☰

什么原因导致平均负载异常高？

tag-icon • tag-icon load-average iowait
什么原因导致平均负载异常高？

我注意到上周二晚上，平均负载急剧上升，由于流量很小，这似乎很不正常。通常，这些数字通常平均在 .40 或更低，我的服务器内容（mysql、php 和 apache）已优化。我注意到 IOWait 异常高，尽管进程几乎没有使用任何 CPU。

顶部 - 01:44:39 启动 1 天，21:13，1 个用户，平均负载：1.41、1.09、0.86
任务：共 60 个，1 个正在运行，59 个正在休眠，0 个已停止，0 个僵尸
Cpu0：0.0％us，0.0％sy，0.0％ni，100.0％id，0.0％wa，0.0％hi，0.0％si，0.0％st
CPU1：0.0％us，0.0％sy，0.0％ni，100.0％id，0.0％wa，0.0％hi，0.0％si，0.0％st
CPU2：0.0％us、0.3％sy、0.0％ni、99.7％id、0.0％wa、0.0％hi、0.0％si、0.0％st
CPU3：0.0％us，0.0％sy，0.0％ni，100.0％id，0.0％wa，0.0％hi，0.0％si，0.0％st
CPU4：0.0％us，0.0％sy，0.0％ni，100.0％id，0.0％wa，0.0％hi，0.0％si，0.0％st
CPU5：0.0％us，0.0％sy，0.0％ni，100.0％id，0.0％wa，0.0％hi，0.0％si，0.0％st
Cpu6：0.0％us，0.0％sy，0.0％ni，100.0％id，0.0％wa，0.0％hi，0.0％si，0.0％st
CPU7：0.0％us，0.0％sy，0.0％ni，91.5％id，8.5％wa，0.0％hi，0.0％si，0.0％st
内存：总计 1048576k，已用 331944k，可用 716632k，缓冲区 0k
交换：总计 0k，已使用 0k，可用 0k，缓存 0k

  PID 用户 PR NI VIRT RES SHR S %CPU %MEM TIME+ 命令           
    1 根 15 0 2468 1376 1140 S 0 0.1 0:00.92 初始化               
 1656 根 15 0 13652 5212 664 S 0 0.5 0：00.00 apache2            
 9323 根 18 0 13652 5212 664 S 0 0.5 0:00.00 apache2            
10079 根 18 0 3972 1248 972 S 0 0.1 0:00.00 星期日                 
10080 根 15 0 4612 1956 1448 S 0 0.2 0:00.01 bash               
11298 根 15 0 13652 5212 664 S 0 0.5 0：00.00 apache2            
11778 chikorit 15 0 2344 1092 884 S 0 0.1 0:00.05 顶部                
15384 根 18 0 17544 13m 1568 S 0 1.3 0:02.28 miniserv.pl        
15585 根 15 0 8280 2736 2168 S 0 0.3 0：00.02 sshd               
15608 菊科里特 15 0 8280 1436 860 S 0 0.1 0:00.02 sshd

这是 VMStat

进程 -----------内存---------- ---交换-- -----io---- -系统-- ----cpu----
 rb swpd 免费 buff 缓存 si so bi bo in cs us sy id wa
 1 0 0 768644 0 0 0 0 14 23 0 10 1 0 99 0

IOStat-没什么异常

总磁盘读取速度：67.13 K/s | 总磁盘写入速度：0.00 B/s
  TID PRIO 用户磁盘读取磁盘写入 SWAPIN IO> 命令          
19496 be/4 chikorit 11.85 K/s 0.00 B/s 0.00 % 0.00 % apache2 -k 启动
19501 be/4 mysql 3.95 K/秒 0.00 B/秒 0.00 % 0.00 % mysqld
19568 be/4 chikorit 11.85 K/s 0.00 B/s 0.00 % 0.00 % apache2 -k 启动
19569 be/4 chikorit 11.85 K/s 0.00 B/s 0.00 % 0.00 % apache2 -k 启动
19570 be/4 chikorit 11.85 K/s 0.00 B/s 0.00 % 0.00 % apache2 -k 启动
19571 be/4 chikorit 7.90 K/s 0.00 B/s 0.00 % 0.00 % apache2 -k 启动
19573 be/4 chikorit 7.90 K/s 0.00 B/s 0.00 % 0.00 % apache2 -k 启动
    1 be/4 根 0.00 B/s 0.00 B/s 0.00 % 0.00 % 初始化
11778 be/4 chikorit 0.00 B/s 0.00 B/s 0.00 % 0.00 % 顶部
19470 be/4 mysql 0.00 B/秒 0.00 B/秒 0.00 % 0.00 % mysqld

平均负载图表 -https://i.stack.imgur.com/kYsD0.png

在确认之前，我想确认一下这不是 MySQL 问题。另外，这是 OpenVZ 上的 Ubuntu 10.04 LTS 服务器。

编辑：这可能会给 IO 等待提供一个很好的图片

顶部 - 22:12:22 启动 17:41，1 个用户，平均负载：1.10、1.09、0.93
任务：共 33 个，1 个正在运行，32 个正在休眠，0 个已停止，0 个僵尸
CPU：0.6％us，0.2％sy，0.0％ni，89.0％id，10.1％wa，0.0％hi，0.0％si，0.0％st
内存：总计 1048576k，已用 260708k，可用 787868k，缓冲区 0k
交换：总计 0k，已使用 0k，可用 0k，缓存 0k

PID 用户 PR NI VIRT RES SHR S %CPU %MEM TIME+ 命令
1 根 15 0 2468 1376 1140 S 0 0.1 0:00.88 初始化
5849 根 15 0 12336 4028 668 S 0 0.4 0:00.00 apache2
8063 根 15 0 12336 4028 668 S 0 0.4 0:00.00 apache2
9732 根 16 0 8280 2728 2168 S 0 0.3 0：00.02 sshd
9746 菊科里特 18 0 8412 1444 864 S 0 0.1 0:01.10 sshd
9747 菊科里特 18 0 4576 1960 1488 S 0 0.2 0:00.24 bash
13706 chikorit 15 0 2344 1088 884 R 0 0.1 0:00.03 顶部
15745 菊科里特 15 0 12968 5108 1280 S 0 0.5 0:00.00 apache2
15751 菊科里特 15 0 72184 25m 18m S 0 2.5 0:00.37 php5-fpm
15790 chikorit 18 0 12472 4640 1192 S 0 0.4 0:00.00 apache2
15797 菊科里特 15 0 72888 23m 16m S 0 2.3 0:00.06 php5-fpm
16038 根 15 0 67772 2848 592 D 0 0.3 0:00.00 php5-fpm
16309 系统日志 18 0 24084 1316 992 S 0 0.1 0:00.07 rsyslogd
16316 根 15 0 5472 908 500 S 0 0.1 0:00.00 sshd
16326 根 15 0 2304 908 712 S 0 0.1 0:00.02 cron
17464 根 15 0 10252 7560 856 D 0 0.7 0:01.88 psad
17466 根 18 0 1684 276 208 S 0 0.0 0:00.31 psadwatchd
17559 根 18 0 11444 2020 732 S 0 0.2 0:00.47 sendmail-mta
17688 根 15 0 10252 5388 1136 S 0 0.5 0:03.81 python
17752 teamspea 19 0 44648 7308 4676 S 0 0.7 1:09.70 ts3server_linux
18098 根 15 0 12336 6380 3032 S 0 0.6 0:00.47 apache2
18099 chikorit 18 0 10368 2536 464 S 0 0.2 0:00.00 apache2
18120 ntp 15 0 4336 1316 984 S 0 0.1 0:00.87 ntpd
18379 根 15 0 12336 4028 668 S 0 0.4 0:00.00 apache2
18387 mysql 15 0 62796 36m 5864 S 0 3.6 1：43.26 mysqld
19584 根 15 0 12336 4028 668 S 0 0.4 0：00.02 apache2
22498 根 16 0 12336 4028 668 S 0 0.4 0:00.00 apache2
24260 根 15 0 67772 3612 1356 S 0 0.3 0:00.22 php5-fpm
27712 根 15 0 12336 4028 668 S 0 0.4 0:00.00 apache2
27730 根 15 0 12336 4028 668 S 0 0.4 0:00.00 apache2
30343 根 15 0 12336 4028 668 S 0 0.4 0:00.00 apache2
30366 根 15 0 12336 4028 668 S 0 0.4 0:00.00 apache2

这是截至今天的可用内存。

             已使用的、可用的、缓存的共享缓冲区总数
内存：1024 302 721 0 0 0
-/+ 缓冲区/缓存：302721
交换：0 0 0

更新：查看日志，特别是导致 CPU 峰值的 PHP5-FPM。我发现它由于某些明显的原因而出现段错误。

[2012-06-03 06:11:20] 通知：[pool www] 子进程 14132 已启动
[2012 年 6 月 3 日 06:11:25] 警告：[pool www] 子进程 13664 在启动后 53.686322 秒因信号 11 (SIGSEGV) 而退出
[2012-06-03 06:11:25] 通知：[pool www] 子进程 14328 已启动
[2012 年 6 月 3 日 06:11:25] 警告：[pool www] 子进程 14132 在启动后 4.708681 秒因信号 11 (SIGSEGV) 而退出
[2012-06-03 06:11:25] 通知：[pool www] 子进程 14329 已启动
[2012 年 6 月 3 日 06:11:58] 警告：[pool www] 子进程 14328 在启动后 32.981228 秒因信号 11 (SIGSEGV) 而退出
[2012-06-03 06:11:58] 通知：[pool www] 子进程 15745 已启动
[2012 年 6 月 3 日 06:12:25] 警告：[pool www] 子进程 15745 在启动后 27.442864 秒因信号 11 (SIGSEGV) 而退出
[2012-06-03 06:12:25] 通知：[pool www] 子进程 17446 已启动
[2012 年 6 月 3 日 06:12:25] 警告：[pool www] 子进程 14329 在启动后 60.411278 秒因信号 11 (SIGSEGV) 而退出
[2012-06-03 06:12:25] 通知：[pool www] 子进程 17447 已启动
[2012 年 6 月 3 日 06:13:02] 警告：[pool www] 子进程 17446 在启动后 36.746793 秒因信号 11 (SIGSEGV) 而退出
[2012-06-03 06:13:02] 通知：[pool www] 子进程 18133 已启动
[2012 年 6 月 3 日 06:13:48] 警告：[pool www] 子进程 17447 在启动后 82.710107 秒因信号 11 (SIGSEGV) 而退出

我认为这可能是导致问题的原因。如果这是原因，那么将其关闭并切换到 fastcgi/fcgid 可能会解决问题...但我仍然想看看是否还有其他原因导致这种情况。

答案1

我估计服务器有内存问题。这将导致容器必须等待数据来自磁盘而不是缓冲区。如果您有权访问服务器，请尝试vmstat在其上运行，而不是在容器中运行。虚拟服务器的内存管理依赖于主机服务器。我注意到的第一件事是数据中没有缓冲区、缓存或交换。这些对性能都很重要。

答案2

要查看哪个进程导致高 I/O，您可以使用dstat或iotop。

要查看 php 崩溃的原因，请确保在启动 apache 时运行ulimit -c unlimited。下次 php 崩溃时，您将看到核心转储。使用bt命令内部gdb获取崩溃的堆栈跟踪。例如

gdb /usr/bin/httpd core
(gdb) bt

看：http://www.network-theory.co.uk/articles/gccdebug.html

答案3

从表面上看，高 CPU 使用率可能是由 Wordpress 插件 Google XML Sitemap 生成器引起的。禁用该插件后，CPU 平均值大多下降。不过，还是要审核插件，删除可能占用过多 CPU 的插件。

答案4

还请检查/已检查物理磁盘子系统没有实际问题 - 重建 raid、BBU 故障、单个磁盘故障……也可能导致类似症状

相关内容