60秒内分析linux性能(上)

来源:互联网 时间:2015-12-11

原文地址:http://techblog.netflix.com/2015/11/linux-performance-analysis-in-60s.html

当你登陆一台有性能问题的linux服务器的时候,什么是你第一项检查的内容?

babababa

大体情况

在60s内,我们可以通过如下的10条命令来获取当前系统的情况,从而达到对所在服务器情况的一个了解

命令列表:

uptimedmesg | tailvmstat 1mpstat -P ALL 1pidstat 1iostat -xz 1free -msar -n DEV 1sar -n TCP,ETCP 1top uptimedmesg|tailvmstat1mpstat-PALL1pidstat1iostat-xz1free-msar-nDEV1sar-nTCP,ETCP1top

1. uptime

23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02

这是一个比较快捷的方式查看我们的load情况,结果暗示了系统中等待运行的任务,当然,这些数值不光包含等待运行的任务,还包括因为I/O中断的进程,这个结果只是一个总体上的值,我们如果想要知道具体的值,就需要借助其它工具来分析,但是这个工具从一个较高的层面了解负载load还是不错的

三个数值分别为1分钟,5分钟,15分钟内系统的平均负载,这3个数值能告诉我们系统负载是如何变化的,比如,你发现1分钟的负载远比15分钟的负载低,那么说明你可能已经错过了这个问题

在上边的例子中,这是一个增长的趋势,最近1一分钟负载为30,而15分钟的值为19,负载这么高说明可能存在一些CPU的需求(太多),vmstat,mpstat 能够确定具体的原因,具体的我们会在下边提到

2. dmesg | tail

$ dmesg | tail[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0[...][1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP co $dmesg|tail[1880957.563150]perlinvokedoom-killer:gfp_mask=0x280da,order=0,oom_score_adj=0[...][1880957.563400]Outofmemory:Killprocess18694(perl)score246orsacrificechild[1880957.563408]Killedprocess18694(perl)total-vm:1972392kB,anon-rss:1953348kB,file-rss:0kB[2320864.954447]TCP:PossibleSYNfloodingonport7001.Droppingrequest. CheckSNMPco

这条命令会显示最新的10条系统命令,我们要重点查看其中的error信息,这些错误信息可能就是导致性能问题的元凶

本例子中出现了oom-killer(Out of memory)和TCP 请求被抛弃

3. vmstat 1

$ vmstat 1procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 032 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 032 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 032 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 032 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0^C $vmstat1procs---------memory-------------swap-------io-----system--------cpu-----r bswpd free buff cache si so bi bo in csussyidwast34 0 0200889792 73708591828 0 0 0 5 6 1096 1 3 0 032 0 0200889920 73708591860 0 0 0 59213284428298 1 1 0 032 0 0200890112 73708591860 0 0 0 09501215499 1 0 0 032 0 0200889568 73712591856 0 0 0 4811900245999 0 0 0 032 0 0200890208 73712591860 0 0 0 015898484098 1 1 0 0^C

vmstat 是virtual memory stat 的缩写(虚拟内存状况),vmstat是一个非常常见的工具,他能够提供给我们一些关键的服务器统计数据,每行代表一个

在我们的例子中,我们使用了一个参数1,就是1s刷新一次数据,我们需要排查的数据为:r:运行队列,即有多少进程被分配到了cpu(当然包含了分配了但是在等待的进程),这个值提供了比load更好的对cpu情况的解释,因为他不包含 I/O ,r的饱和值为CPU的个数

free: 表示空闲的内存,但是是kb,我们可以通过free -m 来查看更详细的,命令7更详细解释了空闲内存的情况

si,so : swap 分区的 in 和 out,如果着两个数不为0,说明服务器内存不够用了,都开始使用虚拟内存了

us, sy, id, wa, st:用户CPU时间,系统CPU时间,CPU空闲时间,等待I/0的CPU时间,和被“偷”的时间(其它用户,Xen)

整个CPU的情况能够帮助我们确定CPU是否是繁忙的,我们把us+sy得到的结果就能说明。I/O wait如果长期是一个固定的值,那么我们可能遇到了磁盘瓶颈。在等待I/O的情况下CPU是空闲的,因为他一直在等….

系统CPU时间对于I/O进程来说是必须的,如果我们有一个比较高的系统CPU时间,超过20%,那么我们可能就要研究的更加深入了,说明我们的内核处理I/O 效率低下

在上边的例子中,几乎所有的时间都是us,这就指向程序级使用,CPU平均使用率超过90%,但这并不一定是问题,我们要结合r项的值来判断

相关阅读:
Top