☰

rsync 占用 100% 的 CPU 并需要数小时才能完成

tag-icon • tag-icon backup rsync
rsync 占用 100% 的 CPU 并需要数小时才能完成

因此，我有一个非常简单的备份脚本，它每晚作为 cron 作业运行，它是：

rsync -azhv /company/shared_files/ /mnt/ext_drive/backups/shared_files/company_share_backup_"`date +\%Y-\%m-\%d`"

之前备份的大小约为 20 GB，运行时间约为 10 分钟，但两天前备份的大小为 80 GB，运行时间超过 6 小时。可能出了什么问题？

我的一般程序是将每个备份保留 7 天，然后保留每周日的备份以节省空间，因此理想情况下，我希望每天进行一次单独的 rsync，而不是以更自然的方式进行 rsync，即仅更新备份中已更改的文件。

额外细节

我正在运行具有 2TB 硬盘和 16G 内存的 Debian Wheezy，并将这些文件从我的 Debian 服务器传输到具有 2TB 的 WD My Passport Ultra。

答案1

您可以在此处执行一些操作。您不需要使用-zrsync 标志来获取本地副本。非远程传输不使用压缩。

-W您可以使用其他选项（如无需预扫描即可传输整个文件）对 rsync 进行更好的优化，以适应小文件和更改类型。

另外，您不应该删除目标上的文件吗？

有关您所使用的实际操作系统、磁盘功能和备份目标的更多详细信息可以帮助您更好地集中解决方案。

答案2

请确保你使用的机器没有被黑客入侵，很多用户（包括我）都发现比特币矿工隐藏在 rsync 或其他进程后面。检查方法如下：

  • 查看用户的 cron 作业：# crontab -l -u alex
  • 删除发现的恶意 cron 作业中列出的文件夹
  • 删除 /tmp 中的隐藏文件夹
  • 删除未知/home/USER/.ssh/authorized_keys 中的密钥或更糟的 /root/.ssh/authorized_keys
  • 安装 ClamAv 并设置每周扫描：关联
  • 未知用户：lslogins
  • /etc/ssh/sshd_config应该只允许一个非 root 用户使用 SSH：AllowUsers me mom dad
  • 使用更强大的密码并使用公钥登录

其他报告https://askubuntu.com/questions/1115770/crond64-tsm-virus-in-ubuntu

答案3

我猜你的文件传输不是受rsync目标设备限制，而是受目标设备限制。它一开始看起来运行得很快的原因是你可能有大量的 RAM，并且 和 中的值很大/proc/sys/vm/dirty_ratio。/proc/sys/vm/dirty_background_ratio这允许从源到 RAM 进行写入，以查看进度，但是当 RAM 缓存已满并且文件实际上需要写入磁盘时，你会看到该过程变慢。

如果这种情况发生在较新的目标磁盘（例如新的 Seagate 4+ TB 磁盘）中，则您可能SMR硬盘目标设备。例如，Seagate 4 TB 和 6 TB SMR HDD 仅在写入的前 20 GB 时速度较快，因为驱动器具有内部 PMR 缓存区域和速度慢得多的 SMR 区域，并且所有这些都在内部处理（这就是所谓的“驱动器管理”设置）。缓存已满后，顺序写入的写入性能从 160 MB/s 下降到 25 MB/s 左右，并且从 80-160 MB/s 降至 1 MB/s随机文件写入。这是实际的硬件性能设备，没有特殊的技巧可以帮助解决这个问题。唯一真正的“解决方法”是等待设备完成任务。一旦存储设备保持通电足够长的时间（对于 Seagate SMR 设备，这似乎大约是半小时），内部缓存将被刷新到较慢的永久区域，之后设备在下一个 ~20 GB 突发中再次快速运行。如果您在一次突发中只写入最多 20 GB（实际上在 30 分钟内），您将永远不会遇到此问题。

不幸的是，大多数硬件供应商不会公开披露快速缓存的数量和所有规格数字总是仅指快速缓存区域。快速缓存已满后，设备的性能通常会大大降低。SSD 设备也会发生这种情况。例如，众所周知，三星 EVO 系列即使硬件非常好，也会表现出类似的行为。对于三星 EVO，速度下降幅度不像 SMR 驱动器那样是 100 倍，而是慢 2-3 倍。

相关内容