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
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 Leerlauf, Ruhezustand, wird für Kernel-Threads verwendet, die den Ruhezustand nicht unterbrechen können. Dieser Zustand führt nicht zu einem Anstieg der durchschnittlichen Last nicht oben/ps gesehen werden.
