Linux:
Der Linux-Kernel hat eine großartige Implementierung für diese Angelegenheit und viele Funktionen / Einstellungen, die dazu bestimmt sind, die Ressourcen für den laufenden Prozess zu verwalten (über CPU-Governors, sysctl oder cgroup). In einer solchen Situation ist es erforderlich, diese Einstellungen zusammen mit der Swap-Anpassung (falls erforderlich) zu optimieren empfohlen, im Grunde passen Sie die Standardfunktionsweise an Ihr Gerät an.
Benchmarks, Stresstests und Situationsanalysen nach Übernahme der Änderungen sind vor allem auf Produktionsservern ein Muss. Der Leistungsgewinn kann sehr wichtig sein, wenn die Kernel-Einstellungen an die erforderliche Nutzung angepasst werden, andererseits erfordert dies Tests und ein gutes Verständnis der verschiedenen Einstellungen, was für einen Administrator zeitaufwändig ist.
Linux verwendet Governors, um die CPU-Ressourcen zwischen den laufenden Anwendungen auszugleichen, viele Governors sind verfügbar; Abhängig vom Kernel Ihrer Distribution sind möglicherweise einige Gouverneure nicht verfügbar (der Kernel kann neu erstellt werden, um fehlende oder nicht vorgeschaltete Gouverneure hinzuzufügen). Sie können den aktuellen Governor überprüfen, ihn ändern und, was in diesem Fall noch wichtiger ist, seine Einstellungen anpassen.
Zusätzliche Dokumentationen:Lektüre, Anleitung, ähnliche Frage, Frequenzskalierung, Wahl des Reglers, der Leistungsregler und cpufreq.
SysCtl:
Sysctl ist ein Werkzeug zum Untersuchen und Ändern von Kernelparametern zur Laufzeit, Anpassungen können mit der Konfigurationsdatei /etc/sysctl.conf dauerhaft vorgenommen werden , dies ist ein wichtiger Teil dieser Antwort, da viele Kerneleinstellungen mit Sysctl geändert werden können, eine vollständige Liste der verfügbaren Einstellungen kann mit dem Befehl sysctl -a angezeigt werden , Details finden Sie in diesem und diesem Artikel.
Cgroup:
Der Kernel bietet die Funktion:Kontrollgruppen, die in diesem Handbuch mit ihrem kürzeren Namen cgroups bezeichnet werden. Mit Cgroups können Sie Ressourcen wie CPU-Zeit, Systemspeicher, Netzwerkbandbreite oder Kombinationen dieser Ressourcen benutzerdefinierten Gruppen von Tasks (Prozessen) zuweisen, die auf einem System ausgeführt werden. Sie können die von Ihnen konfigurierten Kontrollgruppen überwachen, Kontrollgruppen den Zugriff auf bestimmte Ressourcen verweigern und Ihre Kontrollgruppen sogar dynamisch auf einem laufenden System neu konfigurieren. Der Dienst cgconfig (Control Group Config) kann so konfiguriert werden, dass er beim Booten startet und Ihre vordefinierten Cgroups wiederherstellt, wodurch sie über Neustarts hinweg bestehen bleiben.
Quelle, weiterführende Literatur und Frage zum Thema.
RAM:
Dies kann nützlich sein, wenn das System über eine begrenzte Menge an RAM verfügt. Andernfalls können Sie den Swap deaktivieren, um hauptsächlich den RAM zu verwenden. Das Swap-System kann pro Prozess oder mit den Swapiness-Einstellungen angepasst werden. Bei Bedarf können die Ressourcen (RAM) pro Prozess mit ulimit begrenzt werden (wird auch zum Begrenzen anderer Ressourcen verwendet).
Festplatte:
Festplatten-E/A-Einstellungen (E/A-Scheduler) sowie die Clustergröße können geändert werden.
Alternativen:
Alternativ können auch andere Tools wie nice, cpulimit, cpuset, tasket oder ulimit verwendet werden.
Die beste Antwort darauf ist "saugen und sehen" ... führen Sie einige Belastungstests durch und sehen Sie, was die besten Ergebnisse liefert. Das liegt daran, dass sehr geringfügige Nuancen im Verhalten Ihrer Threads zu Leistungsunterschieden führen können.
Das Folgende basiert weitgehend auf meiner eigenen Erfahrung...
Wo anfangen?
Die Fähigkeit von Linux zu verhindern, dass Threads ausgehungert werden, ist ziemlich gut. Das bedeutet nicht unbedingt, dass jeder Thread einen gleichmäßigen Anteil am Kuchen bekommt, aber alle Threads bekommen zumindest etwas Kuchen ab. Wenn Sie zwei Threads haben, die um CPU-Zeit konkurrieren ... sagen wir, einer versucht, 100 % CPU zu verwenden, und ein anderer versucht, nur 10 % zu verwenden ... dann wundern Sie sich nicht, wenn sich das bei 91 % und 9 % oder irgendwo ausgleicht darum herum.
Die Gesamtleistung kann abnehmen, wenn eine bestimmte Ressource stark ist überabonniert. Dies gilt insbesondere für Festplatten-IO auf sich drehenden Festplatten. Der Kopf muss sich physisch zwischen Orten auf der Festplatte bewegen (suchen) und kontinuierlich Das Wechseln zwischen verschiedenen Dateien kann zu einer erheblichen Verlangsamung führen. Aber dieser Effekt ist oft ziemlich klein, wenn ein Thread stark IO-gebunden ist und ein anderer ein wenig tun möchte IO.
Zusammen bedeuten diese beiden Dinge, dass es oft besser ist, 20 % überzeichnet zu sein als 20 % unterzeichnet. Mit anderen Worten:Reservieren Sie keine CPU-Zeit für Threads, die nicht versuchen, viel CPU zu verbrauchen.
Beispiel:Wenn Sie CPU-gebundene Threads und Festplatten-IO-gebundene Threads haben und 8 Kerne und 1 Festplatte haben, dann beginnen Sie mit 8 CPU-gebundene Threads und ein Festplatten-IO-gebundener Thread. 7 und 1 lassen einen Kern möglicherweise die meiste Zeit im Leerlauf. 8 und 1 werden den HD-Thread mit ziemlicher Sicherheit nicht aushungern, was bedeutet, dass Sie sowohl HD als auch CPU voll ausnutzen.
Die Gefahr kurzlebiger Threads
Seien Sie vorsichtig, dass Linux mit viel zu kämpfen hat von kurzlebigen Fäden. Deutlicher wird dies bei absichtlichen Versuchen, ein System zu beschädigen. Aber ständig spawnende Threads/Prozesse können Linux dazu bringen, sich schlecht zu verhalten.
In Ihrer Frage haben Sie dedizierte Worker-Threads beschrieben, die wie langlebige Threads klingen. Das klingt nach dem richtigen Ansatz.
Der London-Bus-Effekt
Du wartest eine halbe Stunde auf einen Bus, dann kommen gleich 5 vorbei. Dies geschieht, weil Passagiere, die in den vorderen Bus einsteigen, ihn verlangsamen. Der Mangel an Passagieren in den späteren Bussen beschleunigt sie und verursacht einen Bündelungseffekt.
Das gleiche Problem kann beim Threading auftreten, insbesondere wenn Threads um Ressourcen konkurrieren. Wenn Sie Threads haben, die vorhersehbar zwischen Aufgaben wechseln, z. B. von einer Festplatte lesen und dann auf eine andere schreiben, neigen sie möglicherweise dazu, sich zusammenzuballen, anstatt sich stochastisch zu verteilen, wie Sie vielleicht erwarten. So kann eine Ressource die Verwendung einer anderen verlangsamen. Aus diesem Grund kann es manchmal besser sein, die Aufgaben eines Threads weiter zu unterteilen.
Gruppen
Ich vermeide es, zu sehr ins Detail zu gehen. Aber ich sollte erwähnen, dass Linux eine Funktion namens "cgroups" hat, die es Ihnen ermöglicht, Prozesse zu gruppieren und ihre kollektiven Ressourcen zu begrenzen. Dies kann bei der weiteren Leistungsoptimierung sehr nützlich sein.
Es gibt eine kurze Diskussion von ihnen hier. Aber ich würde Ihnen raten, ein wenig Zeit auf Google zu verbringen, um ihre volle Leistungsfähigkeit zu sehen, da sie Ihnen auf lange Sicht helfen können.