Linux 서버에서 시스템 성능 문제를 발견하면 처음 1분 안에 어떤 시스템 표시기를 확인하게 되나요?
Netflix는 AWS에 대규모 EC2 클러스터와 다양한 성능 분석 및 모니터링 도구를 보유하고 있습니다. 예를 들어 Atlas를 사용하여 전체 플랫폼을 모니터링하고 Vector를 사용하여 EC2 인스턴스의 성능을 실시간으로 분석합니다. 이러한 도구는 이미 대부분의 문제를 해결하는 데 도움이 될 수 있지만 때로는 여전히 시스템에 로그인하고 일부 표준 Linux 성능 분석 도구를 사용하여 문제를 찾아야 합니다.
이 기사에서 Netflix 성능 엔지니어링 팀은 발견 후 처음 60초 이내에 문제를 분석하고 찾는 데 사용하는 표준 Linux 명령줄 도구 중 일부를 소개합니다.
이 60초 동안 다음 10개의 명령줄을 사용하여 시스템의 전반적인 작동과 현재 실행 중인 프로세스의 리소스 사용량을 이해할 수 있습니다.
이러한 지표 중에서 먼저 오류 및 리소스 포화율과 관련된 지표에 중점을 둔 다음 리소스 사용량을 살펴봅니다. 오류와 자원 포화율은 비교적 이해하기 쉽습니다. 포화란 처리 능력을 초과하는 리소스(예: CPU, 메모리, 디스크)의 부하를 의미합니다. 이때 관찰되는 것은 요청 대기열이 쌓이기 시작하거나 요청 대기 시간이 길어지는 것입니다.
으아악일부 명령줄은 sysstat 패키지에 따라 다릅니다. 이러한 명령줄을 사용하면 시스템 성능 문제를 분석할 때 일반적으로 사용되는 일련의 방법이나 프로세스에 익숙해질 수 있습니다. USE. 이 방법은 주로 모든 리소스(CPU, 메모리, 디스크 등)를 리소스 사용량(Utilization), 리소스 포화(Satulation), 오류(Error)의 세 가지 측면에서 분석합니다.
이 분석 과정에서 포지셔닝 범위를 좁히고 다음 포지셔닝에 대한 보다 명확한 방향을 제공하기 위해 제거한 리소스 문제에도 항상 주의를 기울여야 합니다.
다음 장에서는 각 명령줄에 대한 설명을 제공하고 프로덕션 환경의 데이터를 예로 사용합니다. 이러한 명령줄에 대한 자세한 설명을 보려면 해당 도움말 문서를 참조하세요.
이 명령을 사용하면 시스템 부하 평균을 빠르게 확인할 수 있습니다. 이 부하 값은 실행 대기 중인 작업 수를 나타내는 것으로 생각하면 됩니다. Linux 시스템의 경우 여기에는 CPU를 원하거나 사용 중인 작업과 io에서 차단된 작업이 포함됩니다. 이 명령을 사용하면 시스템의 전역 상태에 대한 일반적인 이해를 얻을 수 있지만 더 많은 정보를 얻으려면 여전히 다른 도구를 사용해야 합니다.
이 세 가지 값은 시스템이 계산한 1분, 5분, 15분의 지수가중 동적 평균으로, 간단히 이 기간 내의 평균값이라고 보면 됩니다. 이 세 가지 값을 기반으로 시간이 지남에 따라 시스템 부하가 어떻게 변하는지 이해할 수 있습니다. 예를 들어 지금 시스템에 문제가 있는데 이 세 가지 값을 확인해보니 1분의 부하 값이 15분의 부하 값보다 훨씬 작은 것을 발견했다면 아마 시점을 놓친 것일 겁니다. 시스템 문제.
위 예시에서 평균 부하량은 1분에 30을 보여주고 있는데, 이는 15분에 19가 넘는 수치입니다. 로드가 증가하는 데에는 여러 가지 이유가 있습니다. CPU가 충분히 사용되지 않았을 수 있으며 문제가 있는 곳을 vmstat 또는 mpstat에서 추가로 확인할 수 있습니다.
이 명령은 최신 시스템 로그를 표시합니다. 여기서는 주로 성능 문제를 일으킬 수 있는 시스템 오류가 있는지 살펴봅니다. 위의 예에는 oom-killer 및 TCP 패킷 손실이 포함되어 있습니다.
이 단계를 건너뛰지 마세요. dmesg는 항상 살펴볼 가치가 있습니다.
vmstat는 가상 메모리와 CPU의 일부 조건을 보여줍니다. 위의 예에서 명령줄의 1은 1초마다 표시한다는 의미입니다. 이 버전의 vmstat에서 첫 번째 줄은 이 시작 이후의 다양한 표시기를 나타냅니다. 첫 번째 줄은 일시적으로 무시할 수 있습니다.
확인할 지표:
把用户态 CPU 时间（us）和内核态 CPU 时间（sy）加起来，我们可以进一步确认 CPU 是否繁忙。等待 IO 的时间（wa）高的话，表示磁盘是瓶颈；注意，这个也被包含在空闲时间里面(id)， CPU 这个时候也是空闲的，任务此时阻塞在磁盘 IO 上了。你可以把等待 IO 的时间(wa)看做另一种形式的 CPU 空闲，它可以告诉你 CPU 为什么是空闲的。
系统处理 IO 的时候，肯定是会消耗内核态时间(sy)的。如果内核态时间较多的话，比如超过 20%，我们需要进一步分析，也许内核对 IO 的处理效率不高。
在上面这个例子里，CPU 时间大部分都消耗在了用户态，表明主要是应用层的代码在使用 CPU。CPU 利用率（us + sy）也超过了 90%，这不一定是一个问题;我们可以通过 r 和 CPU 个数确定 CPU 的饱和度。
$ mpstat -P ALL 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78 07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99 07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00 07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03 [...]
这个命令把每个 CPU 的时间都打印出来，可以看看 CPU 对任务的处理是否均匀。比如，如果某一单个 CPU 使用率很高的话，说明这是一个单线程应用。
$ pidstat 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 07:41:02 PM UID PID %usr %system %guest %CPU CPU Command 07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0 07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave 07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java 07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java 07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java 07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat 07:41:03 PM UID PID %usr %system %guest %CPU CPU Command 07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave 07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java 07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java 07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass 07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat ^C
pidstat 和 top 很像，不同的是它可以每隔一个间隔打印一次，而不是像 top 那样每次都清屏。这个命令可以方便地查看进程可能存在的行为模式，你也可以直接 copy past，可以方便地记录随着时间的变化，各个进程运行状况的变化。
上面的例子说明有 2 个 Java 进程消耗了大量 CPU。这里的 %CPU 表明的是对所有 CPU 的值，比如 1591% 标识这个 Java 进程几乎消耗了 16 个 CPU。
$ iostat -xz 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 x86_64 (32 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 73.96 0.00 3.73 0.03 0.06 22.21 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util xvda 0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09 xvdb 0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25 xvdc 0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26 dm-0 0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04 dm-1 0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00 dm-2 0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23
iostat 是理解块设备(磁盘)的当前负载和性能的重要工具。几个指标的含义：
如果这个块设备是一个逻辑块设备，这个逻辑快设备后面有很多物理的磁盘的话，100% 利用率只能表明有些 IO 的处理时间达到了 100%;后端的物理磁盘可能远远没有达到饱和状态，可以处理更多的负载。
还有一点需要注意的是，较差的磁盘 IO 性能并不一定意味着应用程序会有问题。应用程序可以有许多方法执行异步 IO，而不会阻塞在 IO 上面;应用程序也可以使用诸如预读取，写缓冲等技术降低 IO 延迟对自身的影响。
$ free -m total used free shared buffers cached Mem: 245998 24545 221453 83 59 541 -/+ buffers/cache: 23944 222053 Swap:
右边的两列显式：
我们只是想要检查这些不接近零的大小，其可能会导致更高磁盘 I/O(使用 iostat 确认)，和更糟糕的性能。上面的例子看起来还不错，每一列均有很多 M 个大小。
比起第一行，-/+ buffers/cache 提供的内存使用量会更加准确些。Linux 会把暂时用不上的内存用作缓存，一旦应用需要的时候就立刻重新分配给它。所以部分被用作缓存的内存其实也算是空闲的内存。为了解释这一点， 甚至有人专门建了个网站：http://www.linuxatemyram.com/。
如果使用 ZFS 的话，可能会有点困惑。ZFS 有自己的文件系统缓存，在 free -m 里面看不到;系统看起来空闲内存不多了，但是有可能 ZFS 有很多的缓存可用。
$ sar -n DEV 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00 12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00 12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00 12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00 12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 ^C
这个工具可以查看网络接口的吞吐量：rxkB/s 和 txkB/s 可以测量负载，也可以看是否达到网络流量限制了。在上面的例子里，eth0 的吞吐量达到了大约 22 Mbytes/s，差不多 176 Mbits/sec ，比 1 Gbit/sec 还要少很多。
这个例子里也有 %ifutil 标识设备利用率，我们也用 Brenan 的 nicstat tool 测量。和 nicstat 一样，这个设备利用率很难测量正确，上面的例子里好像这个值还有点问题。
$ sar -n TCP,ETCP 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 12:17:19 AM active/s passive/s iseg/s oseg/s 12:17:20 AM 1.00 0.00 10233.00 18846.00 12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s 12:17:20 AM 0.00 0.00 0.00 0.00 0.00 12:17:20 AM active/s passive/s iseg/s oseg/s 12:17:21 AM 1.00 0.00 8359.00 6039.00 12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s 12:17:21 AM 0.00 0.00 0.00 0.00 0.00 ^C
这是对 TCP 重要指标的一些概括，包括：
重传表示网络或者服务器的问题。也许是网络不稳定了，也许是服务器负载过重开始丢包了。上面这个例子表示每秒只有 1 个新连接建立。
$ top top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92 Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie %Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java 4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave 66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top 5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java 4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java 1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
top 命令涵盖了我们前面讲述的许多指标。我们可以用它来看和我们之前查看的结果有没有很大的不同，如果有的话，那表示系统的负载在变化。
top 的缺点就是你很难找到这些指标随着时间的一些行为模式，在这种情况下，vmstat 或者 pidstat 这种可以提供滚动输出的命令是更好的方式。如果你不以足够快的速度暂停输出(Ctrl-S 暂停，Ctrl-Q 继续)，一些间歇性问题的线索也可能由于被清屏而丢失。
위 내용은 60초 안에 Linux 성능을 최적화하고 향상시키는 방법은 무엇입니까? 2%의 사람들만이 알고 있다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
