【乐享】分析服务器崩溃 & rclone的性能调试
概要
被这个该死的小内存折腾得死去活来，每天晚上服务器都要卡死，第二天来强制重启，加上网上关于rclone的资料不是很详细，只能依靠一些Github Issues和官方文档，所以特别麻烦。因此，我也来为这个不充分的资料添一份力罢。
如果你是着急要解决方案，这里直接给出：
- 内存占用很大就加上
--cache-chunk-no-memory参数，禁用内存缓存 - 文件访问速度很慢就开启VFS缓存
--vfs-cache-mode full，并记得设置最大缓存占用空间--vfs-cache-max-size 15G
当然，如果你想看看我的故事，请继续看罢：
问题分析
找出崩溃原因
首先当然是确定崩溃时间和原因，这就要看服务器提供商的日志了。这是我在阿里云控制台看到的。注意，我这次“崩溃”其实是由于系统占用太高导致其他程序无法正常运行。
可以看到CPU和内存的高占用时间基本重合，而网络占用基本没有，基本可以判断不是遭受外部攻击，而是由于服务器系统内部问题导致宕机。话说就我这小不点谁来打我啊这。
找出肇事程序
由于阿里云的控制台只能看到VPS的整体情况，想要看具体的程序还是得到系统内查看。首先查看log，目录在服务器的/var/log下，找到messages或者带有日志分割的日志，下载查看。你当然可以使用dmesg等命令行工具查看，但是我用得不太熟，就还是vscode直接打开日志文件来得顺手些。不过一般都看不出什么毛病，除了像CPU锁死这样的有关系统异常的问题可以看，比如我写的这篇文章，其他系统正常运行的情况下都没什么看的。
然后。转战宝塔监控。这玩意儿要事先打开，不过由于问题基本上每个晚上都会发生，所以还是有机会打开看的。基于磁盘读写占用过多，我们先看磁盘的占用，一看，基本确定肇事程序为rclone。
不过，现在还看不出来rclone是怎么肇事的，这里就随机应变了。我是某一天晚上凌晨起来，顺手看了下top，然后就发现kswap0占用高得离谱，而且是CPU和磁盘读写一起占用。这就很巧了，问题已经水落石出。kswap0这个进程，从名字就可以推断出是将物理内存转存到硬盘swap空间的东西，因此又可以推断出此时一定是内存不足而且持续升高导致转存swap时磁盘和CPU占用飙升，因而其他应用无响应。再加上宝塔监控的信息，基本可以判断是rclone吃内存吃太多了。为了验证判断，我们Google一下：
果然，好多人都有相关的问题，所以实际问题基本符合推断，可以开始解决。
解决问题
所有的参数都是在/etc/systemd/sysetem/onedrive.service的自定义服务配置文件中进行修改。翻看官方文档，发现有VFS技术，详细说明可以看这里。简单来说，就是将网盘上的部分内容提前缓存到本地，以加快数据访问速度和减少网络压力。试一试，将--vfs-cache-mode设置成full，将--vfs-cache-max-size设置成硬盘的剩余空间对应的合理大小，我的是15G，重启，等一晚上，然后发现宕机依旧。
再查阅相关Github Issues，发现与内存占用有关的相关参数为--buffer-size、--transfer与--multi-thread-streams等，如图：
查看rclone官方文档上对应的相关参数，发现--buffer-size对应的是每个文件的至多内存占用，--transfer与--multi-thread-streams为传输文件的并行数，都有关，加上，等一天，发现晚上还是宕机了。摆烂两天，顺便将音乐文件全部转移到网易云，准备放弃挣扎。
最后，再Github Issues中又偶然看到一个问题，里面又给出一个参数--cache-chunk-no-memory，如图：
再等一晚上，一切安好，问题解决:D
原因分析
如果仔细看每天的内存突发上升事件，会发现集中在凌晨12点钟左右开始。通过将navidrome禁用，发现并没有宕机。因此，估计是navidrome在每天12点钟的时候会自动将媒体库全部扫描一遍，然后由于我存在onedrive的音乐有一点多，有3000曲左右，大概21G，所以rclone将这3000多曲音乐全部从onedrive上扒拉下来时吃掉了大量的内存，导致需要将内存数据转存到swap上。然后又好死不死，在kswap0转存swap时候rclone还在继续吃内存，再加上本来分给swap的空间（4G）不够，造成整个系统运行缓慢直至无法正常运行。这也就可以解释为什么我去年将navidrome的曲库搬到OSS上的时候，一个月产生了巨额访问（GetRequest）费用：
因此，如果你的曲库不是很大的话，应该不会有很大问题。不过还是建议做好配置，因为通过rclone挂载外部网盘来实现扩容，特别是对于小内存小存储的机器，确实挺鸡贼的😅