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

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

babababa

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

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

Default

$ 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

1 2 3 4 5 6

$ 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

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

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

3. vmstat 1

Default

$ 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 34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0 32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0 32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0 32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0 32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0 ^C

1 2 3 4 5 6 7 8 9

$ 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 34  0    0 200889792  73708 591828    0    0     0     5    6   10 96  1  3  0  0 32  0    0 200889920  73708 591860    0    0     0   592 13284 4282 98  1  1  0  0 32  0    0 200890112  73708 591860    0    0     0     0 9501 2154 99  1  0  0  0 32  0    0 200889568  73712 591856    0    0     0    48 11900 2459 99  0  0  0  0 32  0    0 200890208  73712 591860    0    0     0     0 15898 4840 98  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项的值来判断