在Linux Ubuntu上加载平淡的奇怪

在过去的几天里,我一直在试图理解我们基础架构中发生的奇怪事情,但是我一直无法想象它,所以我正在转向你们给我一些提示。

我一直在注意到Graphite,load_avg中的尖峰大约每2个小时发生一次致命的规律 – 这不是完全是2个小时,而是非常规律的。 我附上了我从Graphite拿来的截图

加载平均 - 点击放大

我一直在调查这一点 – 这种规律导致我认为这是某种cron工作或类似的东西,但没有在这些服务器上运行的cronjob – 实际上这些是在Rackspace云运行的虚拟机。 我正在寻找的是某种迹象可能会导致这些问题,以及如何进一步调查。

服务器相当闲置 – 这是一个临时环境,所以几乎没有stream量进入/应该没有负载。 这些都是4个虚拟核心虚拟机。 我所知道的是,我们每10秒钟就会收集一堆Graphite样本,但如果这是造成负载的原因,那么我认为它会持续高涨,而不是在不同的服务器上每隔2小时发生一次。

任何帮助如何调查这将不胜感激!


以下是一些来自app01的数据 – 这是上图中的第一个蓝色尖峰 – 我无法从数据中得出任何结论。 也不是说,每半小时(不是每2小时)发生的字节写数就是每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 

IO

 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 

networking:

 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好奇的人。 这里是服务器上设置的所有cronjob的摘要(我select了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 $ 

正如你所看到的,没有HOURLY cronjobs。 只有每天/每周等

我已经收集了一堆统计数据(vmstat,mpstat,iostat) – 不过我正在努力尝试,我只是看不到任何会导致虚拟机组件行为exception的线索……我开始依靠pipe理程序来解决潜在的问题。 随时查看统计数据要点在“冒犯”时间周围开始输出sar -q,然后可以看到vm,mp和iostats ….

基本上这对我来说还是个谜。

有趣。

首先,你可以增加sarlogging的频率。 而不是10分钟,尝试logging每一分钟。 sysstat cronjob是可configuration的。

接下来,尝试编写以下命令。

 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增加的每次迭代中收集这组数据。 获得至less一个完整工作日的数据将是一件好事。

现在,我明白,服务器是空闲的,但仍然有一些应用程序必须运行。 他们是什么?

是否有可能运行一些分析工具,如perf或oprofile。

是否有任何服务器硬件组件被更改? 甚至像固件升级或软件升级一样无害。

嘿,一个问题。 什么是您正在运行的调度程序。 我相信这是cfq,任何机会,你可以改变它noop。 将elevator=noop放在内核命令行参数中,然后重启系统,看看是否改善了。

日志顶部进程

由于事件发生非常规律,因此设置cron作业来监视那段时间内的最高进程

 #app01 20-59 0/2 * * * root /usr/bin/top -b -n 1 | /usr/bin/head -n 15 >> /var/log/top.log 

20-59更改为*将logging每个偶数小时的整个小时。 在任何情况下,Cron工作将每分钟运行一次。

您可能需要添加top.log文件来logging旋转,所以它不会占用所有的空间,以防您忘记禁用它。

检查日志文件

在高负载时间search日志文件条目

以下面的负载input为例

 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所有日志条目。 可能必须包含其他日志目录。

Sun Jan 6 21:00:07 2013:xvda w_await spike

xvda图表 – 等待大涨在2013年1月6日21:00:07 在这里输入图像描述

有一件事我肯定会检查:

  • 对于相同模式的vSpheregraphics,可能是同一主机上的另一个虚拟机正在占用CPU(因此虚拟机上的负载会增加,因为可用的CPU时间较less,需要更多的时间来处理恒定stream量的相同数据量你的虚拟机)。

编辑:没有得到它第一次:)你在Rackspace上运行,所以没有控制pipe理程序,但它可能是值得问rackspace,如果他们可以检查这种模式是共同的在同一主机上的其他虚拟机。