我有一个负载非常小的CentOS-5服务器。 “sar”命令的典型输出显示如下：
02:20:01 PM CPU %user %nice %system %iowait %steal %idle 02:30:01 PM all 0.63 0.00 1.23 0.31 0.00 97.84 02:40:01 PM all 0.92 0.32 1.34 0.45 0.00 96.97 02:50:01 PM all 0.76 0.00 0.93 0.77 0.00 97.54 03:00:01 PM all 0.41 0.00 0.72 0.15 0.00 98.72 03:10:01 PM all 0.78 0.32 1.49 1.83 0.00 95.58 03:20:01 PM all 0.27 0.00 0.50 0.62 0.00 98.61 不过，我观察到，每天凌晨4:10，CPU使用率非常高。 几乎每个晚上都会发生这种情况，除了一个月的几天。 “sar”命令显示如下所示：
03:00:01 AM all 0.10 0.00 0.10 0.11 0.00 99.68 03:10:01 AM all 0.08 0.32 0.18 0.21 0.00 99.21 03:20:01 AM all 0.03 0.00 0.03 0.19 0.00 99.76 03:30:01 AM all 0.01 0.00 0.02 0.06 0.00 99.91 03:40:02 AM all 0.75 0.32 3.21 15.43 0.00 80.28 03:50:01 AM all 0.95 0.00 3.43 9.25 0.00 86.36 04:00:01 AM all 0.69 0.00 3.79 4.86 0.00 90.66 04:10:01 AM all 22.38 0.54 4.47 30.92 0.00 41.69 04:20:01 AM all 2.99 0.02 4.58 4.95 0.00 87.46 04:30:01 AM all 0.34 0.00 0.61 13.22 0.00 85.83 04:40:01 AM all 0.05 0.32 0.17 0.52 0.00 98.95 04:50:01 AM all 0.22 0.00 0.36 0.11 0.00 99.32 05:00:01 AM all 0.23 0.00 0.36 0.12 0.00 99.28
我如何确定是什么导致CPU使用率和艾奥瓦等这个高峰我检查/ var / log /消息，但无法确定。 当时没有其他的cron工作或者其他的东西可以运行。 由于这是显示在％用户下，我只能看出它是一些用户进程。 我怎么能确切的确定原因？
这是当cron.daily脚本运行时…默认情况下，它每天凌晨4点之后运行。
从/etc/crontabs
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily <-- THIS ONE!! 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
并在/etc/cron.daily 。
罪魁祸首可能是你的mlocate.cron ，它运行updatedb ，在一些系统上可能相当密集：
#!/bin/sh nodevs=$(< /proc/filesystems awk '$1 == "nodev" { print $2 }') renice +19 -p $$ >/dev/null 2>&1 /usr/bin/updatedb -f "$nodevs"
如/ etc / crontab中所述，计划在每天凌晨04:02自动运行cron：
[...] 02 4 * * * root run-parts /etc/cron.daily
运行ls /etc/cron.daily/将显示计划在04:02 AM运行的命令（它们按顺序执行）。 你可以很容易地修改它们，以便在执行之前输出负载。
但是，如果这是一个标准的CentOS安装，负责高负载的脚本很可能是mlocate.cron，0logwatch（如果已安装）或logrotate。
mlocate会执行一个完整的文件系统扫描（这将解释你的系统增加了I / O等待），0logwatch将parsing你的日志文件（这可能是相当大的，导致I / O操作）和logrotate也可以创build重要的I / o如果它跨文件系统移动文件。
既然你说这种情况几乎每天都在4:10发生，一个粗糙的方法是在4:05到4:15之间每分钟运行一次ps aux ，并把输出写入一个文件中。 然后，您可以检查占用CPU的命令的％CPU使用率。
可能是一个cron工作 – 可能“locateb”正在更新？
在夜晚添加自己的cron'd输出“ps”可能有助于找出罪魁祸首。