考虑移除 Julia 镜像或切换同步方式

[ZenithalHourlyRate]

目前 Julia 镜像占用大，利用率低，提议移除

1. Julia 镜像占用约 3.6T，占用 TUNA 与 BFSU 镜像站总储存空间的约 4%
2. 过去一周 /julia 的 TUNA 流量为 30G，BFSU 的为 40G；而 TUNA 过去一周流量约 570T，BFSU 约 163T。

注意到 https://discourse.juliacn.com/t/topic/2969 中 juliacn 已经提供了相应的镜像

我们认为该问题可以有两个方法解决

1. 移除相应镜像，并将其重定向到 juliacn 的相关站点
2. 修改同步脚本，使得空间占用量降低

我们倾向于使用第一种方法解决，因为镜像站维护人员并不熟悉 julia，且时间精力有限。

移除可能在任何空间告警的时候发生。目前，BFSU 的空间利用已达 99.1%，TUNA 的空间利用已达 98.5%，会随时在镜像大小波动中占满储存。

Cc @johnnychen94

[taoky]

julia/artifact 的占用空间非常大：

$ du -sh .
3.5T	.

但是作为参考，科大镜像站 artifact 的日访问量只有几十次到约百次：

$ xzcat access.log-20230216.xz | grep --text 'julia/artifact' | wc
    177    2301   29195

不确定同步程序会不会删除 artifact 中的无效引用（？），同时如果能够在同步时 exclude 掉很大的每日构建类 artifact 的话（如果有）大小应该能小很多。

[johnnychen94]

社区目前的服务器在容量和稳定性上不是很优，实际上很多用户还是会手动定向至校园镜像站来使用 Julia，重定向的话可能会导致用户大批量开始抱怨。

从我所知道的来说，Julia 社区里目前确实存在对 Artifacts 进行滥用的情况，例如: BinaryBuilderBase 以一己之力占了 300GB 的 artifacts 空间¹ 官方对此的态度应该是这些都属于 S3 考虑的东西而 S3 存储很便宜所以导致增长有点过快

我能想到的几个更平滑的策略是：

• 找商业化支持来支撑代理服务器的部署，优化社区的服务器质量
• 定位 artifacts 占用量高的包，然后在同步脚本中引入黑名单机制屏蔽这些包的 artifacts 下载（这样做会导致用户的下载会被导向 github）：如果这样做的话，大约需要将空间压缩到什么程度才算是可行的呢，比如说，1T 以内？

Footnotes

1. https://gist.github.com/johnnychen94/ade1d5fd1eb398edf017ab42623397c1 ↩

[xgdgsc]

就这么大吗，有没有出钱加硬盘的选项？

[jiegec]

主要是性价比的问题，单台服务器插满的硬盘容量也就那么多，需要优先考虑用的人多的。

[ZenithalHourlyRate]

• 定位 artifacts 占用量高的包，然后在同步脚本中引入黑名单机制屏蔽这些包的 artifacts 下载（这样做会导致用户的下载会被导向 github）：如果这样做的话，大约需要将空间压缩到什么程度才算是可行的呢，比如说，1T 以内？

我们可以接受这种方案；当然，也可以屏蔽一些旧的 artifact，例如只同步最新版本；我们期待总占用小于 500G。

[johnnychen94]

我现在在全职工作所以可能没有这么快响应，我会尽量在 3.15 之前给出一个新的满足需求的同步方案。

[GiggleLiu]

就这么大吗，有没有出钱加硬盘的选项？

加硬盘是对 tuna 镜像和 julia 社区都更好的选项。首先删除julia镜像对 Julia 社区的用户非常不友好，其次多出的 2% 的服务器空间没有办法帮助 tuna 镜像解决本质问题。

Julia 社区的用户主要集中在科学计算领域，主要来自科研院校和企业研发部门，因此用户体量的确不大。下载量没有优势不意味着它不重要，因为这些领域往往有着高附加值。比如，如果tuna源停用，我教的科学计算课的课件就得重写 😢 。

从成本角度考虑，网络资源远比硬盘贵，拓展空间成本并没有那么高，所以拓展硬盘容量是个实际的选项。我建议核算下成本，可以由 JuliaCN 支付多出的维护成本。

[Harry-Chen]

就这么大吗，有没有出钱加硬盘的选项？

加硬盘是对 tuna 镜像和 julia 社区都更好的选项。首先删除julia镜像对 Julia 社区的用户非常不友好，其次多出的 2% 的服务器空间没有办法帮助 tuna 镜像解决本质问题。

2% 不解决本质问题，但能缓解其他在目前更重要、用户更多的软件或系统的燃眉之急。

Julia 社区的用户主要集中在科学计算领域，主要来自科研院校和企业研发部门，因此用户体量的确不大。下载量没有优势不意味着它不重要，因为这些领域往往有着高附加值。比如，如果tuna源停用，我教的科学计算课的课件就得重写 😢 。

作为一个 HPC 从业者，我目前没有见到显著的使用 Julia 进行的严肃计算。我想如果我们真的删除 Julia，您只需要把课件换成另一个镜像源（比如 NJU）即可，无需重写。

从成本角度考虑，网络资源远比硬盘贵，拓展空间成本并没有那么高，所以拓展硬盘容量是个实际的选项。我建议核算下成本，可以由 JuliaCN 支付多出的维护成本。

由于架构要求，扩容的成本不仅仅是增加单块硬盘。例如，镜像站单台主力服务器的扩容需要超过 20 块的大容量高速 NVMe 硬盘，目前每块的成本超过 10000 人民币。我想这一成本对于非盈利的开源组织来说是很沉重的。

[GiggleLiu]

由于架构要求，扩容的成本不仅仅是增加单块硬盘。例如，镜像站单台主力服务器的扩容需要超过 20 块的大容量高速 NVMe 硬盘，目前每块的成本超过 10000 人民币。我想这一成本对于非盈利的开源组织来说是很沉重的。

感谢说明，JuliaCN 支持一块是没有问题的，但是20块对开源组织肯定有沉重的负担。不知道这里的一块盘能否支撑 3.5 T 的开销。
总是让镜像源用爱发电肯定不是可持续的方案，所以我建议核算清楚成本，提供个可选方案，让其它组织一起承担开销。只要开销合理，JuliaCN 可以向一些公司去拉赞助，这样开源生态才可以转起来。

作为一个 HPC 从业者，我目前没有见到显著的使用 Julia 进行的严肃计算。

引用你的个人经验来说明问题是不公平的，科学计算本来就是从学术届慢慢向工业界扩散的过程，普通用户少只是暂时的。Julia 对于开发新的算法是很有吸引力的，从学术界对 Julia 软件包的引用就可以看出来

引用数学优化软件 JuMP.jl 进行计算的工作：

引用张量计算软件 ITensor.jl 进行计算的工作：

http://itensor.org/docs.cgi?page=papers

引用量子计算模拟器 Yao.jl 进行计算的工作，其中就包括清华的某量子课题组的约十篇工作：

在很长的时间，国内都没有好用的源，导致国内服务器根本没法 setup Julia环境。
国内刚刚弄好 Julia artifacts 的源的时候，由于一些网络问题，很多软件还是装不上，的确导致用户很失望。
所以你作为 HPC 从业者，看不到 Julia 用户很正常。
我们应该更加有耐心，要相信 Julia 的软件源正在变得越来越稳定，它的影响力会慢慢的扩散出去。
我不希望我们国家以后还需要依赖 Matlab 教学。即使是python也不够好，因为这些语言割裂了开发者和用户，把学生限制在了用户而非开发者层面。

2% 不解决本质问题，但能缓解其他在目前更重要、用户更多的软件或系统的燃眉之急。

很多国内 julia 的软件源写的是 tuna 的，网上的教程也是写 tuna 的源的居多。撤销 tuna 源之后，大家得重新找源。教程也得修改。除非可以加个重定向，否则对 julia 生态打击是很大的。

[shankerwangmiao]

由于架构要求，扩容的成本不仅仅是增加单块硬盘。例如，镜像站单台主力服务器的扩容需要超过 20 块的大容量高速 NVMe 硬盘，目前每块的成本超过 10000 人民币。我想这一成本对于非盈利的开源组织来说是很沉重的。

感谢说明，JuliaCN 支持一块是没有问题的，但是20块对开源组织肯定有沉重的负担。不知道这里的一块盘能否支撑 3.5 T 的开销。 总是让镜像源用爱发电肯定不是可持续的方案，所以我建议核算清楚成本，提供个可选方案，让其它组织一起承担开销。只要开销合理，JuliaCN 可以向一些公司去拉赞助，这样开源生态才可以转起来。

这里面其实是有个问题的，作为小型的存储系统，它并非是可以无限分割的，不能像水那样想要多少就可以量取多少。即使添加，也不可能是一块一块地添加，更何况硬盘的插槽其实也快满了。所以要扩容的话可能是所有盘一起都换掉。因此核算成本其实并不能解决眼下存储即将耗尽的问题。目前我们还在争取条件看看能否进一步扩充容量，不过暂时没有时间表。

2% 不解决本质问题，但能缓解其他在目前更重要、用户更多的软件或系统的燃眉之急。

很多国内 julia 的软件源写的是 tuna 的，网上的教程也是写 tuna 的源的居多。撤销 tuna 源之后，大家得重新找源。教程也得修改。除非可以加个重定向，否则对 julia 生态打击是很大的。

如果确实不得不出现这样的遗憾情况，我们会做好后续收尾工作。

[GiggleLiu]

由于架构要求，扩容的成本不仅仅是增加单块硬盘。例如，镜像站单台主力服务器的扩容需要超过 20 块的大容量高速 NVMe 硬盘，目前每块的成本超过 10000 人民币。我想这一成本对于非盈利的开源组织来说是很沉重的。

感谢说明，JuliaCN 支持一块是没有问题的，但是20块对开源组织肯定有沉重的负担。不知道这里的一块盘能否支撑 3.5 T 的开销。 总是让镜像源用爱发电肯定不是可持续的方案，所以我建议核算清楚成本，提供个可选方案，让其它组织一起承担开销。只要开销合理，JuliaCN 可以向一些公司去拉赞助，这样开源生态才可以转起来。

这里面其实是有个问题的，作为小型的存储系统，它并非是可以无限分割的，不能像水那样想要多少就可以量取多少。即使添加，也不可能是一块一块地添加，更何况硬盘的插槽其实也快满了。所以要扩容的话可能是所有盘一起都换掉。因此核算成本其实并不能解决眼下存储即将耗尽的问题。目前我们还在争取条件看看能否进一步扩充容量，不过暂时没有时间表。

恩，希望可以争取下。感谢

2% 不解决本质问题，但能缓解其他在目前更重要、用户更多的软件或系统的燃眉之急。

很多国内 julia 的软件源写的是 tuna 的，网上的教程也是写 tuna 的源的居多。撤销 tuna 源之后，大家得重新找源。教程也得修改。除非可以加个重定向，否则对 julia 生态打击是很大的。

如果确实不得不出现这样的遗憾情况，我们会做好后续收尾工作。

恩，做好两手准备吧。@johnnychen94 也在找新的解决方案。如果不得不删除，我们再看下如何才能更加平滑的重定向过去。

[leavelet]

北大镜像站 Julia 源正在同步，预计 3.15 之前可以上线。我们正在和 TUNA 积极沟通，看怎么过渡会比较合适。

[zsz00]

现在 北大镜像站 Julia 源 可用了吗? 地址是什么? @leavelet

[ZenithalHourlyRate]

在 2 月 22 日时 BFSU 存储利用率达到了 99.6%，当时即移除 julia 镜像并将其重定向到 TUNA

现在 TUNA 一台后端服务器存储利用率达到了 99.3%