Lösung 1:
Nicht sicher, aber meistens auf 1.00*n_cpu .
Die Last bedeutet Folgendes:Wenn es mehrere Prozesse auf einem Single-CPU-System gibt, laufen sie scheinbar parallel. Aber es ist nicht wahr. Was praktisch passiert:Der Kernel gibt einem Prozess 1/100 Sekunde und unterbricht dann seine Ausführung mit einem Interrupt. Und gibt die nächste 1/100 Sekunde an einen anderen Prozess weiter.
Praktisch wird die Frage "Welcher Prozess soll unser nächstes 1/100-Sekunden-Intervall bekommen?" durch eine komplexe Heuristik entschieden. Es wird als task bezeichnet Planung .
Natürlich sind Prozesse, die blockiert sind, also beispielsweise auf ihre Daten warten, was sie von der Platte lesen, von dieser Aufgabenplanung ausgenommen.
Was Last sagt:Wie viele Prozesse warten derzeit auf ihren nächsten 1/100-Sekunden-Zeitrahmen. Natürlich ist es ein Mittelwert. Dies liegt daran, dass Sie mehrere Zahlen in einer cat /proc/loadavg sehen können .
Die Situation in einem Multi-CPU-System ist etwas komplexer. Es gibt mehrere CPUs, deren Zeitrahmen mehreren Prozessen gegeben werden können. Das macht die Aufgabenplanung etwas – aber nicht zu viel – komplexer. Aber die Situation ist die gleiche.
Der Kernel ist intelligent, er versucht, die Systemressourcen für die optimale Effizienz zu teilen, und er ist nahe daran (es gibt kleinere Optimierungsdinge, zum Beispiel ist es besser, wenn ein Prozess so lange wie möglich auf demselben ausgeführt wird CPU aufgrund von Caching-Überlegungen, aber sie spielen dort keine Rolle). Denn wenn wir Load 8 haben, bedeutet das:Es warten tatsächlich 8 Prozesse auf ihre nächste Zeitscheibe. Wenn wir 8 CPUs haben, können wir diese Zeitscheiben den CPUs eins zu eins zuweisen und somit wird unser System optimal ausgenutzt.
Wenn Sie eine top sehen , können Sie sehen, dass die Anzahl der tatsächlich laufenden Prozesse überraschend gering ist:Es sind die Prozesse, die mit R gekennzeichnet sind dort. Selbst auf einem nicht wirklich Hardcore-System liegt er oft unter 5. Dies liegt teilweise daran, dass die Prozesse, die auf ihre Daten von den Platten oder aus dem Netzwerk warten, ebenfalls ausgesetzt werden (gekennzeichnet mit S). oben). Die Auslastung zeigt nur die CPU-Auslastung.
Es gibt auch Tools, um die Plattenlast zu messen, sie sollten meiner Meinung nach mindestens so wichtig sein wie die Überwachung der CPU-Auslastung, aber irgendwie ist es hier in unserer professionellen Sysadmin-Welt nicht so bekannt.
Windows-Tools teilen die Last oft mit der tatsächlichen Anzahl der CPUs. Dies führt dazu, dass einige professionelle Windows-Systemadministratoren die Systemlast im Sinne einer Aufteilung nach CPU verwenden. Sie haben nicht Recht und werden wahrscheinlich glücklicher sein, nachdem Sie ihnen das erklärt haben.
Multicore-CPUs sind praktisch mehrere CPUs auf demselben Siliziumchip. Es gibt keinen Unterschied.
Bei Hyperthread-CPUs gibt es einen interessanten Nebeneffekt:Das Laden einer CPU macht ihre Hyperthread-Paare langsamer. Dies geschieht jedoch auf einer tieferen Ebene als die normale Aufgabenplanung, obwohl sie die prozessbewegenden Entscheidungen des Planers beeinflussen kann (und sollte).
Aber aus heutiger Sicht - was die Systemlast bestimmt - spielt es auch keine Rolle.
Lösung 2:
Lastdurchschnitt bedeutet nicht, was Sie denken, dass es bedeutet. Es geht nicht um die sofortige CPU-Auslastung, sondern darum, wie viele Prozesse darauf warten, ausgeführt zu werden. Normalerweise Das liegt daran, dass viele Dinge CPU wollen, aber nicht immer. Ein häufiger Übeltäter ist ein Prozess, der auf IO wartet – Festplatte oder Netzwerk.
Versuchen Sie, ps -e v auszuführen und Suchen nach Prozesszustandsflags.
state The state is given by a sequence of characters, for example, "RWNA". The first character indicates the run state of the process:
D Marks a process in disk (or other short term, uninterruptible) wait.
I Marks a process that is idle (sleeping for longer than about 20 seconds).
L Marks a process that is waiting to acquire a lock.
R Marks a runnable process.
S Marks a process that is sleeping for less than about 20 seconds.
T Marks a stopped process.
W Marks an idle interrupt thread.
Z Marks a dead process (a "zombie").
Dies ist von ps Manpage, damit Sie dort mehr Details finden - R und D Prozesse sind wahrscheinlich von besonderem Interesse.
Sie können aus allen möglichen Gründen mit durchschnittlichen Lastspitzen enden, daher sind sie nicht wirklich ein gutes Maß für etwas anderes als „Ist dieses System ausgelastet?“. Es wird Ihnen nichts nützen, wenn Sie sich beim Zuordnen des Lastdurchschnitts zu CPU-Kernen verzetteln.
Lösung 3:
Da Hyperthreading eigentlich kein zweiter Kern ist, wird es einen Kern nie auf 200 % bringen, aber für bestimmte Workloads über 100 %.
Ihre maximale Belastung liegt also irgendwo unbekannt zwischen ca. 4 und 6
(Natürlich kann dies bei Überlast höher steigen, da es tatsächlich lauffähige Prozesse zählt, insbesondere wenn sie auf IO warten)
Lösung 4:
Auf einem Linux-System werden nicht nur die Prozesse in der ausführbaren Warteschlange zur Berechnung der Auslastung hochgezählt, sondern auch die in unterbrechungsfreien Ruhezuständen, wodurch die Auslastung ansteigt, wenn viele Prozesse auf die Festplatte warten.
Lösung 5:
Ich habe einige Experimente auf unserem 24-Kern-Xeon-System (2 Sockel x 12 Kerne) durchgeführt. Die maximale Auslastung beträgt in diesem Fall 48.0 aufgrund der Art und Weise, wie Linux Hyperthreading einrichtet.
Sie erhalten jedoch nicht das Äquivalent von 48 Kernen Durchsatz. Was ich beobachtet habe ist, dass man etwa 90% des Durchsatzes in den ersten 24 logischen Prozessoren bekommt, also wenn die Last auf 24.0 läuft. Dann erhält man einen zusätzlichen Durchsatz von ca. 10 % für die restlichen 24 logischen Prozessoren (Last läuft bis 48.0). Eine andere Denkweise ist, dass Sie, wenn Sie 48 Threads auf den 24 Kernen ausführen, eine Steigerung von etwa 10-20 % erhalten, wenn Sie Hyperthreading aktivieren oder nicht. Es ist kein 100 %-Boost, wie die Marketingleute vermuten lassen würden.
Eine Möglichkeit, diese Beobachtung zu testen, besteht beispielsweise darin, einen Prozess zu haben, der 48 Threads ausführt (z. B. unter Verwendung des TBB- oder handgerollten Threading-Modells) und dann
ausführttime numactl --physcpubind=0-23 ./myprocess
und dann ausführen
time numactl --physcpubind=0-47 ./myprocess
Letzteres sollte in etwa 10-20% weniger Zeit laufen. Wenn Ihr Prozess stark E/A-blockiert ist, kann das Ergebnis anders sein.
Ersteres deaktiviert Hyperthreading, indem es den Threads nur erlaubt, auf einem einzigen logischen Prozessor (von jedem Kern) zu laufen, während letzteres Hyperthreading aktiviert, indem es den Threads erlaubt, auf 2 logischen Prozessoren (von jedem Kern) zu laufen.
Die Auslastung sollte in beiden Fällen als 48,0 gemeldet werden ... was, wie Sie sehen können, sehr irreführend ist.