我在一台 ubuntu 机器上运行了几个 cron 作业。每个作业都会做一些非常繁重的工作。cron 作业正在解析文件，文件越大，解析文件所需的时间就越长。奇怪的是，如果我将文件设置得太大（例如 30mb），脚本就会挂起。它开始非常热情地处理它们，但经过一段时间（大约 5-10 分钟），进程的 CPU 使用率会大幅下降，并进入某种“僵尸”状态。如果在此之前，htop 中的进程使用了 70-80% 的 CPU，那么在发生这种下降之后，它会减慢到 5-10% 左右。平均负载也会下降。进程的状态有时会在 htop 中更改为 D，AFAIR 代表僵尸。今天我注意到 mysql 进程在执行繁重查询时有相同的行为（查询需要大约 4 个小时才能执行）。cron 作业主要是 php，在处理过程中，大部分 CPU 消耗在 php 进程而不是 mysql 上。所以我认为问题不在于特定的语言/程序，而在于流程的“管理”方式。
我见过类似行为的唯一其他地方是我的 Amazon EC2 微型实例，在大量使用 CPU 之后，CPU 配额生效，一切都急剧变慢。
这是一台运行 ubuntu 的专用机器。可能是什么原因造成的？
编辑：添加一些细节
内存没有问题，在我看来这不是交换的问题。
iostat 对 IO 活动有如下描述：http://img13.imageshack.us/i/captureehm.png/我觉得这没问题，因为预计会发生一些 IO，而且看起来处理器并没有因 IO 等待而“不堪重负”。如果我错了，请纠正我:)
答案1
特区（1）将提供您需要在此处分析的数据。您可以查看sar -A所有收集的 sar 统计数据，然后深入研究。例如，sar -b将为您提供 I/O 统计数据，以查看您是否因磁盘活动而陷入困境。
sar 的一个很好的特性是它在后台记录，这样您就可以用它来查看历史数据，而不仅仅是当前的统计数据。
答案2
好吧，你可以检查一下它是否正在“尼斯“，但这听起来更像是由于内存或 IO 问题导致进程陷入停滞。您可以发布内存使用情况吗？
答案3
“D”状态表示命令正在等待 IO。它与僵尸进程不太一样。
检查您的进程使用了多少内存 - 如果使用的内存太多并且正在交换，这很可能表现为您所看到的症状。