在过去的几天里，我一直在试图了解我们的基础设施中发生的奇怪现象，但我无法弄清楚，所以我向你们寻求一些提示。
我在 Graphite 中注意到，load_avg 的峰值大约每 2 小时就会出现一次，而且非常有规律——虽然不是 2 小时，但非常有规律。我附上了从 Graphite 截取的屏幕截图
我一直在调查这个问题——这种现象的规律性让我以为这是某种 cron 作业或类似的东西，但这些服务器上没有运行 cron 作业——实际上这些是在 Rackspace 云中运行的虚拟机。我正在寻找可能导致这些问题的某种迹象以及如何进一步调查这个问题。
服务器相当空闲 - 这是一个暂存环境，因此几乎没有流量进入/它们应该没有负载。这些都是 4 个虚拟核心虚拟机。我确切知道的是，我们大约每 10 秒采集一堆 Graphite 样本，但如果这是负载的原因，那么我预计它会持续处于高位，而不是每 2 小时在不同的服务器上分批发生一次。
对于如何调查此事的任何帮助都将不胜感激！
以下是 app01 的 sar 数据（即上图中的第一个蓝色峰值），我无法从数据中得出任何结论。另外，您看到的每半小时（而不是每 2 小时）发生的字节写入峰值并不是由于 chef-client 每 30 分钟运行一次造成的。我会尝试收集更多数据，尽管我已经这样做了，但也无法从中得出任何结论。
加载
09:55:01 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked
10:05:01 PM 0 125 1.28 1.26 0.86 0
10:15:01 PM 0 125 0.71 1.08 0.98 0
10:25:01 PM 0 125 4.10 3.59 2.23 0
10:35:01 PM 0 125 0.43 0.94 1.46 3
10:45:01 PM 0 125 0.25 0.45 0.96 0
10:55:01 PM 0 125 0.15 0.27 0.63 0
11:05:01 PM 0 125 0.48 0.33 0.47 0
11:15:01 PM 0 125 0.07 0.28 0.40 0
11:25:01 PM 0 125 0.46 0.32 0.34 0
11:35:01 PM 2 130 0.38 0.47 0.42 0
11:45:01 PM 2 131 0.29 0.40 0.38 0
11:55:01 PM 2 131 0.47 0.53 0.46 0
11:59:01 PM 2 131 0.66 0.70 0.55 0
12:00:01 AM 2 131 0.81 0.74 0.57 0
中央处理器
09:55:01 PM CPU %user %nice %system %iowait %steal %idle
10:05:01 PM all 5.68 0.00 3.07 0.04 0.11 91.10
10:15:01 PM all 5.01 0.00 1.70 0.01 0.07 93.21
10:25:01 PM all 5.06 0.00 1.74 0.02 0.08 93.11
10:35:01 PM all 5.74 0.00 2.95 0.06 0.13 91.12
10:45:01 PM all 5.05 0.00 1.76 0.02 0.06 93.10
10:55:01 PM all 5.02 0.00 1.73 0.02 0.09 93.13
11:05:01 PM all 5.52 0.00 2.74 0.05 0.08 91.61
11:15:01 PM all 4.98 0.00 1.76 0.01 0.08 93.17
11:25:01 PM all 4.99 0.00 1.75 0.01 0.06 93.19
11:35:01 PM all 5.45 0.00 2.70 0.04 0.05 91.76
11:45:01 PM all 5.00 0.00 1.71 0.01 0.05 93.23
11:55:01 PM all 5.02 0.00 1.72 0.01 0.06 93.19
11:59:01 PM all 5.03 0.00 1.74 0.01 0.06 93.16
12:00:01 AM all 4.91 0.00 1.68 0.01 0.08 93.33
输入输出
09:55:01 PM tps rtps wtps bread/s bwrtn/s
10:05:01 PM 8.88 0.15 8.72 1.21 422.38
10:15:01 PM 1.49 0.00 1.49 0.00 28.48
10:25:01 PM 1.54 0.00 1.54 0.03 29.61
10:35:01 PM 8.35 0.04 8.31 0.32 411.71
10:45:01 PM 1.58 0.00 1.58 0.00 30.04
10:55:01 PM 1.52 0.00 1.52 0.00 28.36
11:05:01 PM 8.32 0.01 8.31 0.08 410.30
11:15:01 PM 1.54 0.01 1.52 0.43 29.07
11:25:01 PM 1.47 0.00 1.47 0.00 28.39
11:35:01 PM 8.28 0.00 8.28 0.00 410.97
11:45:01 PM 1.49 0.00 1.49 0.00 28.35
11:55:01 PM 1.46 0.00 1.46 0.00 27.93
11:59:01 PM 1.35 0.00 1.35 0.00 26.83
12:00:01 AM 1.60 0.00 1.60 0.00 29.87
网络：
10:25:01 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
10:35:01 PM lo 8.36 8.36 2.18 2.18 0.00 0.00 0.00
10:35:01 PM eth1 7.07 4.77 5.24 2.42 0.00 0.00 0.00
10:35:01 PM eth0 2.30 1.99 0.24 0.51 0.00 0.00 0.00
10:45:01 PM lo 8.35 8.35 2.18 2.18 0.00 0.00 0.00
10:45:01 PM eth1 3.69 3.45 0.65 2.22 0.00 0.00 0.00
10:45:01 PM eth0 1.50 1.33 0.15 0.36 0.00 0.00 0.00
10:55:01 PM lo 8.36 8.36 2.18 2.18 0.00 0.00 0.00
10:55:01 PM eth1 3.66 3.40 0.64 2.19 0.00 0.00 0.00
10:55:01 PM eth0 0.79 0.87 0.08 0.29 0.00 0.00 0.00
11:05:01 PM lo 8.36 8.36 2.18 2.18 0.00 0.00 0.00
11:05:01 PM eth1 7.29 4.73 5.25 2.41 0.00 0.00 0.00
11:05:01 PM eth0 0.82 0.89 0.09 0.29 0.00 0.00 0.00
11:15:01 PM lo 8.34 8.34 2.18 2.18 0.00 0.00 0.00
11:15:01 PM eth1 3.67 3.30 0.64 2.19 0.00 0.00 0.00
11:15:01 PM eth0 1.27 1.21 0.11 0.34 0.00 0.00 0.00
11:25:01 PM lo 8.32 8.32 2.18 2.18 0.00 0.00 0.00
11:25:01 PM eth1 3.43 3.35 0.63 2.20 0.00 0.00 0.00
11:25:01 PM eth0 1.13 1.09 0.10 0.32 0.00 0.00 0.00
11:35:01 PM lo 8.36 8.36 2.18 2.18 0.00 0.00 0.00
11:35:01 PM eth1 7.16 4.68 5.25 2.40 0.00 0.00 0.00
11:35:01 PM eth0 1.15 1.12 0.11 0.32 0.00 0.00 0.00
11:45:01 PM lo 8.37 8.37 2.18 2.18 0.00 0.00 0.00
11:45:01 PM eth1 3.71 3.51 0.65 2.20 0.00 0.00 0.00
11:45:01 PM eth0 0.75 0.86 0.08 0.29 0.00 0.00 0.00
11:55:01 PM lo 8.30 8.30 2.18 2.18 0.00 0.00 0.00
11:55:01 PM eth1 3.65 3.37 0.64 2.20 0.00 0.00 0.00
11:55:01 PM eth0 0.74 0.84 0.08 0.28 0.00 0.00 0.00
对于那些对 cronjobs 感到好奇的人来说。这是服务器上设置的所有 cronjobs 的摘要（我选择了 app01，但其他几台服务器上也设置了相同的 cronjobs）
$ ls -ltr /etc/cron*
-rw-r--r-- 1 root root 722 Apr 2 2012 /etc/crontab
/etc/cron.monthly:
total 0
/etc/cron.hourly:
total 0
/etc/cron.weekly:
total 8
-rwxr-xr-x 1 root root 730 Dec 31 2011 apt-xapian-index
-rwxr-xr-x 1 root root 907 Mar 31 2012 man-db
/etc/cron.daily:
total 68
-rwxr-xr-x 1 root root 2417 Jul 1 2011 popularity-contest
-rwxr-xr-x 1 root root 606 Aug 17 2011 mlocate
-rwxr-xr-x 1 root root 372 Oct 4 2011 logrotate
-rwxr-xr-x 1 root root 469 Dec 16 2011 sysstat
-rwxr-xr-x 1 root root 314 Mar 30 2012 aptitude
-rwxr-xr-x 1 root root 502 Mar 31 2012 bsdmainutils
-rwxr-xr-x 1 root root 1365 Mar 31 2012 man-db
-rwxr-xr-x 1 root root 2947 Apr 2 2012 standard
-rwxr-xr-x 1 root root 249 Apr 9 2012 passwd
-rwxr-xr-x 1 root root 219 Apr 10 2012 apport
-rwxr-xr-x 1 root root 256 Apr 12 2012 dpkg
-rwxr-xr-x 1 root root 214 Apr 20 2012 update-notifier-common
-rwxr-xr-x 1 root root 15399 Apr 20 2012 apt
-rwxr-xr-x 1 root root 1154 Jun 5 2012 ntp
/etc/cron.d:
total 4
-rw-r--r-- 1 root root 395 Jan 6 18:27 sysstat
$ sudo ls -ltr /var/spool/cron/crontabs
total 0
$
如您所见，没有每小时一次的 cronjob。只有每日/每周一次的 cronjob 等。
我收集了大量统计数据（vmstat、mpstat、iostat）——无论我怎么努力，我都找不到任何线索表明任何 VM 组件行为不当……我开始倾向于虚拟机管理程序的潜在问题。请随意查看统计数据要点从“有问题”时间附近的 sar -q 输出开始，然后您可以看到 vm、mp 和 iostats……
基本上这对我来说仍然是一个谜......
答案1
有趣的。
首先，您能否增加 sar 日志记录的频率。尝试每分钟记录一次，而不是每 10 分钟一次。sysstat cronjob 是可配置的。
接下来，尝试编写以下命令。
ps auxf > /tmp/ps.out
vmstat 1 50 > /tmp/vm.out
mpstat -P ALL 1 50 > /tmp/mp.out
iostat -xdk 1 50 > /tmp/io.out
cat /proc/meminfo > /tmp/meminfo.out
每次平均负载增加时，手动或通过 cron 收集这组数据。最好至少有一个完整工作日的数据。
现在，我明白了，服务器处于空闲状态，但仍有一些应用程序正在运行。它们是什么？
您是否可以运行一些分析工具，例如 perf 或 oprofile。
是否有任何服务器硬件组件发生改变？即使是固件升级或软件升级这样无害的事情。
嘿，有个问题。你运行的调度程序是什么。我相信它是 cfq，你能把它改成 noop 吗？输入elevator=noop内核命令行参数并重新启动系统，看看它是否会改善它。
答案2
日志顶部流程
由于发生的频率很高，因此设置 cron 任务来监控这些时间段内的顶级进程
#app01
20-59 0/2 * * * root /usr/bin/top -b -n 1 | /usr/bin/head -n 15 >> /var/log/top.log
更改20-59为*将记录每偶数小时的整小时。无论哪种情况，Cron 作业都会每分钟运行一次。
您可能需要将 top.log 文件添加到日志轮换中，这样如果您忘记禁用它，它就不会占用所有空间。
检查日志文件
高负载期间搜索日志文件条目
以下面的加载条目为例
10:25:01 PM 0 125 4.10 3.59 2.23 0
做
grep ' 22:2' /var/log/*
grep ' 22:2' /var/log/apache2/*
这将显示 的所有日志条目22:2x:xx。可能必须包括其他日志目录。
2013 年 1 月 6 日星期日 21:00:07：xvda w_await 峰值
xvda 图表 - w_await 峰值出现在 2013 年 1 月 6 日星期日 21:00:07
答案3
有一件事我肯定会检查：
- vSphere 图表采用相同的模式，也许同一主机上的另一个 VM 正在占用 CPU（因此，由于 VM 可用的 CPU 时间较少，因此需要更多时间以恒定流量处理相同数量的数据，因此 VM 上的负载会增加）。
编辑：第一次没有得到它:)您正在 Rackspace 上运行，因此无法控制虚拟机管理程序，但可能值得询问 rackspace 是否可以检查这种模式是否在同一主机上的其他虚拟机上常见。