빠른 원격 측정, 번거로움 없는 Linux 성능 분석

운영 및 유지보수 담당자로서 Linux 시스템의 성능 문제로 고민해본 적 있으신가요? 문제를 해결하는 데 많은 시간과 에너지를 소비했지만 여전히 문제를 정확하게 찾아 분석할 수 없을 수도 있습니다. 그렇다면 Linux 성능 문제를 신속하게 원격 측정하는 몇 가지 방법을 알아야 합니다.

다음 10가지 명령을 실행하면 60초 이내에 시스템의 실행 프로세스와 리소스 사용량을 대략적으로 이해할 수 있습니다. 이러한 명령의 오류 메시지와 리소스 포화도 출력(읽기 쉬움)을 살펴보면 리소스를 최적화할 수 있습니다. 포화는 리소스의 로드가 처리할 수 있는 한도를 초과하는 경우를 의미합니다. 포화가 발생하면 일반적으로 요청 대기열의 길이 또는 대기 시간에 노출됩니다.

으아악

이러한 명령 중 일부는 sysstat 소프트웨어 패키지의 사전 설치가 필요합니다. 이러한 명령으로 표시되는 정보는 다양한 리소스(예: CPU, 메모리, 디스크) 확인과 같은 USE 방법(성능 병목 현상을 찾는 방법)을 구현하는 데 도움이 될 수 있습니다. 등) 사용, 포화 및 오류 정보 또한 문제를 찾는 과정에서 이러한 명령을 사용하여 문제를 일으킬 수 있는 특정 가능성을 배제하고 검사 범위를 좁히고 방향을 지적할 수 있습니다. 다음 장에서는 이러한 명령을 프로덕션 환경에서 실행하는 방법을 예로 들어 간략하게 소개합니다. 이러한 도구의 사용에 대해 자세히 알아보려면 해당 매뉴얼 문서를 참조하십시오.

1.가동시간

으아악

이것은 시스템 부하 평균을 빠르게 확인하는 방법입니다. 시스템에서 실행해야 할 작업(프로세스) 수를 표시합니다. Linux 시스템에서 이 숫자에는 CPU에서 실행해야 하는 프로세스와 실행 중인 프로세스가 포함됩니다. I/O(일반적으로 디스크 I/O) 프로세스를 기다리는 것은 시스템 로드를 대략적으로 표시한 것일 뿐이므로 간단히 살펴보기만 하면 됩니다. 또한 특정 상황을 더 자세히 이해하려면 다른 도구를 사용해야 합니다.
마지막 세 숫자는 1분, 5분, 15분에 걸쳐 시스템의 전체 부하 평균을 지수적으로 압축한 결과를 보여줍니다. 시간이 지남에 따라 시스템 부하가 어떻게 변화하는지 확인할 수 있습니다. 위의 예에서는 지난 1분 동안의 부하 값이 30을 초과한 반면, 15분 동안의 평균 부하 값은 19에 불과했기 때문에 시간이 지남에 따라 시스템 부하가 증가하고 있습니다. 이러한 명백한 차이는 CPU 로드와 같은 많은 영향을 미칩니다. 자세한 내용을 확인하려면 vmstat 또는 mpstat 명령을 실행하세요. 이 두 명령에 대해서는 3장과 4장을 참조하세요.

2.dmesg

으아악

이 명령은 성능 문제를 일으킬 수 있는 오류를 찾기 위해 마지막 10개의 시스템 메시지(아직 존재하는 경우)를 표시합니다.
위의 예에는 oom-killer 및 TCP 요청 삭제가 포함되어 있습니다. 이 단계를 놓치지 마세요! dmesg 명령은 항상 시도해 볼 가치가 있습니다.

3.vmstat 1

으아악

vmstat(8)은 가상 메모리 통계의 약어입니다. 일반적으로 사용되는 도구입니다(BSD용으로 수십 년 전에 생성됨). vmstat 명령은 매개변수 1을 지정합니다. 실행하려면 매 초의 통계 요약을 인쇄하는 것입니다(예제에서는 vmstat의 이 버전). 출력의 첫 번째 줄의 열은 명시적으로 이전 초의 값이 아닌 부팅 이후의 평균 값입니다.
지금은 첫 번째 행을 건너뛰겠습니다. 각 열을 알고 기억하고 싶지 않다면 다음 열을 확인하세요.

으아악

CPU 고장 시간은 CPU가 사용 중인지 여부를 결정하기 위해 사용자 시간과 시스템 시간에 의해 결정됩니다. I/O 대기 시간이 변하지 않으면 이는 CPU의 유휴 상태를 나타냅니다. I/O가 일시 중지될 때까지 기다리는 것이 CPU 유휴 상태의 또 다른 형태라고 생각할 수 있습니다. 이는 CPU가 I/O에 매우 중요한 이유에 대한 단서를 제공합니다. O 처리 A 평균 시스템 시간이 20%를 초과하면 추가 조사가 필요할 수 있습니다. 아마도 커널이 I/O 처리에 너무 비효율적일 수 있습니다.
위의 예에서 CPU 시간은 거의 전적으로 사용자 수준에서 소비되며 이는 응용 프로그램이 너무 많은 CPU 시간을 차지하고 있으며 평균 CPU 사용량도 90%를 초과한다는 것을 나타냅니다. 물론 이것이 반드시 문제가 되는 것은 아닙니다. 확인 "r "열의 채도를 보면 알 수 있습니다.

4.mpstat -P 전체 1

으아악

이 명령은 각 CPU의 CPU 고장 시간을 인쇄하며, 이는 사용량이 고르지 않은 단일 CPU를 확인하는 데 사용할 수 있습니다. 단일 스레드 응용 프로그램이 실행 중임을 나타냅니다.

5. pidstat 1

으아악

pidstat 명령은 top 명령의 각 프로세스에 대한 통계 요약과 약간 비슷하지만 top의 화면 새로 고침 대신 롤링 통계 요약을 반복하여 인쇄합니다. 실시간 보기에 사용할 수 있으며 복사에도 사용할 수 있습니다. 그리고 당신이 본 것을 조사 기록에 붙여넣으세요.
위의 예는 두 개의 Java 프로세스가 CPU를 소비하고 있음을 보여줍니다. %CPU 열은 모든 CPU의 합계입니다. 1591%는 이 Java 프로세스가 거의 16개의 CPU를 소비한다는 의미입니다.

6.iostat -xz 1

$ iostat -xz 1Linux 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 5.62 1.78 0.03
[...]
^C

无论是对工作负载还是性能表现来说，这都是一个很棒的用于查看块设备（磁盘）情况的工具。
查看个列：

r/s, w/s, rkB/s, wkB/s：这些分别代表该设备每秒的读次数、写次数、读取 kb 数，和写入 kb 数，这些数值用于描述工作负载情况，性能迟滞问题则可能仅仅是由于施加了过大的负载。
await：表示以毫秒为单位的 I/O 平均消耗时间，这是应用程序消耗的实际时间，因为它包括了排队时间和处理时间，比预期耗用了更多的平均时间就可能意味着设备的饱和，或设备出了问题。
avgqu-sz：向设备发出的请求的平均数量，该值大于 1 说明已经饱和了（虽说设备可以并行处理请求，尤其是由多个磁盘组成的虚拟设备。）
%util：设备利用率，这个值是一个显示出该设备在工作时每秒处于忙碌状态的百分比，虽然它取决于设备本身物理性能，若值大于 60％，通常表明性能不佳（可以从 await 中看出），当值接近 100% 通常意味着已饱和。

如果该存储设备是一个面向很多后端磁盘的逻辑磁盘设备，则 100% 利用率可能只是意味着当前正在处理某些 I/O 占用，然而，后端磁盘可能远未饱和，并且可能能够处理更多的工作，请记住，磁盘 I/O 性能较差不一定是程序的问题，许多技术通常是异步 I/O，使应用程序不会被阻塞并遭受延迟（例如，预读，以及写缓冲）。

7. free -m

$ free -m
total used free shared buffers cached
Mem: 245998 24545 221453 83 59 541
-/+ buffers/cache: 23944 222053
Swap: 0 0 0

右边的两列显式：

buffers：用于块设备 I/O 的缓冲区缓存。
cached：用于文件系统的页面缓存。

我们只是想要检查这些不接近零的大小，其可能会导致更高磁盘 I/O（使用 iostat 确认），和更糟糕的性能，上面的例子看起来还不错，每一列均有很多 M 个大小，比起第一行，-/+ buffers/cache 提供的内存使用量会更加准确些，Linux 会把暂时用不上的内存用作缓存，一旦应用需要的时候就立刻重新分配给它，所以部分被用作缓存的内存其实也算是空闲的内存，为了解释这一点， 甚至有人专门建了个网站： linuxatemyram，您如果还是不理解的话，可以去“充充电”。如果你在 Linux 上安装了 ZFS，这一点会变得更加困惑，因为 ZFS 它自己的文件系统缓存不算入free -m，有时候发现系统已经没有多少空闲内存可用了，其实内存却都待在 ZFS 的缓存里。

8. sar -n DEV 1

$ sar -n DEV 1Linux 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 接收的流量达到 22Mbytes/s，也即 176Mbits/sec（限额是 1Gbit/sec），我们所用的命令版本中还提供了 %ifutil 作为设备使用率（接收和发送的最大值）的指标，我们也可以用 Brendan 的 nicstat 工具计量这个值，一如 nicstat，sar 显示的这个值是很难精确取得的，在这个例子里面，它就没在正常的工作（显示0.00）。

9. sar -n TCP,ETCP 1

$ sar -n TCP,ETCP 1Linux 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 指标的汇总视图，这些包括：

active/s：每秒本地发起 TCP 连接数（例如，通过 connect()）。
passive/s：每秒远程发起的 TCP 连接数（例如，通过 accept()）。
retrans/s：每秒重传 TCP 次数。

active 和 passive 的连接数往往对于描述一个粗略衡量服务器负载是非常有用的：新接受的连接数（passive），下行连接数（active），也可以理解为 active 连接是对外的，而 passive 连接是对内的，虽然严格来说并不完全正确（例如，一个 localhost 到 localhost 的连接），重传是出现一个网络和服务器问题的一个征兆，其可能是由于一个不可靠的网络（例如，公网）造成的，或许也有可能是由于服务器过载并丢包。上面的例子显示了每秒只有一个新的 TCP 连接。

10. top

$ toptop - 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
6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:0
8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_sched

top 命令包含了很多我们之前已经检查过的指标，我们可以观察到命令输出的结果每时每刻都有很大不同，这表明负载是可变的，top 的一个缺点是，很难看到数据随时间变动的趋势，而vmstat 和 pidstat则能提供滚动输出，这样显得更清楚一些，同样的，如果你不以足够快的速度暂停输出以上信息（Ctrl-S 暂停，Ctrl-Q 继续），一些间歇性问题的线索就可能由于被清屏而丢失。

综上所述，通过本文中介绍的快速遥测技巧，我们可以更加高效地诊断和解决Linux系统的性能问题。当出现问题时，我们可以快速地排查，在最短的时间内找到关键点并进行调试，从而提高工作效率和用户体验。

위 내용은 빠른 원격 측정, 번거로움 없는 Linux 성능 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!