Mac OSX 上的进程“卡住”且 CPU 使用率异常描述了同样的现象，但针对的是写作。我的问题与阅读有关。
OS X 版本 10.8.5
我的内置 500GB 硬盘上有大约 3000 万个小文件，我想将它们备份到几个外部硬盘上。由于文件数量众多，我决定压缩它们，移动压缩文件，然后在完成后解压缩它们。压缩速度在前 80% 左右时 CPU 使用率为 100%，然后稳步下降，现在 CPU 使用率约为 3-7%，每秒大约有 1000 次读取/1MB。运行显示大多数时间top都在进行该过程。stuck
剩余的 20% 文件是在（旋转的）硬盘几乎已满时写入的（我注意到时可用空间已降至 2GB）；我怀疑这些文件散布在整个磁盘中，这stuck意味着要等待从磁盘读取文件。此后我删除了某些文件，因此磁盘现在有约 50GB 的可用空间；但是，性能并没有改善。
运行renice -20或sudo运行都没什么区别；另外，我读到没有办法对 Mac 进行碎片整理。我怀疑我需要删除相关文件，然后在磁盘不那么满时重新写入，以便能够达到之前的性能。
有没有办法知道文件的位置，以便我可以验证这是否确实是问题的根源？此外，知道文件的位置可以帮助我找出文件开始混杂的位置，知道要删除和重写哪些文件 - 还可以验证新文件是否按顺序写入。
更新：我绝对倾向于碎片化的解释。继续压缩，CPU 使用率下降到 1-2%。另一方面，我尝试压缩先前的一个文件夹，它以之前的速度完成。如果没有更好的建议，那么我计划先将文件移动到另一台硬盘上，然后再压缩它们，然后在我的内置硬盘上解压它们。
更新2：我注意到一个反病毒脚本正在检查所连接 USB 上的数百万个文件，并在后台以 级别运行nice 20。我终止了该脚本，压缩 CPU 利用率又恢复到原始水平。显然，即使压缩以 级别运行nice -20，在系统调用方面，它的优先级仍然低于反病毒脚本。真正令人惊讶的是，反病毒脚本是可移植的，完全通过 USB 运行，甚至不接触内部硬盘——我很惊讶它会产生这样的效果。事实上，这种情况并非反病毒脚本所独有——任何对大量文件进行 I/O 的操作，例如解压缩 USB 驱动器上的文件，都会导致同样的事情发生。
在停止杀毒软件并监控其性能后，我决定重新启动它以查看会发生什么。它扫描的第一个文件相当大；即使单独扫描该文件，压缩的 CPU 使用率也会立即下降到 0.2%。随着时间的推移，杀毒软件的实际内存使用量达到 330MB，而压缩的实际内存使用量下降了约 750MB。除此之外，从命令中看不出有什么明显的区别top。
所以现在，这是一个可复制的现象；如果有人提出解释，我可以测试他们的想法并接受它作为答案。