现在有很多用于Linux的性能工具，但它们是如何融合在一起的，我们什么时候使用它们？在Velocity 2015上，我给出了一个关于Linux性能工具的90分钟教程。之前我已经谈过这个话题，但是考虑到90分钟的时间段，我可以包含更多的方法，工具和现场演示，使其成为我所做主题的最完整的演示。视频和幻灯片如下。
第1部分（youtube）（54分钟）。
第2部分（youtube）（45分钟）。
幻灯片（slideshare）。
在本教程中，我总结了传统和高级性能工具，包括：top，ps，vmstat，iostat，mpstat，free，strace，tcpdump，netstat，nicstat，pidstat，swapon，lsof，sar，ss，iptraf，iotop，slaptop，pcstat ，tiptop，rdmsr，lmbench，fio，pchar，perf_events，ftrace，SystemTap，ktap，sysdig和eBPF;并参考更多。我还包括可观察性，sar，基准测试和调整（包括上面的图像）的更新工具图。
本教程可以与广泛的读者共享 - 任何从事Linux系统工作的人 - 都可以作为免费的Linux性能工具速成课程。我希望人们喜欢它并觉得它有用。这是播放列表。
在Netflix，我们有用于全云监控的Atlas，以及用于按需实例分析的Vector。很多时候我们不需要直接登录实例，但是当我们这样做时，本教程将介绍我们使用的工具。
您登录到有性能问题的Linux服务器：您在第一分钟检查什么？
在Netflix，我们拥有庞大的EC2 Linux云，以及众多性能分析工具来监控和调查其性能。 其中包括用于全云监控的Atlas和用于按需实例分析的Vector。 尽管这些工具可以帮助我们解决大多数问题，但我们有时需要登录到实例并运行一些标准的Linux性能工具。
前60秒：总结
在本文中，Netflix性能工程团队将使用标准的Linux工具向您展示在命令行中进行优化性能调查的前60秒。 在60秒内，您可以通过运行以下十个命令，获得系统资源使用情况和正在运行的进程的高级概念。 查找错误和饱和度指标（saturation metrics），因为它们都易于解释，然后是资源利用率。 饱和度（Saturation）是资源负载超过其处理能力的地方，并且可以作为请求队列的长度或等待的时间暴露出来。
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软件包。 这些命令公开的指标将帮助您完成一些USE方法：用于查找性能瓶颈的方法。 这涉及检查所有资源（CPU，内存，磁盘，e.t.c）的利用率（utilization），饱和度（saturation）和错误度量（error metrics）标准。 同时要注意检查并排除资源的时候，因为通过消除（elimination）这个过程缩小了研究对象的范围，并且指导任何后续调查（follow on investigation）。
以下部分总结了这些命令，并以生产系统为例。 有关这些工具的更多信息，请参阅他们的手册页。
1. uptime
$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
这是查看负载平均值的快速方法，它表示想要运行的任务（进程）的数量。在Linux系统上，这些数字包括想要在CPU上运行的进程以及在不可中断的I / O（通常是磁盘I / O）中被阻塞的进程。这提供了资源负载（或需求）的高级概念，但是没有其他工具就无法正确理解。值得快速浏览一下。
这三个数字是指数衰减移动总和平均值（exponentially damped moving sum averages）在1分钟，5分钟和15分钟的常数。这三个数字让我们了解负载如何随时间而变化。例如，如果您被要求检查问题服务器，并且1分钟的值比15分钟的值低得多，那么您可能已经登录太晚而错过了该问题。
在上面的例子中，负载平均值显示最近的增加，1分钟的值为30，而15分钟的值为19。数字这么大意味着很多东西：可能是CPU需求; vmstat或mpstat将会确认，这是本序列命令3和命令4。
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.
这可以查看最后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
虚拟内存统计数据的简称，vmstat（8）是一种常用的工具（几十年前首次为BSD创建）。它在每行上打印关键服务器统计信息的摘要。
vmstat运行的参数为1，打印一秒摘要。第一行输出（在此版本的vmstat中）有一些列显示引导后的平均值，而不是前一秒。现在，跳过第一行，除非你想学习和记住哪一列是哪一列。
要检查的列：
r：在CPU上运行并等待轮换的进程数量。这比确定CPU饱和度的负载平均值提供了更好的信号，因为它不包含I / O。可以这么理解：大于CPU计数的“r”值就意味着饱和（saturation）。
free：以千字节为单位的可用内存。如果要计数的位数太多，则有足够的空闲内存。包含在命令7中的“free -m”命令更好地解释了可用内存的状态。
si，so：交换和换出。如果这些不是零，则表示内存不足。
us，sy，id，wa，st：这些是所有CPU平均CPU时间的细分。它们是用户时间（user time），系统时间（ system time）（内核），空闲（idle），等待I / O（wait I/O）和被盗时间（stolen time）（由其他客人，或者对于Xen而言，客户自己的隔离驱动程序域（isolated driver domain））。
CPU时间细分将通过将用户+系统时间加和来确认CPU是否繁忙。等待I / O的持续程度指向磁盘瓶颈;这是CPU空闲的地方，因为任务被阻塞等待挂起的磁盘I / O。您可以将等待I / O视为另一种形式的CPU闲置，这样可以为他们为什么闲置提供线索。
系统时间对于I / O处理是必需的。高系统时间的平均值超过20％可能会让人感兴趣进一步探索：内核可能无效处理I / O。
在上面的例子中，CPU时间几乎全部在用户级别，而是指向应用程序级别的使用。 CPU的平均使用率也超过90％。这不一定是个问题;使用“r”列检查饱和度。
