现象
打开一个后台的测试页面刷新需要好几秒～ 简直就是慢！！虽然是测试环境但是配置不低，不应该出现这种问题，借此机会边记录边查询问题所在,过程就是记录几个工具的使用。
思路
问题解决后，我觉得有必要写一下当时怎么想的，虽然问题很2：
1.我排查了load，内存等基础信息，为啥？
当时发现网页卡就一门子钻进测试服务器里了，因为我是运维哈哈，平时机器装的东西可能比较多，所以怀疑压力可能比较大了,内存、负载一顿看，发现有问题但不至于卡顿
2.检查了数据库的压力，因为只是在页面查询的时候才出现这个问题,索性看看数据库
3.借助软件跟进了查询期间的负载情况，下方介绍细节，发现每次查询cpu、内存都在一瞬间出现吃紧的情况，貌似占用确实很大
4.借助浏览器查看发现了问题所在
以下的服务器排查就是为了记录而记录，完全和结果没啥关系，只不过记下来走的弯路，有时候往往简单的问题却被自己搞得很复杂，本次排查就是某个网页访问很慢引起的，下面是过程。
- top先看看情况
如图，可以分析出来在我刷新一项功能的时候,cpu占用非常高，而不操作的时候cpu很清闲。
图片.png
- vmstat 近一步分析一下
procs
r 列表示运行和等待cpu时间片的进程数，如果长期大于1，说明cpu不足，需要增加cpu。
b 列表示在等待资源的进程数，比如正在等待I/O、或者内存交换等。
如上面的解释，手动测试一下，看到r选项偶尔出现大于1的情况，那就是每次点击后台页面发生的，可以说明这个操作发生时cpu吃紧出现排队情况。
[root@mailvip ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 304684 859444 5030496 0 0 12 0 736 756 0 0 100 0 0
0 0 0 304684 859444 5030512 0 0 24 0 638 762 0 0 100 0 0
1 0 0 270088 859452 5030524 0 0 16 60 1136 843 3 0 96 0 0
1 0 0 163432 859460 5030544 0 0 20 0 3019 1153 7 1 91 0 0
1 0 0 167896 859464 4644588 0 0 24 16 1987 861 10 4 86 0 0
1 0 0 166036 859472 4644412 0 0 296 12 1802 850 13 0 87 0 0
1 0 0 162192 859468 4550304 0 0 32 0 1831 856 12 1 87 0 0
2 0 0 163700 859628 4512828 0 0 188 160 3400 1242 16 7 77 0 0
0 0 0 816628 859628 4515496 0 0 132 0 1822 835 6 1 92 0 0
0 0 0 817124 859644 4515632 0 0 16 64 1495 810 2 0 98 0 0
3 2 0 815512 859672 4515684 0 0 84 4 4282 1450 24 3 71 2 0
0 0 0 876908 859684 4453164 0 0 152 0 2240 1050 8 2 89 1 0
0 0 0 876660 859692 4453300 0 0 84 124 645 721 0 0 100 0 0
0 0 0 876892 859696 4453096 0 0 16 0 885 831 0 0 99 0 0
0 0 0 876260 859708 4453372 0 0 16 144 3079 1640 9 7 85 0 0
0 0 0 876852 859712 4453124 0 0 12 140 1058 874 0 1 99 0 0
0 0 0 876904 859720 4453136 0 0 12 0 1060 910 0 0 99 0 0
0 0 0 876804 859720 4453168 0 0 36 0 897 835 0 0 100 0 0
0 0 0 876484 859800 4453228 0 0 20 0 657 755 0 0 100 0 0
1 0 0 876484 859804 4453248 0 0 20 0 1231 819 5 0 95 0 0
1 0 0 695460 859804 4453264 0 0 16 0 2917 1229 6 2 92 0 0
1 0 0 388080 859808 4453268 0 0 4 0 1851 773 10 3 87 0 0
1 0 0 387592 859836 4453252 0 0 16 7736 1754 811 13 0 87 1 0
1 0 0 328144 859836 4453292 0 0 12 4 1682 754 10 2 87 0 0
1 0 0 338192 859848 4507284 0 0 20 0 2167 1021 8 6 87 0 0
5 0 0 822920 859852 4507108 0 0 8 0 2648 1032 13 1 86 0 0
- strace分析服务器进程占用
brk是负责内存分配的，我服务器内存占用确实存在一些问题，但不是目前的问题所在。
[root@mailvip ~]# strace -c -p $(pgrep -n php-fpm)
Process 18550 attached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
57.89 0.041970 139 302 brk
14.14 0.010252 1 16174 sendto
13.63 0.009881 1 18138 poll
6.65 0.004818 0 17419 recvfrom
3.59 0.002603 3 912 read
1.23 0.000891 4 240 3 lstat
0.79 0.000573 1 1107 307 stat
0.66 0.000479 1 745 write
0.51 0.000369 3 125 78 connect
0.18 0.000133 1 127 getcwd
0.17 0.000120 0 736 gettimeofday
0.15 0.000106 1 161 open
0.11 0.000083 1 151 fstat
0.07 0.000054 1 43 lseek
0.06 0.000047 0 351 fcntl
0.06 0.000046 1 60 chdir
0.06 0.000041 0 125 socket
0.05 0.000034 1 30 rt_sigprocmask
0.00 0.000000 0 316 close
0.00 0.000000 0 96 mmap
0.00 0.000000 0 96 munmap
0.00 0.000000 0 30 rt_sigaction
0.00 0.000000 0 47 ioctl
0.00 0.000000 0 22 22 access
0.00 0.000000 0 134 setitimer
0.00 0.000000 0 30 accept
0.00 0.000000 0 60 shutdown
0.00 0.000000 0 180 setsockopt
0.00 0.000000 0 47 getsockopt
0.00 0.000000 0 11 unlink
0.00 0.000000 0 60 times
0.00 0.000000 0 11 utime
0.00 0.000000 0 180 clock_gettime
------ ----------- ----------- --------- --------- ----------------
100.00 0.072500 58266 410 total
-
浏览器分析，直接看图
如图：一个html，大小居然达到了60多MB，不慢就怪了..
发现问题后，查看源代码保存本地查看，发现里面获取了很多测试数据，这个数据量特别大，导致加载本地页面的时候，会去数据库查询这些数据，找研发修复这个问题，加了判断条件后就恢复了。
image.png
图片.png
-
解决
恢复后：虽然还有点大，但是已经明显有所下降，这个页面本来数据就很多
image.png
总结：
在排查一些网站很慢的情况不一定要去服务器里面查问题，有时候页面上告诉你的问题也许会更直观，可以直奔主题参考网页访问哪里占用较高，根据此处来判断。
网友评论