考虑移除 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%

[leavelet]

镜像本身同步已完成。我们已经向学校提交申请。目前校计算中心正在组织对服务的用量等进行评估，并进行初步测试。一旦稳定，我们将立刻上线。感谢TUNA的同学提供服务器情况的相关信息，很抱歉迟了一些，但我们认为这星期上线是没有问题的

[johnnychen94]

定位 artifacts 占用量高的包，然后在同步脚本中引入黑名单机制屏蔽这些包的 artifacts 下载

因为 Julia 镜像的定位是一个全量存储，所以删掉部分数据会在用户侧带来一些问题（即本来可以下载的变成了去 GitHub 下载，但国内直连 GitHub 的成功率过低）。

最后没有走这个方案，而是延续了 Julia 的缓存服务器的设计并做了一些优化工作，后面应该会尝试在公网自行部署一个oss存储桶和一些边缘节点。

[ZenithalHourlyRate]

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

现在 TUNA 一台后端服务器存储利用率达到了 99.7%，已移除相应镜像。

目前，http 服务仍能正常工作，rsync 因为负载均衡会按照来源IP出现不工作的情况

[leavelet]

欢迎大家测试：mirrors.pku.edu.cn/julia

[ZenithalHourlyRate]

现在 TUNA 一台后端服务器存储利用率达到了 99.7%，已移除相应镜像。

另一台后端服务器存储利用率也来到了 99.7%，已移除相应镜像，并将相应 http 流量重定向到 PKU；rsync 服务已停止，并通知到了已知的下游。

[ZenithalHourlyRate]

https://mirrors.tuna.tsinghua.edu.cn/news/remove-julia-openresty-mysql-ftp/

[yaoge123]

https://mirror.nju.edu.cn/julia/ 继续服务

[johnnychen94]

请问 opentuna.cn 是否也计划做相应移除？我看它上一次同步是在一周前 (0322)

[johnnychen94]

苏州同元这边也起了一个公开的 Julia 镜像：https://discourse.juliacn.com/t/topic/7552