Teil1Linux-Leistungsoptimierung

1Leistungsoptimierung

Leistung. Indikatoren

Hohe Parallelität und schnelle Reaktion entsprechen den beiden Kernindikatoren der Leistungsoptimierung: Durchsatz und Latenz

Zusammenfassung der Wissenspunkte zur Linux-Leistungsoptimierung · Practice + Collection Edition — Bilder von: www.ctq6.cn

AnwendungslastWinkel: wirkt sich direkt auf die Benutzererfahrung des Produktterminals aus
SystemressourcenWinkel: Ressourcennutzung, Sättigung usw.

Der Kern des Leistungsproblems besteht darin, dass die Systemressourcen den Engpass erreicht haben, die Anforderungsverarbeitung jedoch nicht schnell genug ist, um weitere Anforderungen zu unterstützen. Bei der Leistungsanalyse geht es eigentlich darum, die Engpässe der Anwendung oder des Systems zu finden und zu versuchen, diese zu vermeiden oder zu lindern.

Wählen Sie Metriken zur Bewertung der Anwendungs- und Systemleistung.
Legen Sie Leistungsziele für Anwendungen und Systeme fest
Bild von: www.ctq6.cn
Wie sollen wir „durchschnittliche Last“ verstehen? ist die durchschnittliche Anzahl aktiver Prozesse. Es steht nicht in direktem Zusammenhang mit der CPU-Auslastung, wie wir es traditionell verstehen.
Der unterbrechungsfreie Prozess ist ein Prozess, der sich im Kernelstatus in einem kritischen Prozess befindet (z. B. eine allgemeine E/A-Antwort, die auf ein Gerät wartet).
Der unterbrechungsfreie Zustand ist eigentlich ein Schutzmechanismus des Systems für Prozesse und Hardwaregeräte.

Was ist die angemessene durchschnittliche Auslastung? Überwachen Sie in der tatsächlichen Produktionsumgebung die durchschnittliche Auslastung des Systems und beurteilen Sie den Laständerungstrend anhand historischer Daten. Wenn es einen offensichtlichen Aufwärtstrend bei der Auslastung gibt, führen Sie rechtzeitig eine Analyse und Untersuchung durch. Natürlich können Sie auch einen Schwellenwert festlegen (z. B. wenn die durchschnittliche Auslastung mehr als 70 % der CPU-Anzahl beträgt).
In der Praxis verwechseln wir häufig die Konzepte der durchschnittlichen Auslastung und der CPU-Auslastung sind nicht völlig gleichwertig:

CPU-intensive Prozesse führen zu einem Anstieg der durchschnittlichen Auslastung Zu diesem Zeitpunkt ist die CPU-Auslastung nicht unbedingt hoch. Eine große Anzahl von Prozessen, die auf die CPU-Planung warten, führt zu einem Anstieg der durchschnittlichen Last Mit der Zeit wird auch die CPU-Auslastung relativ hoch sein
- Wenn die durchschnittliche Auslastung hoch ist, kann dies an CPU-intensiven Prozessen liegen oder daran liegen, dass /O ausgelastet ist. Während einer spezifischen Analyse können Sie das Tool mpstat/pidstat kombinieren, um die Analyse der Lastquelle zu unterstützen
- 2 Der Kontext der neuen Aufgabe wird an diese Register und den Programmzähler übertragen und schließlich wird an die Stelle gesprungen, auf die der Programmzähler zeigt, um die neue Aufgabe auszuführen. Unter anderem wird der gespeicherte Kontext im Systemkernel gespeichert und bei einer Neuplanung der Aufgabe erneut geladen, um sicherzustellen, dass der ursprüngliche Aufgabenstatus nicht beeinträchtigt wird. Folgen Sie der chinesischen Linux-CommunityJe nach Aufgabentyp ist die CPU-Kontextumschaltung unterteilt in:
  - Prozesskontextwechsel
  - Thread-Kontextwechsel
  - Interrupt-Kontextwechsel
  Prozesskontextwechsel
  
  Der Linux-Prozess unterteilt den laufenden Bereich des Prozesses entsprechend in Kernelraum und Benutzerraum Berechtigungsstufe. Der Übergang vom Benutzermodus zum Kernelmodus muss durch Systemaufrufe abgeschlossen werden.
  
  Ein Systemaufrufprozess führt tatsächlich zwei CPU-Kontextwechsel durch:
  - Die Position der Benutzermodusanweisung im CPU-Register wird zuerst gespeichert, das CPU-Register wird auf die Position der Kernelmodusanweisung aktualisiert und in den Kernelmodus gesprungen, um die Kernelaufgabe auszuführen
  - Nach dem Systemaufruf Nach Abschluss stellt das CPU-Register die ursprünglich gespeicherten Benutzerstatusdaten wieder her und wechselt dann zum Benutzerbereich, um mit der Ausführung fortzufahren.
  Der Systemaufrufprozess umfasst keine Prozessbenutzermodusressourcen wie virtuellen Speicher und wechselt auch nicht den Prozess. Es unterscheidet sich vom Prozesskontextwechsel im herkömmlichen Sinne. Daher wird der Systemaufruf oft als privilegierter Moduswechsel bezeichnet .
  
  Prozesse werden vom Kernel verwaltet und geplant, und der Prozesskontextwechsel kann nur im Kernelmodus erfolgen. Daher müssen im Vergleich zu Systemaufrufen vor dem Speichern des Kernelstatus und der CPU-Register des aktuellen Prozesses zunächst der virtuelle Speicher und der Stapel des Prozesses gespeichert werden. Nach dem Laden des Kernelstatus des neuen Prozesses müssen der virtuelle Speicher und der Benutzerstapel des Prozesses aktualisiert werden.
  
  Der Prozess muss nur dann den Kontext wechseln, wenn die Ausführung auf der CPU geplant ist. Es gibt die folgenden Szenarien: CPU-Zeitscheiben werden abwechselnd zugewiesen, unzureichende Systemressourcen führen dazu, dass der Prozess hängt, der Prozess bleibt aktiv während der Ruhezustandsfunktion hängen und Vorlaufzeit für Prozesse mit hoher Priorität. Wenn ein Hardware-Interrupt auftritt, wird der Prozess auf der CPU angehalten und führt stattdessen den Interrupt-Dienst im Kernel aus.
  
  Thread-Kontextwechsel
  
  Thread-Kontextwechsel ist in zwei Typen unterteilt:
  - Der vordere und hintere Thread gehören zum selben Prozess, und die virtuellen Speicherressourcen bleiben während des Wechsels unverändert. Sie müssen nur die privaten Daten, Register usw. des Threads wechseln.
  - Der vordere und hintere Thread gehören dazu zu verschiedenen Prozessen, was dem Wechsel des Prozesskontexts entspricht.
  Thread-Wechsel im selben Prozess verbraucht weniger Ressourcen, was auch der Vorteil von Multithreading ist.
  
  Interrupt-Kontextwechsel
  
  Der Interrupt-Kontextwechsel betrifft nicht den Benutzerstatus des Prozesses, sodass der Interrupt-Kontext nur den Status enthält, der für die Ausführung des Kernel-Status-Interrupt-Dienstprogramms erforderlich ist (CPU-Register, Kernel-Stack, Hardware-Interrupt). Parameter usw.).
  
  Die Priorität der Interrupt-Verarbeitung ist höher als die des Prozesses, sodass Interrupt-Kontextwechsel und Prozesskontextwechsel nicht gleichzeitig stattfinden
  
  CPU-Kontextwechsel (Teil 2)
  
  Sie können die allgemeine Kontextwechselsituation des Systems über vmstat überprüfen
```
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
```
  Nach dem Login kopieren
  - cs (Kontextwechsel) Anzahl der Kontextwechsel pro Sekunde
  - in (Interrupt ) Anzahl der Interrupts pro Sekunde
  - r (laufend oder ausführbar) Die Länge der Bereitschaftswarteschlange, die Anzahl der Prozesse, die ausgeführt werden und auf die CPU warten
  - b (Blockiert) Die Anzahl der Prozesse im unterbrechungsfreien Ruhezustand
  So zeigen Sie die Details jedes Prozesses an: In diesem Fall müssen Sie pidstat verwenden, um den Kontextwechsel jedes Prozesses anzuzeigen
```
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
```
  Nach dem Login kopieren
  - 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列： 中断次数明显上升，说明中断处理也是潜在问题
```
  Nach dem Login kopieren
  说明运行/等待CPU的进程过多，导致大量的上下文切换，上下文切换导致系统的CPU占用率高
```
pidstat -w -u 1  #查看到底哪个进程导致的问题
```
  Nach dem Login kopieren
  从结果中看出是sysbench导致CPU使用率过高，但是pidstat输出的上下文次数加起来也并不多。分析sysbench模拟的是线程的切换，因此需要在pidstat后加-t参数查看线程指标。
  另外对于中断次数过多，我们可以通过/proc/interrupts文件读取
```
watch -d cat /proc/interrupts
```
  Nach dem Login kopieren
  发现次数变化速度最快的是重调度中断（RES），该中断用来唤醒空闲状态的CPU来调度新的任务运行。分析还是因为过多任务的调度问题，和上下文切换分析一致。
  Die CPU-Auslastung einer Anwendung erreicht 100 %, was soll ich tun?
  Linux, als Multitasking-Betriebssystem, teilt die CPU-Zeit in kurze Zeitscheiben auf und weist diese über den Scheduler der Reihe nach jeder Aufgabe zu. Um die CPU-Zeit aufrechtzuerhalten, löst Linux Zeitunterbrechungen durch vordefinierte Beat-Raten aus und verwendet globale Jiffies, um die Anzahl der Beats seit dem Booten aufzuzeichnen. Die Zeitunterbrechung erfolgt, sobald dieser Wert + 1.
  CPU-Auslastung , der Prozentsatz der gesamten CPU-Zeit außer der Leerlaufzeit. Die CPU-Auslastung kann anhand der Daten in /proc/stat berechnet werden. Denn der kumulative Wert der Anzahl der Beats seit dem Booten in /proc/stat wird als durchschnittliche CPU-Auslastung seit dem Booten berechnet, was im Allgemeinen von geringer Aussagekraft ist. Sie können die durchschnittliche CPU-Auslastung während dieses Zeitraums berechnen, indem Sie die Differenz zwischen zwei Werten ermitteln, die in Abständen eines Zeitraums ermittelt wurden. Das Leistungsanalysetool gibt die durchschnittliche CPU-Auslastung über einen bestimmten Zeitraum an. Achten Sie auf die Einstellung des Intervalls.
  Die CPU-Auslastung kann über top oder ps angezeigt werden. Sie können die CPU-Probleme des Prozesses mithilfe von Perf analysieren, das auf der Stichprobenerhebung von Leistungsereignissen basiert. Es kann nicht nur verschiedene Ereignisse des Systems und der Kernelleistung analysieren, sondern auch zur Analyse der Leistungsprobleme bestimmter Anwendungen verwendet werden.
  Perf Top / Perf Record / Perf Report (-g aktiviert die Stichprobe von Anrufbeziehungen)
```
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服务性能
```
  Nach dem Login kopieren
  发现此时每秒可承受请求给长少，此时将测试的请求数从100增加到10000。在另外一个终端运行top查看每个CPU的使用率。发现系统中几个php-fpm进程导致CPU使用率骤升。
  接着用perf来分析具体是php-fpm中哪个函数导致该问题。
```
perf top -g -p XXXX #对某一个php-fpm进程进行分析
```
  Nach dem Login kopieren
  发现其中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个请求测试
```
  Nach dem Login kopieren
  实验结果中每秒请求数依旧不高，我们将并发请求数降为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
```
  Nach dem Login kopieren
  发现是php-fpm调用的该子进程，此时去查看源码可以看出每个请求都会调用一个stress命令来模拟I/O压力。之前top显示的结果是CPU使用率升高，是否真的是由该stress命令导致的，还需要继续分析。代码中给每个请求加了verbose=1的参数后可以查看stress命令的输出，在中断测试该命令结果显示stress命令运行时存在因权限问题导致的文件创建失败的bug。
  Dies ist immer noch nur eine Vermutung. Der nächste Schritt besteht darin, die Analyse mit dem Perf-Tool fortzusetzen. Der Leistungsbericht zeigt, dass Stress tatsächlich viel CPU beansprucht, was durch die Behebung des Berechtigungsproblems gelöst werden kann.
  Was soll ich tun, wenn im System eine große Anzahl unterbrechungsfreier Prozesse und Zombie-Prozesse vorhanden sind?
  Prozessstatus
  - R Wird ausgeführt/ausführbar, was darauf hinweist, dass sich der Prozess in der Bereitschaftswarteschlange der CPU befindet, ausgeführt wird oder auf die Ausführung wartet; kommuniziert mit der Hardware und darf während der Interaktion nicht durch andere Prozesse unterbrochen werden.
  - Z Zombie, ein Zombie-Prozess, was bedeutet, dass der Prozess tatsächlich beendet wurde, der übergeordnete Prozess jedoch seine Ressourcen nicht zurückgefordert hat ;
  - S Unterbrechbarer Ruhezustand, der unterbrochen werden kann, bedeutet, dass der Prozess vom System angehalten wird, weil es auf ein Ereignis wartet, und in den R-Zustand übergeht
  对于不可中断状态，一般都是在很短时间内结束，可忽略。但是如果系统或硬件发生故障，进程可能会保持不可中断状态很久，甚至系统中出现大量不可中断状态，此时需注意是否出现了I/O性能问题。
  僵尸进程一般多进程应用容易遇到，父进程来不及处理子进程状态时子进程就提前退出，此时子进程就变成了僵尸进程。大量的僵尸进程会用尽PID进程号，导致新进程无法建立。
  磁盘O_DIRECT问题
```
sudo docker run --privileged --name=app -itd feisky/app:iowait
ps aux | grep &#39;/app&#39;
```
  Nach dem Login kopieren
  可以看到此时有多个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组数据
```
  Nach dem Login kopieren
  可以看到当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进程调用进行跟踪
```
  Nach dem Login kopieren
  报错没有权限，因为已经时root权限了。所以遇到这种情况，首先要检查进程状态是否正常。ps命令查找该进程已经处于Z状态，即僵尸进程。
  这种情况下top pidstat之类的工具无法给出更多的信息，此时像第5篇一样，用perf record -d和perf report进行分析，查看app进程调用栈。
  看到app确实在通过系统调用sys_read()读取数据，并且从new_sync_read和blkdev_direct_IO看出进程时进行直接读操作，请求直接从磁盘读，没有通过缓存导致iowait升高。
  Nach einer schichtweisen Analyse liegt die Hauptursache im direkten Festplatten-I/O innerhalb der App. Suchen Sie dann den spezifischen Codespeicherort zur Optimierung.
  Zombie-Prozesse
  Nach der oben genannten Optimierung ist Iowait deutlich zurückgegangen, aber die Anzahl der Zombie-Prozesse nimmt immer noch zu. Suchen Sie zunächst den übergeordneten Prozess des Zombie-Prozesses. Drucken Sie mit pstree -aps XXX den Aufrufbaum des Zombie-Prozesses aus und stellen Sie fest, dass der übergeordnete Prozess der App-Prozess ist.
  Überprüfen Sie den App-Code, um zu sehen, ob das Ende des untergeordneten Prozesses korrekt behandelt wird (ob wait()/waitpid() aufgerufen wird, ob eine SIGCHILD-Signalverarbeitungsfunktion registriert ist usw.).
  Wenn Sie auf einen Anstieg von Iowait stoßen, verwenden Sie zunächst Tools wie dstat und pidstat, um zu bestätigen, ob ein Festplatten-E/A-Problem vorliegt, und finden Sie dann heraus, welche Prozesse das E/A verursachen. Wenn Sie strace nicht verwenden können Analysieren Sie den Prozessaufruf direkt. Sie können ihn mit dem Perf-Tool analysieren.
  Für das Zombie-Problem verwenden Sie pstree, um den übergeordneten Prozess zu finden, und sehen Sie sich dann den Quellcode an, um die Verarbeitungslogik für das Ende des untergeordneten Prozesses zu überprüfen.
  CPU-Leistungsindikator
  - CPU-Auslastung
  - Idealerweise entspricht die durchschnittliche Auslastung der Anzahl der logischen CPUs, was bedeutet, dass jede Wenn die CPU vollständig ausgelastet ist, bedeutet dies, dass die Systemlast höher ist.
    Prozesskontextwechsel
  Performance -Tools
  - Durchschnittlastfall. CPU bzw. CPU-Auslastung jedes Prozesses. Durchsuchen Sie außerdem das öffentliche Linux-Konto und antworten Sie auf „Git Books“, um ein Überraschungsgeschenkpaket zu erhalten.
- Kontextwechselfall
- Bei hoher Prozess-CPU-Auslastung
- Bei hoher System-CPU-Auslastung
- Unterbrechungsfreie und Zombie-Prozessfälle
- Soft-Interrupt-Fall

Das obige ist der detaillierte Inhalt vonZusammenfassung der Wissenspunkte zur Linux-Leistungsoptimierung · Practice + Collection Edition. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!