(补注:本文作者 Brendan Gregg, 他是 Oracle/Linux系统性能分析方面的大牛。)
为了解决性能问题,你登入了一台Linux服务器,在最开始的一分钟内需要查看什么?
在Netflix我们有一个庞大的EC2 Linux集群,还有非常多的性能分析工具来监控和调查它的性能。其中包括用于云监控的Atlas,用于实例按需分析的Vector。即使这些工具帮助我们解决了大多数问题,我们有时还是得登入Linux实例,运行一些标准的Linux性能工具来解决问题。
在这篇文章里,Netflix Performance Engineering团队将使用居家常备的Linux标准命令行工具,演示在性能调查最开始的60秒里要干的事,
最开始的60秒……
运行下面10个命令,你可以在60秒内就对系统资源的使用情况和进程的运行状况有大体上的了解。无非是先查看错误信息和饱和指标,再看下资源的使用量。这里“饱和”的意思是,某项资源供不应求,已经造成了请求队列的堆积,或者延长了等待时间。
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
1
2
3
4
5
6
7
8
9
10
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
有些命令需要你安装sysstat包。(译注:指mpstat, pidstat, iostat和sar,用包管理器直接安装sysstat即可) 这些命令所提供的指标能够帮助你实践USE方法:这是一种用于定位性能瓶颈的方法论。你可以以此检查所有资源(CPU,内存,硬盘,等等)的使用量,是否饱和,以及是否存在错误。同时请留意上一次检查正常的时刻,这将帮助你减少待分析的对象,并指明调查的方向。(译注:USE方法,就是检查每一项资源的使用量(utilization)、饱和(saturation)、错误(error))
接下来的章节里我们将结合实际例子讲解这些命令。如果你想了解更多的相关信息,请查看它们的man page。
1. uptime
$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
1
2
$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
这个命令显示了要运行的任务(进程)数,通过它能够快速了解系统的平均负载。在Linux上,这些数值既包括正在或准备运行在CPU上的进程,也包括阻塞在uninterruptible I/O(通常是磁盘I/O)上的进程。它展示了资源负载(或需求)的大致情况,不过进一步的解读还有待其它工具的协助。对它的具体数值不用太较真。
最右的三个数值分别是1分钟、5分钟、15分钟系统负载的移动平均值。它们共同展现了负载随时间变动的情况。举个例子,假设你被要求去检查一个出了问题的服务器,而它最近1分钟的负载远远低于15分钟的负载,那么你很可能已经扑了个空。
在上面的例子中,负载均值最近呈上升态势,其中1分钟值高达30,而15分钟值仅有19。这种现象有许多种解释,很有可能是对CPU的争用;该系列的第3个和第4个命令——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 counters.
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 counters.
这个命令显示了最新的10个系统信息,如果有的话。注意会导致性能问题的错误信息。上面的例子里就包括对过多占用内存的某进程的死刑判决,还有丢弃TCP请求的公告。
不要漏了这一步!检查dmesg总是值得的。
3. vmstat 1
$ 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(8),是“virtual memory stat”的简称,几十年前就已经包括在BSD套件之中,一直以来都是居家常备的工具。它会逐行输出服务器关键数据的统计结果。
通过指定1作为vmstat的输入参数,它会输出每一秒内的统计结果。(在我们当前使用的)vmstat输出的第一行数据是从启动到现在的平均数据,而不是前一秒的数据。所以我们可以跳过第一行,看看后面几行的情况。
检查下面各列:
r:等待CPU的进程数。该指标能更好地判定CPU是否饱和,因为它不包括I/O。简单地说,r值高于CPU数时就意味着饱和。
free:空闲的内存千字节数。如果你数不清有多少位,就说明系统内存是充足的。接下来要讲到的第7个命令,free -m,能够更清楚地说明空闲内存的状态。
si,so:Swap-ins和Swap-outs。如果它们不为零,意味着内存已经不足,开始动用交换空间的存粮了。
us,sy,id,wa,st:它们是所有CPU的使用百分比。它们分别表示user time,system time(处于内核态的时间),idle,wait I/O和steal time(被其它租户,或者是租户自己的Xen隔离设备驱动域(isolated driver domain),所占用的时间)。
通过相加us和sy的百分比,你可以确定CPU是否处于忙碌状态。一个持续不变的wait I/O意味着瓶颈在硬盘上,这种情况往往伴随着CPU的空闲,因为任务都卡在磁盘I/O上了。你可以把wait I/O当作CPU空闲的另一种形式,它额外给出了CPU空闲的线索。
I/O处理同样会消耗系统时间。一个高于20%的平均系统时间,往往值得进一步发掘:也许系统花在I/O的时太长了。
在上面的例子中,CPU基本把时间花在用户态里面,意味着跑在上面的应用占用了大部分时间。此外,CPU平均使用率在90%之上。这不一定是个问题;检
为了解决性能问题,你登入了一台Linux服务器,在最开始的一分钟内需要查看什么?
在Netflix我们有一个庞大的EC2 Linux集群,还有非常多的性能分析工具来监控和调查它的性能。其中包括用于云监控的Atlas,用于实例按需分析的Vector。即使这些工具帮助我们解决了大多数问题,我们有时还是得登入Linux实例,运行一些标准的Linux性能工具来解决问题。
在这篇文章里,Netflix Performance Engineering团队将使用居家常备的Linux标准命令行工具,演示在性能调查最开始的60秒里要干的事,
最开始的60秒……
运行下面10个命令,你可以在60秒内就对系统资源的使用情况和进程的运行状况有大体上的了解。无非是先查看错误信息和饱和指标,再看下资源的使用量。这里“饱和”的意思是,某项资源供不应求,已经造成了请求队列的堆积,或者延长了等待时间。
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
1
2
3
4
5
6
7
8
9
10
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
有些命令需要你安装sysstat包。(译注:指mpstat, pidstat, iostat和sar,用包管理器直接安装sysstat即可) 这些命令所提供的指标能够帮助你实践USE方法:这是一种用于定位性能瓶颈的方法论。你可以以此检查所有资源(CPU,内存,硬盘,等等)的使用量,是否饱和,以及是否存在错误。同时请留意上一次检查正常的时刻,这将帮助你减少待分析的对象,并指明调查的方向。(译注:USE方法,就是检查每一项资源的使用量(utilization)、饱和(saturation)、错误(error))
接下来的章节里我们将结合实际例子讲解这些命令。如果你想了解更多的相关信息,请查看它们的man page。
1. uptime
$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
1
2
$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
这个命令显示了要运行的任务(进程)数,通过它能够快速了解系统的平均负载。在Linux上,这些数值既包括正在或准备运行在CPU上的进程,也包括阻塞在uninterruptible I/O(通常是磁盘I/O)上的进程。它展示了资源负载(或需求)的大致情况,不过进一步的解读还有待其它工具的协助。对它的具体数值不用太较真。
最右的三个数值分别是1分钟、5分钟、15分钟系统负载的移动平均值。它们共同展现了负载随时间变动的情况。举个例子,假设你被要求去检查一个出了问题的服务器,而它最近1分钟的负载远远低于15分钟的负载,那么你很可能已经扑了个空。
在上面的例子中,负载均值最近呈上升态势,其中1分钟值高达30,而15分钟值仅有19。这种现象有许多种解释,很有可能是对CPU的争用;该系列的第3个和第4个命令——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 counters.
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 counters.
这个命令显示了最新的10个系统信息,如果有的话。注意会导致性能问题的错误信息。上面的例子里就包括对过多占用内存的某进程的死刑判决,还有丢弃TCP请求的公告。
不要漏了这一步!检查dmesg总是值得的。
3. vmstat 1
$ 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(8),是“virtual memory stat”的简称,几十年前就已经包括在BSD套件之中,一直以来都是居家常备的工具。它会逐行输出服务器关键数据的统计结果。
通过指定1作为vmstat的输入参数,它会输出每一秒内的统计结果。(在我们当前使用的)vmstat输出的第一行数据是从启动到现在的平均数据,而不是前一秒的数据。所以我们可以跳过第一行,看看后面几行的情况。
检查下面各列:
r:等待CPU的进程数。该指标能更好地判定CPU是否饱和,因为它不包括I/O。简单地说,r值高于CPU数时就意味着饱和。
free:空闲的内存千字节数。如果你数不清有多少位,就说明系统内存是充足的。接下来要讲到的第7个命令,free -m,能够更清楚地说明空闲内存的状态。
si,so:Swap-ins和Swap-outs。如果它们不为零,意味着内存已经不足,开始动用交换空间的存粮了。
us,sy,id,wa,st:它们是所有CPU的使用百分比。它们分别表示user time,system time(处于内核态的时间),idle,wait I/O和steal time(被其它租户,或者是租户自己的Xen隔离设备驱动域(isolated driver domain),所占用的时间)。
通过相加us和sy的百分比,你可以确定CPU是否处于忙碌状态。一个持续不变的wait I/O意味着瓶颈在硬盘上,这种情况往往伴随着CPU的空闲,因为任务都卡在磁盘I/O上了。你可以把wait I/O当作CPU空闲的另一种形式,它额外给出了CPU空闲的线索。
I/O处理同样会消耗系统时间。一个高于20%的平均系统时间,往往值得进一步发掘:也许系统花在I/O的时太长了。
在上面的例子中,CPU基本把时间花在用户态里面,意味着跑在上面的应用占用了大部分时间。此外,CPU平均使用率在90%之上。这不一定是个问题;检