Wenn es um die Behebung eines Leistungsproblems unter Linux geht, ist es sehr wichtig, die Grundlagen verschiedener Befehlsausgaben wie Uptime, vmstat. In diesem Beitrag werden wir versuchen, die Lastdurchschnitte zu verstehen und die Warteschlange/Blockierte Warteschlange in Bezug auf die CPU-Auslastung auszuführen. Lassen Sie uns zunächst verstehen, was der Lastdurchschnitt ist:
Der Lastdurchschnitt ist die Anzahl der Jobs in der Ausführungswarteschlange (Zustand R) oder die auf Festplatten-E/A warten (Zustand D), gemittelt über 1, 5 und 15 Minuten. Beispielausgabe des Befehls uptime/top:
# uptime 11:49:14 up 25 days, 5:56, 68 users, load average: 0.03, 0.13, 0.47
# top -b -n 1 top - 11:49:34 up 25 days, 5:56, 68 users, load average: 0.09, 0.14, 0.46 Tasks: 456 total, 1 running, 445 sleeping, 10 stopped, 0 zombie Cpu(s): 0.8%us, 0.4%sy, 0.0%ni, 98.6%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 141823788k total, 140483388k used, 1340400k free, 313452k buffers Swap: 16772092k total, 0k used, 16772092k free, 134695384k cached
Als Faustregel gilt:
- Single-Core-System – Wenn die durchschnittliche Auslastung 1,00 beträgt, bedeutet dies, dass das System voll ausgelastet ist, und wenn weitere Aufgaben eingehen, werden sie in die Warteschlange gestellt und auf die Ausführung gewartet.
- Single-Core-System – Wenn die durchschnittliche Auslastung 2,00 beträgt, bedeutet dies, dass das System bereits ausgelastet ist und einige Aufgaben bereits in der Warteschlange stehen und auf die Ausführung warten.
- Mehrkernsystem (4 Kerne) – Wenn der Lastdurchschnitt 1,00 beträgt, bedeutet dies, dass das System 1/4 seiner CPU-Kapazität verwendet, eine Aufgabe aktiv ausgeführt wird und sich noch 3 Kerne im „Leerlauf“ befinden.
- Mehrkernsystem (4 Kerne) – Wenn der Lastdurchschnitt 4,00 beträgt, bedeutet dies, dass das System alle 4 Kerne verwendet, und es zeigt an, dass das System vollständig ausgelastet ist.
Ist in den oben genannten Fällen noch etwas Headroom übrig? – normalerweise nein – wenn die durchschnittliche Auslastung nahe an der Anzahl der Kerne auf dem System liegt – sollte das Betriebssystem überprüft werden, um nach tatsächlichen Engpässen und fehlender Abstimmung zu suchen, oder vielleicht ist das Betriebssystem nicht richtig skaliert, um APP/DB-Aufgaben zu erfüllen.
Wie wird der Durchschnittswert der Last auf Active OS berechnet? – Dazu müssen wir die Run Queue finden, die über den vmstat-Befehl verfügbar ist:
Idle-System (8-Core-System)
# vmstat 1 6 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 1674516 316588 134364752 0 0 0 1 0 0 1 0 99 0 0 0 0 0 1674624 316588 134364752 0 0 0 0 195 307 0 0 100 0 0 0 0 0 1674624 316596 134364752 0 0 0 12 168 302 0 0 100 0 0 0 0 0 1674624 316596 134364752 0 0 0 0 198 331 0 0 100 0 0 0 0 0 1674624 316596 134364752 0 0 0 0 206 356 0 0 100 0 0 0 0 0 1674624 316600 134364736 0 0 0 12 197 333 0 0 100 0 0
Aktives System (8-Kern-System)
# vmstat 1 6 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 0 1674516 316588 134364752 0 0 0 1 0 0 1 0 99 0 0 7 0 0 1674624 316588 134364752 0 0 0 0 195 307 0 0 100 0 0 2 0 0 1674624 316596 134364752 0 0 0 12 168 302 0 0 100 0 0 6 0 0 1674624 316596 134364752 0 0 0 0 198 331 0 0 100 0 0 1 0 0 1674624 316596 134364752 0 0 0 0 206 356 0 0 100 0 0 8 0 0 1674624 316600 134364736 0 0 0 12 197 333 0 0 100 0 0
Die obigen Ausgaben sind Beispiele – die erste zeigt, dass die aktuelle Laufwarteschlange (r) 0 ist, während die Laufwarteschlange auf einem aktiven System in 6 Proben von 1 auf 8 springt.
Was genau ist eine Laufwarteschlange?
Run-Warteschlange :Anzahl der aktiven (laufenden) und in der Warteschlange befindlichen Prozesse.
Im zweiten Beispiel sehen wir bei aktivem System eine Laufwarteschlange von 8 – dies ist bereits die maximale Obergrenze, die ein System mit 8 Kernen ausführen sollte. Natürlich kann die Ausführungswarteschlange Werte wie 36 oder sogar 101 anzeigen – sie sind vollkommen in Ordnung, wenn wir auf der ersten 36 36 Kerne und auf der zweiten 101 mehr als 101 Kerne haben.
Die Spalte „Laufwarteschlange“ sollte immer niedriger/gleich der Anzahl der auf dem System installierten Kerne sein – natürlich kann die Laufwarteschlange von 100 auf einem System mit nur 8 Kernen sichtbar sein – das bedeutet, dass 8 Prozesse aktiv von der CPU bedient werden und die restlichen 92 in die Warteschlange gestellt werden und auf die Hinrichtung warten. Wenn die Ausführungswarteschlange über den installierten CPU-Kernen liegt, sollte eine Untersuchung im Hinblick auf die Überprüfung der APP/DB-Leistung und fehlender Optimierung durchgeführt werden oder kann darauf hindeuten, dass das System nicht richtig skaliert ist, um eine solche Ausführungswarteschlange/Last zu bedienen.
Genauso wie die Warteschlange für die Ausführung der durchschnittlichen Last unter der Anzahl der installierten Kerne bleiben sollte – wenn dieser Wert nicht unter dem maximalen Schwellenwert gehalten wird, führt dies zu einer Verlangsamung/Hängung oder einem Räumungsfall (wenn das System HA aktiviert ist), da das Betriebssystem einfach die Heartbeat-Überwachung auf der Festplatte/im Netzwerk in die Warteschlange stellen kann Schicht, da sie damit beschäftigt ist, andere Aufgaben zu erfüllen. Eine hohe durchschnittliche Auslastung und eine hohe Ausführungswarteschlange führen zu einem plötzlichen Absturz/Hängen – es lohnt sich, beide Werte aktiv über Überwachungstools von Drittanbietern zu überwachen und zu warnen, wenn die Ausführungswarteschlange / die durchschnittliche Auslastung mehr als 70 % der tatsächlichen CPU-Ressourcen beanspruchen.
Die zweite wichtige Spalte, die auch von Load Average verwendet wird, ist der Status „b“ in vmstat, der blockierte Statusprozesse erklärt – dies kann leicht als Status-D-Prozesse interpretiert werden (warten auf den Abschluss von Back-End-E/A – normalerweise Speicheraktivität). Wenn der Lastdurchschnitt hoch ist und keine Prozesse aktiv ausgeführt werden und vmstat einen abnormalen „b“-Statuswert anzeigt, ist es an der Zeit, die SAN-Leistung oder die Überprüfung einer Betriebssystemkomponente wie ISCSI/NFS/NIC/HBA zu überprüfen, was zu Problemen führen kann schwerwiegender Blockadezustand unter Linux. Zum Beispiel könnte der NFS-Server auf CPU-Ebene ausgelastet sein und alle Client-Prozesse/Aufgaben (Linux) werden in Zustand d (b) in die Warteschlange gestellt, was zu einer „Warteschlange“ führt, die anschließend eine massive Run-Warteschlange freigeben könnte – wie es alle Prozesse waren Wenn sie darauf warten, dass die Back-End-E/A später beendet wird, wechseln sie möglicherweise wieder in den Modus „Running“, was zu einer massiven Run-Warteschlange führt, die einen Hängezustand/Panikzustand verursachen oder anschließend zu einem Räumungsfall führen kann.
Der Netzwerkdurchsatz und der TCP/UDP-Verkehr werden ebenfalls aufgrund des hohen Lastdurchschnitts beeinträchtigt – da das System einfach damit beschäftigt ist, andere Aufgaben zu erfüllen, als eingehende/ausgehende Verbindungen zu bestätigen und eingehenden Netzwerk-E/A-Verkehr über NFS/ISCSI usw. zu priorisieren. In einigen Fällen kann TOP angezeigt werden Wenn der %CPU-Wert größer als 100 ist, ist dies vollkommen in Ordnung, da der TOP-Befehl standardmäßig in Linux Single-Core-Operationen anzeigt, daher kann der %CPU-Wert in Multicore-Setups größer als 100 % sein. Wenn PID beispielsweise 4 Kerne vollständig nutzt, wird der %CPU-Wert 400 anzeigen
# top top - 11:49:34 up 25 days, 5:56, 68 users, load average: 0.09, 0.14, 0.46 Tasks: 456 total, 1 running, 445 sleeping, 10 stopped, 0 zombie Cpu(s): 0.8%us, 0.4%sy, 0.0%ni, 98.6%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 141823788k total, 140483388k used, 1340400k free, 313452k buffers Swap: 16772092k total, 0k used, 16772092k free, 134695384k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1438 java 20 0 945m 4220 2528 S 400.5 0.0 56:31.95 java <---
Info über %CPU:
## %CPU -- CPU Usage The task's share of the elapsed CPU time since the last screen update, expressed as a percentage of total CPU time. In a true SMP environment, if a process is multi-threaded and top is not operating in Threads mode, amounts greater than 100% may be reported. You toggle Threads mode with the 'H' interactive command. ##
Um laufende/blockierte Prozesse schnell aufzulisten, verwenden Sie den folgenden ps-Befehl:
# ps r -Af
Um Prozess-Threads aufzulisten, um zu überprüfen, ob einige Threads, die von der übergeordneten PID erzeugt werden, kein CPU-Spike-Problem verursachen, führen Sie Folgendes aus:
# ps -e -To pid,ppid,state,pcpu,command
oder
# ps -elfL
Verwenden Sie auch die folgenden Befehlsbeispiele, um zu überprüfen, ob die Betriebssystem-CPUs aktiv Benutzerspeicher ( US ) bereitstellen:
# sar -P ALL 1 Linux 3.8.13-118.13.3.el6uek.x86_64 (lgeeklab) 01/08/2017 _x86_64_ (8 CPU) 02:40:38 PM CPU %user %nice %system %iowait %steal %idle 02:40:39 PM all 12.62 0.00 0.12 6.88 0.00 80.38 02:40:39 PM 0 0.00 0.00 0.00 54.55 0.00 45.45 02:40:39 PM 1 0.00 0.00 0.00 0.00 0.00 100.00 02:40:39 PM 2 0.99 0.00 0.00 0.00 0.00 99.01 02:40:39 PM 3 0.00 0.00 0.00 0.00 0.00 100.00 02:40:39 PM 4 100.00 0.00 0.00 0.00 0.00 0.00 02:40:39 PM 5 0.98 0.00 0.98 0.00 0.00 98.04 02:40:39 PM 6 0.00 0.00 0.00 0.00 0.00 100.00 02:40:39 PM 7 0.00 0.00 0.00 0.00 0.00 100.00 Average: CPU %user %nice %system %iowait %steal %idle Average: all 12.63 0.00 0.13 6.00 0.00 81.24 Average: 0 0.00 0.00 0.00 45.23 0.00 54.77 Average: 1 0.50 0.00 0.00 3.00 0.00 96.50 Average: 2 0.50 0.00 0.00 0.00 0.00 99.50 Average: 3 0.00 0.00 0.00 0.50 0.00 99.50 Average: 4 100.00 0.00 0.00 0.00 0.00 0.00 Average: 5 0.50 0.00 0.50 0.00 0.00 99.00 Average: 6 0.00 0.00 0.00 0.00 0.00 100.00 Average: 7 0.00 0.00 0.00 0.00 0.00 100.00
# mpstat -P ALL Linux 3.8.13-118.13.3.el6uek.x86_64 (geeklab) 01/08/2017 _x86_64_ (8 CPU) 02:41:26 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 02:41:26 PM all 0.79 0.00 0.10 1.18 0.00 0.02 0.00 0.00 97.92 02:41:26 PM 0 0.94 0.00 0.14 2.84 0.00 0.02 0.00 0.00 96.06 02:41:26 PM 1 0.94 0.00 0.14 2.70 0.00 0.02 0.00 0.00 96.20 02:41:26 PM 2 0.93 0.00 0.14 1.13 0.00 0.03 0.00 0.00 97.77 02:41:26 PM 3 0.94 0.00 0.13 2.71 0.00 0.02 0.00 0.00 96.20 02:41:26 PM 4 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.28 02:41:26 PM 5 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.27 02:41:26 PM 6 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.27 02:41:26 PM 7 0.64 0.00 0.05 0.01 0.00 0.01 0.00 0.00 99.29
Darüber hinaus können die folgenden TOP-Befehlsschalter verwendet werden, um PID-Thread-Informationen zu erhalten und auch, welcher Kern zuletzt PID bedient hat:
Threads in TOP anzeigen:
# top -H
Um anzuzeigen, welche Kern-PID das letzte Mal bedient wurde, führen Sie Folgendes aus:
# top
Drücken Sie dann 'F ' und drücken Sie 'J ' und drücken Sie die Eingabetaste, um die folgende Ausgabe zu erhalten, wobei 'P ' Zeile wird die zuletzt verwendete CPU sein.
Tasks: 1045 total, 2 running, 1043 sleeping, 0 stopped, 0 zombie Cpu(s): 0.2%us, 0.2%sy, 0.0%ni, 93.6%id, 5.9%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 16159656k total, 15349888k used, 809768k free, 597960k buffers Swap: 8232956k total, 218784k used, 8014172k free, 9840192k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND 10428 root 20 0 15228 2228 1724 S 0.7 0.0 0:26.86 2 top 10838 oracle 20 0 4921m 585m 5708 S 0.7 3.7 137:11.13 3 mysqld 15360 root 20 0 15888 2792 1724 R 0.7 0.0 0:00.55 6 top 528 root 20 0 0 0 0 S 0.3 0.0 76:39.23 0 jbd2/dm-0-8 9003 root 20 0 0 0 0 S 0.3 0.0 8:49.33 2 jbd2/dm-3-8 10815 oracle 20 0 4921m 585m 5708 S 0.3 3.7 13:35.18 1 mysqld 14902 oracle 20 0 9431m 2.4g 28m S 0.3 15.5 19:54.77 3 java 15021 oracle 20 0 9431m 2.4g 28m S 0.3 15.5 20:09.19 1 java 15094 oracle 20 0 9431m 2.4g 28m S 0.3 15.5 6:54.88 3 java 32045 enduser 20 0 15228 2220 1724 S 0.3 0.0 9:32.73 5 top 32278 root 20 0 15228 2212 1724 S 0.3 0.0 9:32.96 1 top
Häufig gestellte Fragen
Sollte das System mit einer Obergrenze von 8 laufenden Prozessen mit einem Lastdurchschnitt auf demselben Wert auf einem 8-Kern-System laufen?
Antwort - Nein
Das System sollte richtig skaliert werden und 70% seiner Möglichkeiten nicht überschreiten - damit es etwas Spielraum für neue auszuführende Aufgaben gibt - dies ist besonders wichtig für HA-fähige Server und für Systeme mit High-End E/A-/Netzwerkkomponenten, die möglicherweise versehentlich vom aktiven Betriebssystem in die Warteschlange gestellt werden. Für diese eingehende Überprüfung sollte das APP/DB-Team durchführen, um zu überprüfen, was genau aktiv unter dem Betriebssystem ausgeführt wird.
Verursachen nur APP/DB-Tasks eine hohe Warteschlange / einen hohen Lastdurchschnitt
Antwort - Nein
Einige OS-Aufgaben können zu einer hohen Ausführungswarteschlange oder einem hohen Lastdurchschnitt führen – dies sind jedoch wirklich seltene Fälle. In diesem Fall ist der Befehl top hilfreich, um die US /SY / NI / ID / WA / HI / SI / ST-Werte zu überwachen und sich auf den Abschnitt SY ( System ) zu konzentrieren, der angibt, wie viel Prozessorzeit auf Kernel-Ebene verbracht wird. Stellen Sie sicher, dass es immer niedriger ist als die tatsächliche US-Auslastung (Benutzer) und dass SY beispielsweise nicht 20-30 % der CPU verwendet (abhängig von der CPU-Konfiguration und dem tatsächlichen Fall).
Beispielsweise kann ein hohes %SY während hoher E/A-/Netzwerkoperationen oder in Fällen von Speicherknappheit sichtbar sein – Beispielprozess ist:kjorunald. Ein hohes %SY kann auch während starker Systemlasten sichtbar sein - zum Beispiel bei einer hohen Laufwarteschlange oder einer blockierten Warteschlange, die durch APP/DB-Tasks verursacht wird - meistens wird dann beobachtet, dass %SY bei etwa 20-30% liegt, während %US dies tun wird viel höher sein.
Ein höheres %SY bedeutet nicht immer, dass es ein Kernel- oder Betriebssystemproblem gibt – zum Beispiel könnte es Anwendungs-/Datenbankcode geben, der viele Systemaufrufe um eine bestimmte Kernelfunktion herum verursacht – zum Debuggen dieses weiteren Strace oder Perf sollte verwendet werden Überprüfen Sie die spezifische PID-Interaktion.
Bedeutet das, dass ein einzelner Kern jeweils nur eine einzelne Prozessaufgabe bedienen kann?
Antwort - Ja/Nein
CPUs sind für Multitasking ausgelegt – selbst mit Single-Core-Systemen können Benutzer immer noch mehrere Aufgaben ausführen und mehrere Anwendungen starten – im Single-Core-Setup wird „Time-Slicing“ verwendet, wodurch Aufgaben für eine bestimmte Zeit ausgeführt werden können, während andere Aufgaben darauf warten ausgeführt werden (dies kann ein paar Mal pro Sekunde passieren).
Moderne Systeme verwenden Multicore/Multithreading-Funktionen, um diese Auswirkungen des Umschaltens weniger sichtbar zu machen – daher haben Benutzer auf Enterprise-Systemen ein Multicore-Setup, bei dem Anwendungen kleinere Threads erstellen können, die tatsächliche Multitasking-Operationen erreichen (jeder Kern kann unterschiedliche Aufgaben erfüllen), was zu viel mehr führt geringere durchschnittliche Belastung des Systems und niedrigere Aufgabenwarteschlange – Beispielsweise kann ein Dual-Core-System Anwendungen/Threads/Aufgaben in zwei separate Kerne aufteilen, sodass der Kern im Vergleich zu einem Single-Core-System nur die Hälfte der Aufgaben umschalten kann, was weit weniger Auswirkungen auf die Systemleistung hat.