zip 太好了（Mac OS X）

Question

我使用 zip 将本地目录定期备份到远程机器上。他们不相信这里的 rsync 之类的东西，所以这是我能做的最好的（？）。这是我使用的脚本

echo $(date)>>~/backuplog.txt;
if [[ -e /Volumes/backup/ ]];
then 
    cd /Volumes/Non-RAID_Storage/;
    for file in projects/*; 
        do nice -n 10 zip -vru9 /Volumes/backup/nonRaidStorage.backup.zip "$file" 2>&1 | grep -v "zip info: local extra (21 bytes)">>~/backuplog.txt;
    done;
else 
    echo "backup volume not mounted">>~/backuplog.txt;
fi

这一切都很好，除了 zip 从不使用太多 CPU，所以它似乎比它应该花费的时间更长。它似乎永远不会超过 5%。我试着让它变得更好 -20 但这没有任何区别。仅仅是网络或磁盘速度阻碍了进程还是我做错了什么？

Answer 1

您可能会发现它zip大部分时间都在等待 I/O（读取文件和写入压缩版本），这就是为什么它使用的 CPU 没有您期望的那么多。赋予进程额外的优先级nice对此没有影响，因为如果任务没有以需要它的速度提供数据，则它不能使用更多的 CPU 时间。

在 Linux 下，您可以在top类似实用程序的输出中将这种情况视为“IO 等待”时间的高百分比，OSX 可能也是如此。

IO 等待时间的原因可能包括：

1. 处理许多小文件（读取文件和相关目录结构的大量头部运动）
2. 文件碎片
3. 在备份发生时与相关驱动器上的其他活动（用户复制/移动/访问文件、计划的 AV 扫描等）竞争
4. 通过网络读取文件（现代 CPU 压缩数据的速度远远快于 100Mbit/s 链接所能提供的数据，并且网络延迟会加剧多小文件的影响）或通过网络推送压缩数据（除非您的数据异常可压缩，同样的“zip 比现代 CPU 上的网络更快”条件适用，因为它会从您的本地驱动器读取并处理 daat 比它可以通过网络发送结果的速度更快）
5. 网络争用（如果您正在通话的服务器有一个 100Mbit 的链接，而其他人正在使用它，这可能是一个问题，当然如果它有更快的链接，问题就更少了）
6. 慢速驱动器或慢速接口（如果任何相关驱动器连接 USB2，它们的传输速度往往不超过 25Mbyte/sec，有时会更慢，具体取决于所使用的 USB 适配器以及与其他快速设备的 USB 总线争用，其中现代内部驱动器将推动双倍，如果不是更多的批量传输）

如果您想利用“备用”CPU 周期，并且无法通过减少 IO 延迟来实现，您可以尝试使用 7zip - 这会为每个数据块使用更多的 CPU 时间，但比 zip 实现更好的压缩在许多情况下，也有相当多的余量，从而减少了备份的大小。这会更快（因为 7zip 导致通过网络发送的数据更少）还是更慢（因为额外的计算复杂性意味着您的 CPU 可能成为瓶颈而不是磁盘/文件系统/网络）取决于您的机器的确切规格。

编辑：

另一件事，一些工具报告进程使用每个内核和一些每个 CPU（以及一些取决于设置的任一方式），而 zip 通常是一个线程进程。因此，如果您有一个四核 CPU，那么 5% 不太可能是“CPU 的 5%”，或者一个内核的大约 20%（尽管它可能会在内核之间跳动，如果它是单线程的，则不会在任何给定时刻运行多个）。