昨晚一台业务机宕了，好在有负载均衡没什么影响，记录一下此次故障。
一、现象
负载高的时候监控查看是30左右，早上6点多，系统日志没找到原因，懵逼。。
图片.png
重启后负载还是很高
[root@hotel01-162 ~]# top
top - 13:55:48 up 4:56, 1 user, load average: 3.29, 3.37, 3.29
Tasks: 1680 total, 1 running, 1679 sleeping, 0 stopped, 0 zombie
Cpu0 : 6.7%us, 0.0%sy, 0.0%ni, 66.7%id, 20.0%wa, 0.0%hi, 6.7%si, 0.0%st
Cpu1 : 6.2%us, 6.2%sy, 0.0%ni, 62.5%id, 18.8%wa, 0.0%hi, 6.2%si, 0.0%st
Cpu2 : 6.7%us, 0.0%sy, 0.0%ni, 66.7%id, 26.7%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.0%us, 0.0%sy, 0.0%ni, 93.3%id, 0.0%wa, 0.0%hi, 6.7%si, 0.0%st
Cpu4 : 6.2%us, 0.0%sy, 0.0%ni, 56.2%id, 37.5%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 0.0%us, 5.9%sy, 0.0%ni, 58.8%id, 35.3%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 : 12.5%us, 12.5%sy, 0.0%ni, 75.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16466580k total, 16131992k used, 334588k free, 487060k buffers
Swap: 0k total, 0k used, 0k free, 5334900k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27338 root 20 0 18272 2624 1012 R 25.6 0.0 0:03.06 top
481 root 20 0 0 0 0 D 6.4 0.0 6:38.49 jbd2/vda1-8
2044 root 20 0 83000 3476 2572 S 6.4 0.0 4:26.28 master
2072 postfix 20 0 118m 40m 2684 S 6.4 0.3 6:27.90 qmgr
2279 nginx 20 0 58452 4776 2304 S 6.4 0.0 11:44.43 nginx
7770 nginx 20 0 452m 81m 71m S 6.4 0.5 0:44.78 php-fpm
7771 nginx 20 0 452m 80m 71m S 6.4 0.5 0:47.36 php-fpm
10678 postfix 20 0 83088 3560 2608 S 6.4 0.0 1:01.61 trivial-rewrite
14778 nginx 20 0 536m 113m 94m S 6.4 0.7 1:14.59 php-fpm
14789 nginx 20 0 452m 101m 93m S 6.4 0.6 1:18.69 php-fpm
14792 nginx 20 0 452m 99m 91m S 6.4 0.6 1:13.89 php-fpm
14793 nginx 20 0 452m 99m 91m S 6.4 0.6 1:15.19 php-fpm
29723 postfix 20 0 83224 3624 2704 S 6.4 0.0 0:00.04 cleanup
二、排查分析,利用工具快速定位
- top分析
根据top，可以看出php-fpm比例很高，而且通过%us占用可以看出用户占用cpu很高，还有一个就是qmgr进程 系统邮件用户挺忙，那是他引起的负载高吗？不急继续分析。 - vmstat
从下方参数介绍对比可以看出，
1.等待资源进程数较多，参考procs b选项
2.磁盘频繁写入，io繁忙
r:列表示运行和等待cpu时间片的进程数，如果长期大于1，说明cpu不足，需要增加cpu。
b:列表示在等待资源的进程数，比如正在等待I/O、或者内存交换等。
bi:从块设备读入数据的总量（读磁盘）（每秒kb）
bo:块设备写入数据的总量（写磁盘）（每秒kb),建议bi+bo参考值为1000，如果超过1000，而且wa值较大应该考虑调整磁盘负载
wa:wa展示了io等待所占cpu的百分比，参考值为30%，超过即io繁忙
[root@hotel01-162 ~]# vmstat 1 定位load问题
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 1 0 195704 487832 5316192 0 0 239 1386 159 50 6 5 75 15 0
0 1 0 195332 487836 5316712 0 0 500 8556 17851 16244 4 3 79 14 0
0 2 0 191984 487840 5316760 0 0 280 9592 21260 19762 4 3 82 10 0
1 1 0 190224 487840 5317548 0 0 548 9828 21580 19883 4 4 76 16 0
3 1 0 194348 487848 5317568 0 0 408 8816 22221 19955 5 4 77 14 0
0 2 0 192884 487868 5317796 0 0 320 9392 25902 24860 6 5 79 11 0
0 1 0 191148 487872 5318480 0 0 428 8660 21080 19311 5 3 75 17 0
1 1 0 188684 487872 5318508 0 0 464 9800 18898 18263 4 4 78 14 0
0 2 0 185552 487880 5318880 0 0 56 8292 19263 18062 5 3 81
- iostat 定位哪个磁盘在忙
分析可以看出vda盘符很忙，频繁写入。
util:如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘
[root@hotel01-162 ~]# iostat -x 1
Linux 2.6.32-696.6.3.el6.x86_64 (hotel01-162) 2019年08月20日 _x86_64_ (8 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
5.61 0.00 4.65 14.55 0.00 75.20
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 2.62 2060.25 31.31 651.42 368.81 21688.25 32.31 3.83 5.61 14.11 5.20 1.43 97.31
vdb 0.10 59.16 96.25 3.65 3252.15 502.84 37.58 0.60 5.99 4.92 34.16 0.24 2.39
avg-cpu: %user %nice %system %iowait %steal %idle
5.14 0.00 3.63 15.29 0.00 75.94
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 1696.00 39.00 522.00 336.00 17736.00 32.21 1.86 3.32 13.21 2.59 1.76 98.50
vdb 0.00 0.00 5.00 0.00 56.00 0.00 11.20 0.00 0.00 0.00 0.00 0.00 0.00
avg-cpu: %user %nice %system %iowait %steal %idle
4.01 0.00 3.88 11.15 0.00 80.95
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 1388.00 7.00 491.00 56.00 14848.00 29.93 1.34 2.81 18.00 2.60 1.91 95.30
vdb 0.00 13.00 3.00 15.00 24.00 224.00 13.78 0.03 1.83 0.00 2.20 0.17 0.30
- lsof 定位磁盘写入问题
可以直接用 lsof 指定相关目录，看哪些程序在操作。
比如：lsof /
sendmail 14120 root mem REG 252,1 106160 657093 /usr/lib64/libsasl2.so.2.0.23
sendmail 14120 root mem REG 252,1 596864 131096 /lib64/libm-2.12.so
sendmail 14120 root mem REG 252,1 1584904 658287 /usr/lib64/mysql/libmysqlclient.so.16.0.0
sendmail 14120 root mem REG 252,1 183080 131171 /lib64/libpcre.so.0.0.1
sendmail 14120 root mem REG 252,1 60512 131267 /lib64/liblber-2.4.so.2.10.3
sendmail 14120 root mem REG 252,1 330896 131269 /lib64/libldap-2.4.so.2.10.3
sendmail 14120 root mem REG 252,1 159312 131076 /lib64/ld-2.12.so
postdrop 14123 root mem REG 252,1 44472 131116 /lib64/librt-2.12.so
postdrop 14123 root mem REG 252,1 20024 131094 /lib64/libdl-2.12.so
postdrop 14123 root mem REG 252,1 88600 131139 /lib64/libz.so.1.2.3
postdrop 14123 root mem REG 252,1 40872 131092 /lib64/libcrypt-2.12.so
postdrop 14123 root mem REG 252,1 244624 131493 /lib64/libnspr4.so
postdrop 14123 root mem REG 252,1 18720 131494 /lib64/libplc4.so
postdrop 14123 root mem REG 252,1 14528 131495 /lib64/libplds4.so
postdrop 14123 root mem REG 252,1 183512 656960 /usr/lib64/libnssutil3.so
postdrop 14123 root mem REG 252,1 1316592 658053 /usr/lib64/libnss3.so
postdrop 14123 root mem REG 252,1 181176 658048 /usr/lib64/libsmime3.so
postdrop 14123 root mem REG 252,1 311736 660060 /usr/lib64/libssl3.so
postdrop 14123 root mem REG 252,1 1924768 131088 /lib64/libc-2.12.so
postdrop 14123 root mem REG 252,1 111440 131114 /lib64/libresolv-2.12.so
postdrop 14123 root mem REG 252,1 113904 131098 /lib64/libnsl-2.12.so
postdrop 14123 root mem REG 252,1 1525560 131161 /lib64/libdb-
查看进程
[root@hotel01-162 ~]# ps -ef|grep sendmail|wc -l
290
[root@hotel01-162 ~]# ps -ef|grep postdrop|wc -l
290
[root@hotel01-162 ~]#
三、解决
已经定位问题，是由于邮件系统频繁写入导致。
经过lsof输出，写入较多的是邮件系统，警察看/var/log/maillog信息，看到有一个废弃的域名，之前用来做监控系统的，有个短信邮件的功能是根据计划任务去每分钟执行发送的，由于发送失败频繁发送系统邮件，导致io占用排队。
[root@hotel01-162 maildrop]# top
top - 15:57:06 up 6:57, 2 users, load average: 0.50, 2.04, 9.68
Tasks: 1184 total, 1 running, 1183 sleeping, 0 stopped, 0 zombie
Cpu0 : 10.3%us, 4.1%sy, 0.0%ni, 63.1%id, 20.2%wa, 0.0%hi, 2.3%si, 0.0%st
Cpu1 : 10.1%us, 3.9%sy, 0.0%ni, 71.5%id, 12.1%wa, 0.0%hi, 2.4%si, 0.0%st
Cpu2 : 7.5%us, 3.0%sy, 0.0%ni, 79.7%id, 7.7%wa, 0.0%hi, 2.1%si, 0.0%st
Cpu3 : 7.0%us, 2.9%sy, 0.0%ni, 82.2%id, 5.3%wa, 0.0%hi, 2.6%si, 0.0%st
Cpu4 : 2.2%us, 2.7%sy, 0.0%ni, 54.4%id, 40.5%wa, 0.0%hi, 0.2%si, 0.0%st
Cpu5 : 1.7%us, 3.4%sy, 0.0%ni, 65.7%id, 29.0%wa, 0.0%hi, 0.2%si, 0.0%st
Cpu6 : 1.8%us, 2.3%sy, 0.0%ni, 94.2%id, 1.4%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu7 : 1.6%us, 2.5%sy, 0.0%ni, 93.9%id, 1.2%wa, 0.0%hi, 0.8%si, 0.0%st
Mem: 16466580k total, 16287848k used, 178732k free, 400k buffers
Swap: 0k total, 0k used, 0k free, 594720k cached
四、建议
请不要忽略在我们操作服务器时提示的邮件报错，遇到问题多借助系统工具能解决大多数问题。
You have new mail in /var/spool/mail/root