집 > 기사 > 운영 및 유지보수 > Linux 성능 전반에 걸친 튜닝 경험 요약

Linux 성능 전반에 걸친 튜닝 경험 요약

Linux中文社区앞으로: 2023-08-03 14:59:491156검색

Part1Linux 성능 최적화

1성능 최적화

성능 지표

높음 동시성과 빠른 응답은 성능 최적화의 두 가지 핵심 지표에 해당합니다. 처리량 및 Latency

Application loadAngle: 제품 터미널의 사용자 경험에 직접적인 영향을 미칩니다
System resourcesAngle: 리소스 사용량, satur 이온 성능 문제의 본질은 시스템 리소스가 병목 현상에 도달했지만 요청 처리가 더 많은 요청을 지원할 만큼 빠르지 않다는 것입니다. 성능 분석은 실제로 애플리케이션이나 시스템의 병목 현상을 찾아 이를 피하거나 완화하려고 노력하는 것입니다.
- 애플리케이션 및 시스템 성능을 평가하기 위한 지표 선택
- 애플리케이션 및 시스템에 대한 성능 목표 설정
- 성능 벤치마크 수행
- 병목 현상을 찾기 위한 성능 분석
- 성능 모니터링 및 경고
다양한 성능 문제의 경우 다양한 성능 분석 도구를 선택해야 합니다. 다음은 일반적으로 사용되는 Linux 성능 도구와 해당 유형의 성능 문제를 분석한 것입니다.

사진: www.ctq6.cn
"평균 부하"를 어떻게 이해해야 할까요?

평균 부하: 실행 가능한 상태와 중단 불가능한 상태의 시스템 평균 프로세스 단위 시간 수는 활성 프로세스의 평균 수입니다. 우리가 전통적으로 이해한 것처럼 CPU 사용량과 직접적인 관련이 없습니다.

무정전 프로세스는 커널 상태에서 중요한 프로세스(예: 장치를 기다리는 일반적인 I/O 응답)에 있는 프로세스입니다. 무정전 상태는 실제로 프로세스 및 하드웨어 장치에 대한 시스템의 보호 메커니즘입니다.

합리적인 평균 부하는 얼마인가요?

실제 생산 환경에서 시스템의 평균 부하를 모니터링하고 과거 데이터를 바탕으로 부하 변화 추세를 판단합니다. 부하가 확실히 증가하는 경향이 있는 경우 적시에 분석 및 조사를 수행합니다. 물론 임계값을 설정할 수도 있습니다(예: 평균 부하가 CPU 수의 70%보다 높은 경우)

실제 작업에서는 평균 부하와 CPU 사용량의 개념을 혼동하는 경우가 많습니다. 둘은 완전히 동일하지 않습니다:
- CPU 집약적인 프로세스, 다량의 CPU 사용량으로 인해 평균 로드가 증가합니다. 이때 두 프로세스는 일관됩니다.
- I/O 집약적인 프로세스, I/O를 기다리는 프로세스도 이로 인해 평균 부하가 증가하므로 CPU 사용량이 반드시 높은 것은 아닙니다
- CPU 스케줄링을 기다리는 프로세스 수가 많으면 평균 부하도 증가하게 됩니다.
CPU의 평균 부하가 높으면 CPU가 집중적인 프로세스나 바쁜 I/O로 인해 발생할 수 있습니다. 특정 분석 중에 mpstat/pidstat 도구를 결합하여 로드 소스 분석을 지원할 수 있습니다

2CPU

CPU 컨텍스트 스위칭(1부)

CPU 컨텍스트 스위칭은 이전 작업의 CPU 컨텍스트(CPU 레지스터 및 PC)를 저장한 후 새로운 작업을 로드하는 것입니다. 이러한 레지스터와 프로그램 카운터에 대한 컨텍스트를 지정하고 마지막으로 프로그램 카운터가 가리키는 위치로 점프하여 새 작업을 실행합니다. 그중 저장된 컨텍스트는 시스템 커널에 저장되었다가 작업 일정이 변경될 때 다시 로드되어 원래 작업 상태가 영향을 받지 않도록 합니다.

작업 유형에 따라 CPU 컨텍스트 전환은 다음과 같이 구분됩니다.
- 프로세스 컨텍스트 스위치
- 스레드 컨텍스트 스위치
- 인터럽트 컨텍스트 스위치
프로세스 컨텍스트 스위치

Lin ux 프로세스는 레벨 권한을 따르고 프로세스의 실행 공간을 나눕니다. 커널 공간과 사용자 공간으로 나뉜다. 사용자 모드에서 커널 모드로의 전환은 시스템 호출을 통해 완료되어야 합니다.

시스템 호출 프로세스는 실제로 두 개의 CPU 컨텍스트 전환을 수행합니다.
- CPU 레지스터의 사용자 모드 명령어 위치가 먼저 저장되고, CPU 레지스터가 커널 모드 명령어의 위치로 업데이트되며, 커널 작업을 실행하기 위해 커널 상태로 점프합니다. 시스템 호출이 끝나면 CPU 레지스터는 원래 상태로 돌아갑니다. 사용자 모드 데이터를 저장한 후 사용자 공간으로 전환하여 계속 실행합니다.
- 시스템 호출 프로세스에는 가상 메모리와 같은 프로세스 사용자 모드 리소스가 포함되지 않으며 프로세스를 전환하지도 않습니다. 이는 전통적인 의미의 프로세스 컨텍스트 전환과는 다릅니다. 따라서
  시스템 호출을 종종 특권 모드 스위치
프로세스는 커널에 의해 관리되고 예약되며 프로세스 컨텍스트 전환은 커널 모드에서만 발생할 수 있습니다. 따라서 시스템 호출과 비교하여 현재 프로세스의 커널 상태와 CPU 레지스터를 저장하기 전에 프로세스의 가상 메모리와 스택을 먼저 저장해야 합니다. 새로운 프로세스의 커널 상태를 로딩한 후에는 해당 프로세스의 가상 메모리와 사용자 스택을 새로 고쳐야 합니다.

프로세스는 CPU에서 실행되도록 예약된 경우에만 컨텍스트를 전환하면 됩니다. 다음과 같은 시나리오가 있습니다. CPU 시간 분할이 차례로 할당되고, 시스템 리소스가 부족하여 프로세스가 중단되고, 프로세스가 적극적으로 중단됩니다. 절전 기능 및 우선 순위가 높은 프로세스 선점 시간 조각, 하드웨어가 중단되면 CPU의 프로세스가 일시 중지되고 대신 커널에서 인터럽트 서비스를 실행합니다.

스레드 컨텍스트 전환

스레드 컨텍스트 전환은 두 가지 유형으로 나뉩니다.
- 전면 및 후면 스레드는 전환 중에 가상 메모리 리소스가 변경되지 않고 그대로 유지됩니다. , 레지스터 등을 전환해야 합니다.
- 전면 및 후면 스레드는 서로 다른 프로세스에 속하며 이는 프로세스 컨텍스트 전환과 동일합니다.
동일한 프로세스에서 스레드를 전환하면 리소스를 덜 소모하는데, 이는 멀티스레딩의 장점이기도 합니다.

인터럽트 컨텍스트 전환

인터럽트 컨텍스트 전환에는 프로세스의 사용자 상태가 포함되지 않으므로 인터럽트 컨텍스트에는 커널 상태 인터럽트 서비스 프로그램 실행에 필요한 상태만 포함됩니다(CPU 레지스터, 커널 스택, 하드웨어 인터럽트 매개변수 등).

프로세스보다 인터럽트 처리 우선순위가 높기 때문에 인터럽트 컨텍스트 전환과 프로세스 컨텍스트 전환이 동시에 발생하지 않습니다

Docker+K8s+Jenkins 주류 기술 종합 영상 정보

CPU 컨텍스트 전환(2부)

vmstat
을 통해 시스템의 전반적인 컨텍스트 전환 상황을 확인할 수 있습니다.
```
vmstat 5         #每隔5s输出一组数据
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 103388 145412 511056    0    0    18    60    1    1  2  1 96  0  0
 0  0      0 103388 145412 511076    0    0     0     2  450 1176  1  1 99  0  0
 0  0      0 103388 145412 511076    0    0     0     8  429 1135  1  1 98  0  0
 0  0      0 103388 145412 511076    0    0     0     0  431 1132  1  1 98  0  0
 0  0      0 103388 145412 511076    0    0     0    10  467 1195  1  1 98  0  0
 1  0      0 103388 145412 511076    0    0     0     2  426 1139  1  0 99  0  0
 4  0      0  95184 145412 511108    0    0     0    74  500 1228  4  1 94  0  0
 0  0      0 103512 145416 511076    0    0     0   455  723 1573 12  3 83  2  0
```
- cs(컨텍스트 스위치) 초당 컨텍스트 스위치 수
- in(인터럽트) 초당 인터럽트 수
- r(runnning 또는 runnable) 준비 대기열의 길이, 실행 및 대기 CPU의 프로세스 수
- b (차단됨) 무중단 절전 상태의 프로세스 수
각 프로세스의 세부 정보를 보려면 pidstat를 사용하여 컨텍스트 전환을 확인해야 합니다. 각 프로세스
```
pidstat -w 5
14时51分16秒   UID       PID   cswch/s nvcswch/s  Command
14时51分21秒     0         1      0.80      0.00  systemd
14时51分21秒     0         6      1.40      0.00  ksoftirqd/0
14时51分21秒     0         9     32.67      0.00  rcu_sched
14时51分21秒     0        11      0.40      0.00  watchdog/0
14时51分21秒     0        32      0.20      0.00  khugepaged
14时51分21秒     0       271      0.20      0.00  jbd2/vda1-8
14时51分21秒     0      1332      0.20      0.00  argusagent
14时51分21秒     0      5265     10.02      0.00  AliSecGuard
14时51分21秒     0      7439      7.82      0.00  kworker/0:2
14时51分21秒     0      7906      0.20      0.00  pidstat
14时51分21秒     0      8346      0.20      0.00  sshd
14时51分21秒     0     20654      9.82      0.00  AliYunDun
14时51分21秒     0     25766      0.20      0.00  kworker/u2:1
14时51分21秒     0     28603      1.00      0.00  python3
```
- cswch 每秒自愿上下文切换次数（进程无法获取所需资源导致的上下文切换）
- nvcswch 每秒非自愿上下文切换次数（时间片轮流等系统强制调度）
```
vmstat 1 1    #首先获取空闲系统的上下文切换次数
sysbench --threads=10 --max-time=300 threads run #模拟多线程切换问题

vmstat 1 1    #新终端观察上下文切换情况
此时发现cs数据明显升高，同时观察其他指标：
r列： 远超系统CPU个数，说明存在大量CPU竞争
us和sy列：sy列占比80%，说明CPU主要被内核占用
in列： 中断次数明显上升，说明中断处理也是潜在问题
```
说明运行/等待CPU的进程过多，导致大量的上下文切换，上下文切换导致系统的CPU占用率高
```
pidstat -w -u 1  #查看到底哪个进程导致的问题
```
从结果中看出是sysbench导致CPU使用率过高，但是pidstat输出的上下文次数加起来也并不多。分析sysbench模拟的是线程的切换，因此需要在pidstat后加-t参数查看线程指标。

另外对于中断次数过多，我们可以通过/proc/interrupts文件读取
```
watch -d cat /proc/interrupts
```
发现次数变化速度最快的是重调度中断（RES），该中断用来唤醒空闲状态的CPU来调度新的任务运行。分析还是因为过多任务的调度问题，和上下文切换分析一致。

某个应用的CPU使用率达到100%，怎么办？

Linux作为多任务操作系统，将CPU时间划分为很短的时间片，通过调度器轮流分配给各个任务使用。为了维护CPU时间，Linux通过事先定义的节拍率，触发时间中断，并使用全局变了jiffies记录开机以来的节拍数。时间中断发生一次该值+1.

CPU使用率，除了空闲时间以外的其他时间占总CPU时间的百分比。可以通过/proc/stat中的数据来计算出CPU使用率。因为/proc/stat时开机以来的节拍数累加值，计算出来的是开机以来的平均CPU使用率，一般意义不大。可以间隔取一段时间的两次值作差来计算该段时间内的平均CPU使用率。性能分析工具给出的都是间隔一段时间的平均CPU使用率，要注意间隔时间的设置。

CPU使用率可以通过top 或 ps来查看。分析进程的CPU问题可以通过perf，它以性能事件采样为基础，不仅可以分析系统的各种事件和内核性能，还可以用来分析指定应用程序的性能问题。

perf top / perf record / perf report （-g 开启调用关系的采样）
```
sudo docker run --name nginx -p 10000:80 -itd feisky/nginx
sudo docker run --name phpfpm -itd --network container:nginx feisky/php-fpm

ab -c 10 -n 100 http://XXX.XXX.XXX.XXX:10000/ #测试Nginx服务性能
```
发现此时每秒可承受请求给长少，此时将测试的请求数从100增加到10000。在另外一个终端运行top查看每个CPU的使用率。发现系统中几个php-fpm进程导致CPU使用率骤升。

接着用perf来分析具体是php-fpm中哪个函数导致该问题。
```
perf top -g -p XXXX #对某一个php-fpm进程进行分析
```
发现其中sqrt和add_function占用CPU过多，此时查看源码找到原来是sqrt中在发布前没有删除测试代码段，存在一个百万次的循环导致。将该无用代码删除后发现nginx负载能力明显提升

系统的CPU使用率很高，为什么找不到高CPU的应用？
```
sudo docker run --name nginx -p 10000:80 -itd feisky/nginx:sp
sudo docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:sp
ab -c 100 -n 1000 http://XXX.XXX.XXX.XXX:10000/ #并发100个请求测试
```
实验结果中每秒请求数依旧不高，我们将并发请求数降为5后，nginx负载能力依旧很低。

此时用top和pidstat发现系统CPU使用率过高，但是并没有发现CPU使用率高的进程。

出现这种情况一般时我们分析时遗漏的什么信息，重新运行top命令并观察一会。发现就绪队列中处于Running状态的进行过多，超过了我们的并发请求次数5. 再仔细查看进程运行数据，发现nginx和php-fpm都处于sleep状态，真正处于运行的却是几个stress进程。

下一步就利用pidstat分析这几个stress进程，发现没有任何输出。用ps aux交叉验证发现依旧不存在该进程。说明不是工具的问题。再top查看发现stress进程的进程号变化了，此时有可能时以下两种原因导致：
- 进程不停的崩溃重启（如段错误/配置错误等），此时进程退出后可能又被监控系统重启；
- 短时进程导致，即其他应用内部通过exec调用的外面命令，这些命令一般只运行很短时间就结束，很难用top这种间隔较长的工具来发现
可以通过pstree来查找 stress的父进程，找出调用关系。
```
pstree | grep stress
```
发现是php-fpm调用的该子进程，此时去查看源码可以看出每个请求都会调用一个stress命令来模拟I/O压力。之前top显示的结果是CPU使用率升高，是否真的是由该stress命令导致的，还需要继续分析。代码中给每个请求加了verbose=1的参数后可以查看stress命令的输出，在中断测试该命令结果显示stress命令运行时存在因权限问题导致的文件创建失败的bug。

此时依旧只是猜测，下一步继续通过perf工具来分析。性能报告显示确实时stress占用了大量的CPU，通过修复权限问题来优化解决即可.

시스템에 무정전 프로세스와 좀비 프로세스가 많은 경우 어떻게 해야 하나요?

프로세스 상태
- R 실행 중/실행 가능, 프로세스가 CPU의 준비 대기열에 있고 실행 중이거나 실행 대기 중임을 나타냅니다.
- D 디스크 절전, 중단 불가능한 상태 절전, 일반적으로 나타냅니다. 프로세스 하드웨어와 상호 작용하고 있으며 상호 작용 중에 다른 프로세스에 의해 중단될 수 없습니다.
- Z 좀비 프로세스인 좀비는 프로세스가 실제로 종료되었지만 상위 프로세스가 회수되지 않았음을 의미합니다.
- S Sleep 상태를 중단할 수 있는 Interruptible Sleep은 이벤트를 기다리고 있기 때문에 프로세스가 시스템에 의해 일시 중지되는 것을 의미합니다. R 상태;
- I 유휴 상태, 무정전 커널 스레드에서 사용됩니다.该状态不会导致平均负载升高；
- T Stop/Traced，表示进程处于暂停或跟踪状态（SIGSTOP/SIGCONT， GDB调试）；
- X Dead，进程已经消亡，不会在top/ps中看到。
对于不可中断状态，一般都是在很短时间内结束，可忽略。但是如果系统或硬件发生故障，进程可能会保持不可中断状态很久，甚至系统中出现大量不可中断状态，此时需注意是否出现了I/O性能问题。

僵尸进程一般多进程应用容易遇到，父进程来不及处理子进程状态时子进程就提前退出，此时子进程就变成了僵尸进程。大量的僵尸进程会用尽PID进程号，导致新进程无法建立。

磁盘O_DIRECT问题
```
sudo docker run --privileged --name=app -itd feisky/app:iowait
ps aux | grep &#39;/app&#39;
```
可以看到此时有多个app进程运行，状态分别时Ss+和D+。其中后面s表示进程是一个会话的领导进程，+号表示前台进程组。

其中进程组表示一组相互关联的进程，子进程是父进程所在组的组员。会话指共享同一个控制终端的一个或多个进程组。

用top查看系统资源发现：1）平均负载在逐渐增加，且1分钟内平均负载达到了CPU个数，说明系统可能已经有了性能瓶颈；2）僵尸进程比较多且在不停增加；3）us和sys CPU使用率都不高，iowait却比较高；4）每个进程CPU使用率也不高，但有两个进程处于D状态，可能在等待IO。

分析目前数据可知：iowait过高导致系统平均负载升高，僵尸进程不断增长说明有程序没能正确清理子进程资源。

用dstat来分析，因为它可以同时查看CPU和I/O两种资源的使用情况，便于对比分析。
```
dstat 1 10    #间隔1秒输出10组数据
```
可以看到当wai（iowait）升高时磁盘请求read都会很大，说明iowait的升高和磁盘的读请求有关。接下来分析到底时哪个进程在读磁盘。

之前top查看的处于D状态的进程号，用pidstat -d -p XXX 展示进程的I/O统计数据。发现处于D状态的进程都没有任何读写操作。在用pidstat -d 查看所有进程的I/O统计数据，看到app进程在进行磁盘读操作，每秒读取32MB的数据。进程访问磁盘必须使用系统调用处于内核态，接下来重点就是找到app进程的系统调用。
```
sudo strace -p XXX #对app进程调用进行跟踪
```
报错没有权限，因为已经时root权限了。所以遇到这种情况，首先要检查进程状态是否正常。ps命令查找该进程已经处于Z状态，即僵尸进程。

这种情况下top pidstat之类的工具无法给出更多的信息，此时像第5篇一样，用perf record -d和perf report进行分析，查看app进程调用栈。

看到app确实在通过系统调用sys_read()读取数据，并且从new_sync_read和blkdev_direct_IO看出进程时进行直接读操作，请求直接从磁盘读，没有通过缓存导致iowait升高。

通过层层分析后，root cause是app内部进行了磁盘的直接I/O。然后定位到具体代码位置进行优化即可。

좀비 프로세스

위의 최적화 이후 iowait는 크게 줄어들었지만 좀비 프로세스 수는 여전히 증가하고 있습니다. 먼저 좀비 프로세스의 상위 프로세스를 찾습니다. pstree -aps XXX를 사용하여 좀비 프로세스의 호출 트리를 인쇄하고 상위 프로세스가 앱 프로세스인지 확인합니다.

앱 코드를 확인하여 하위 프로세스의 끝이 올바르게 처리되었는지 확인하세요(wait()/waitpid()가 호출되는지, SIGCHILD 신호 처리 함수가 등록되어 있는지 등).

iowait가 증가하면 먼저 dstat 및 pidstat와 같은 도구를 사용하여 디스크 I/O 문제가 있는지 확인한 다음 strace를 사용할 수 없는 경우 어떤 프로세스가 I/O를 일으키는지 알아보세요. 프로세스 호출을 직접 분석하려면 perf 도구를 사용하여 분석할 수 있습니다.

좀비 문제의 경우 pstree를 사용하여 상위 프로세스를 찾은 후 소스 코드를 보고 하위 프로세스 종료에 대한 처리 로직을 확인합니다.

CPU 성능 지표
- CPU 사용량
- Average load
  
  이상적으로 평균 로드는 논리적 CPU 수와 동일합니다. 즉, 각 CPU가 완전히 활용된다는 의미입니다. 그보다 크면 시스템 부하가 크다는 뜻입니다.
- Process Context Switch
  
  자원을 확보할 수 없는 경우의 자발적 전환과 시스템이 스케줄링을 강제할 때의 비자발적 전환을 포함합니다. 컨텍스트 전환 자체는 Linux의 정상적인 작동을 보장하는 핵심 기능입니다. 과도한 전환은 레지스터에서 원래 실행 중인 프로세스의 CPU 시간을 소모합니다. 커널 및 가상 메모리와 기타 데이터 저장 및 복구. 또한, 공개 계정 프로그래머 샤오러의 백스테이지를 검색해 '인터뷰 질문'에 답하고 깜짝 선물 패키지를 받아가세요.
- CPU 캐시 적중률
  
  CPU 캐시 재사용률이 높을수록 성능이 좋아집니다. 그 중 L1/L2는 싱글 코어에서 흔히 사용되며, L3는 멀티에서 사용됩니다. -코어
성능 도구
- 평균 부하 사례
- 컨텍스트 전환 사례
- 프로세스 CPU 사용량이 많은 사례
- 시스템 CPU 사용량이 높은 경우
- 무정전 및 좀비 프로세스 사례
- 소프트 인터럽트 사례
다양한 성능 지표를 기반으로 올바른 도구 찾기:

사진 출처: www. ctq6.cn
프로덕션 환경에서 개발자는 종종 새로운 도구 패키지를 설치할 권한이 없으며 시스템에 이미 설치된 도구의 사용을 최대화할 수 있습니다. 따라서 어떤 지표 분석이 주류인지 이해해야 합니다. 도구를 제공할 수 있습니다.

출처: www.ctq6.cn
먼저 top/vmstat/pidstat와 같은 더 많은 표시기를 지원하는 여러 도구를 실행해 보면 어떤 유형의 성능 문제인지 확인할 수 있습니다. 프로세스를 찾은 후 추가 분석을 위해 strace/perf를 사용하여 호출 상황을 분석합니다. 소프트 인터럽트로 인해 발생한 경우 /proc/softirqs
를 사용하세요.
사진 출처: www.ctq6.cn
CPU 최적화
- 애플리케이션 최적화

위 내용은 Linux 성능 전반에 걸친 튜닝 경험 요약의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명：

이 기사는 Linux中文社区에서 복제됩니다. 침해가 있는 경우 admin@php.cn으로 문의하시기 바랍니다. 삭제

이전 기사：Linux - 서버가 손상되었는지 완벽하게 확인하는 방법을 알려주는 11단계다음 기사：Linux - 서버가 손상되었는지 완벽하게 확인하는 방법을 알려주는 11단계

Linux 성능 전반에 걸친 튜닝 경험 요약

Part1Linux 성능 최적화

1성능 최적화

성능 지표

"평균 부하"를 어떻게 이해해야 할까요?

합리적인 평균 부하는 얼마인가요?

2CPU

CPU 컨텍스트 스위칭(1부)

프로세스 컨텍스트 스위치

스레드 컨텍스트 전환

인터럽트 컨텍스트 전환

CPU 컨텍스트 전환(2부)

某个应用的CPU使用率达到100%，怎么办？

系统的CPU使用率很高，为什么找不到高CPU的应用？

시스템에 무정전 프로세스와 좀비 프로세스가 많은 경우 어떻게 해야 하나요?

프로세스 상태

磁盘O_DIRECT问题

좀비 프로세스

CPU 성능 지표

성능 도구

CPU 최적화

3Memory

Linux 메모리 작동 방식

메모리 매핑

가상 메모리 공간 분배

메모리 할당 및 재활용

allocation

재활용

如何查看内存使用情况

메모리 버퍼와 캐시를 이해하는 방법은 무엇입니까?

시스템 캐시를 사용하여 프로그램의 운영 효율성을 최적화하는 방법

캐시 적중률

dd缓存加速

O_DIRECT选项绕过系统缓存

메모리 누수, 어떻게 찾아서 처리하나요?

메모리 할당 및 재활용

sudo docker run --name=app -itd feisky/app:mem-leak sudo docker logs app vmstat 3

为什么系统的Swap变高

스왑 원리

NUMA 与 SWAP

swappiness

Swap升高时如何定位分析

시스템 메모리 문제를 빠르고 정확하게 찾는 방법

메모리 성능 표시기

메모리 성능 도구

빠른 분석 방법 기억 성능 병목 현상

vmstat 사용법에 대한 자세한 설명

pidstat 使用详解

관련 기사