早上刚到接到前方同事电话,说线上有台服务访问延迟很高,他排查了下发现内存还很充足,cpu使用率也不是很高,单就是负载出奇的高,等我到后开始一系列的排查
1. 查看服务器资源使用情况
1.1 top
首先使用top -c查看了下,能够看到服务器cpu使用率正常,swap没有使用,内存剩余还很多,没有僵尸进程,也其他异常
#top -c
top - 11:26:23 up 364 days, 22:00, 2 users, load average: 60.13, 70.80, 71.02
Tasks: 327 total, 2 running, 325 sleeping, 0 stopped, 0 zombie
%Cpu0 : 22.9 us, 3.0 sy, 0.0 ni, 73.4 id, 0.3 wa, 0.0 hi, 0.3 si, 0.0 st
%Cpu1 : 6.0 us, 2.0 sy, 0.0 ni, 92.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 8.0 us, 2.7 sy, 0.0 ni, 89.0 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
%Cpu3 : 7.7 us, 2.3 sy, 0.0 ni, 90.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 8008668 total, 3247440 free, 2468668 used, 2292560 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 5232164 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13189 test 20 0 173660 19808 5056 R 18.2 0.2 0:06.89 php-fpm: pool www 13307 test 20 0 153120 7620 2256 S 2.6 0.1 1:47.54 nginx: worker process 13174 test 20 0 170408 17136 5156 S 2.0 0.2 0:05.99 php-fpm: pool www 13156 test 20 0 172616 18220 4784 S 1.7 0.2 0:05.98 php-fpm: pool www
......
输入1 列出每个cpu使用信息
输入P 以cpu使用率由高到低进行排序
1.2 vmstat
查看下服务器io信息
# vmstat 2
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 437072 145988 4787532 0 0 0 2 0 0 2 0 97 0 0
0 0 0 429252 145988 4787552 0 0 0 22 5032 6082 6 1 92 1 0
0 0 0 432304 145988 4787564 0 0 0 0 4637 5141 7 1 92 0 0
0 0 0 433544 145988 4787576 0 0 0 106 4385 5080 6 1 93 0 0
0 0 0 436604 145988 4787588 0 0 0 0 3570 4752 3 1 97 0 0
1 0 0 436912 145988 4788972 0 0 0 46 4866 6283 5 1 93 0 0
0 0 0 432680 145988 4788984 0 0 0 76 3882 5349 3 1 97 0 0
通过上面的输出能看到,正在运行,和睡眠的进程也没有异常,io也没什么问题,这就很奇怪,通过这一些指标看着都很正常,但是服务负载就是很高
1.3 iostat
咱们通过iostat接着排查
# iostat
Linux 3.10.0-1127.10.1.el7.x86_64 (tougao-web02) 07/15/2021 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
2.08 0.00 0.47 0.04 0.00 97.41
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
vda 0.79 0.04 8.42 1273836 265368220
意料之中,iostat也没有看出什么异常信息
1.4 ps
抱着最后的希望再试一下
ps aux |grep 'D'
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
www 1954 0.0 0.1 158272 13132 ? D Jul04 8:34 nginx: worker process
www 1955 0.1 0.1 158096 12976 ? D Jul04 18:52 nginx: worker process
www 1956 1.1 0.1 158020 13176 ? D Jul04 184:32 nginx: worker process
www 1957 0.4 0.1 158500 13352 ? D Jul04 76:12 nginx: worker process
root 10036 0.0 0.0 0 0 ? D 10:07 0:00 [10.0.4.23-mana]
www 28037 0.1 0.2 352872 19420 ? D 09:30 0:02 php-fpm: pool www
www 28038 0.0 0.1 272964 15460 ? D 09:30 0:01 php-fpm: pool www
www 28041 0.0 0.2 276044 17636 ? D 09:30 0:02 php-fpm: pool www
www 28045 0.0 0.2 276044 18572 ? D 09:30 0:01 php-fpm: pool www
www 28047 0.0 0.2 275792 17388 ? D 09:30 0:02 php-fpm: pool www
www 28050 0.1 0.2 276544 17992 ? D 09:30 0:02 php-fpm: pool www
......
状态为D 表示进程是不可唤醒的睡眠状态
看到这里大概就知道原因了,10.0.4.23是我们挂载的NFS网络存储,php和nginx都会去这里获取写入数据,咱们可以进去到NFS的挂载目录下,去编辑或者查看其中的文件试试,发现在进去cd时会有一些卡顿,vim编辑文件时这种卡顿更明显。所以到这里基本确定问题所在
2. 问题解决
快速恢复的话就是停掉php和nginx,umount nfs网络存储系统,然后重新挂载,接着重新启动php,nginx服务,至此问题临时解决
咱们要的不仅仅是解决问题,还有发生问题的原因和避免的方法
#查询服务器RPC相关信息
rpcinfo -p
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
可以看到是NFS2和NFS3混合使用。NFS2里,限制是8K,NFS3的限制取决于源代码里NFSSVC_MAXBLKSIZE的大小(/usr/include/linux/nfsd/const.h),一般也是8K。总的来说,Linux2.4内核里,NFS上限一般就是8K,如果条件允许,尽量使用Linux2.6内核,那样NFS上限可以达到32K,会爽得多。
当然,有时候不可能这么容易的确定BlockSize的大小,因为除了NFS自身上限的限制,还有诸如网络MTU等等的影响
突然不想写啦,剩下的参考此链接