Verwenden und Verstehen von systembezogenen Planungsoptionen in einem Desktop-Kontext

In systemd-Dienstdateien können die folgenden terminbezogenen Optionen festgelegt werden ( korrigieren Sie mich auf der systemd.execManpage , wenn ich falsch liege):

Nice Legt die Standard- Nizza- Ebene (Planungspriorität) für ausgeführte Prozesse fest. Nimmt eine Ganzzahl zwischen -20 (höchste Priorität) und 19 (niedrigste Priorität). Siehe Setpriority (2) für Details.

Welches ist das vertraute schöne Niveau. Es scheint, dass seine Wirkung aufgrund der "Autogroup" -Funktion der jüngsten Linux-Kernel etwas "untergraben" wird. Die folgenden Optionen sind möglicherweise genau das, was ich wirklich einstellen möchte, damit sich die Prozesse für meine Desktop-Erfahrung gut verhalten.

CPUSchedulingPolicy Legt die CPU-Planungsrichtlinie für ausgeführte Prozesse fest. Nimmt eine von anderen, Batch, Idle, Fifo oder rr. Siehe sched_setscheduler (2) für Details.

CPUSchedulingPriority Legt die CPU-Planungspriorität für ausgeführte Prozesse fest. Der verfügbare Prioritätsbereich hängt von der ausgewählten CPU-Planungsrichtlinie ab (siehe oben). Für Echtzeit-Planungsrichtlinien kann eine Ganzzahl zwischen 1 (niedrigste Priorität) und 99 (höchste Priorität) verwendet werden. Siehe sched_setscheduler (2) für Details.

CPUSchedulingResetOnFork Nimmt ein boolesches Argument an. Wenn dies der Fall ist, werden erhöhte CPU-Planungsprioritäten und -Richtlinien beim Verzweigen der ausgeführten Prozesse zurückgesetzt und können daher nicht in untergeordnete Prozesse gelangen. Siehe sched_setscheduler (2) für Details. Der Standardwert ist false.

Ich verstehe die letzte Option. Aus der Erklärung der ersten beiden geht hervor, dass ich eine Planungsrichtlinie und dann angesichts dieser Richtlinie eine Priorität auswählen kann. Mir ist nicht ganz klar, was ich für welche Art von Aufgaben wählen soll. Ist es beispielsweise sicher, für Sicherungsaufgaben "Leerlauf" zu wählen (relativ CPU-intensiv, weil Deduplizierung), oder ist eine andere besser geeignet?

Im Allgemeinen suche ich nach einem verständlichen Überblick über jede Richtlinie mit ihren Prioritäten und ihrer Eignung für bestimmte Zwecke. Auch die Interaktion mit dem netten Level ist von Interesse.

Neben der CPU-Planung gibt es eine E / A-Planung. Ich denke, das entspricht ionice(korrigiere mich, wenn ich falsch liege).

IOSchedulingClass Legt die E / A-Planungsklasse für ausgeführte Prozesse fest. Nimmt eine Ganzzahl zwischen 0 und 3 oder eine der Zeichenfolgen keine, Echtzeit, Best-Effort oder Leerlauf. Siehe ioprio_set (2) für Details.

IOSchedulingPriority Legt die E / A-Planungspriorität für ausgeführte Prozesse fest. Nimmt eine Ganzzahl zwischen 0 (höchste Priorität) und 7 (niedrigste Priorität). Die verfügbaren Prioritäten hängen von der ausgewählten E / A-Planungsklasse ab (siehe oben). Siehe ioprio_set (2) für Details.

Wir sehen hier die gleiche Struktur wie bei der CPU-Planung. Ich suche auch nach der gleichen Art von Informationen.

Bei allen "Planungs" -Optionen sind die genannten Manpages für mich nicht klar genug, vor allem, wenn es darum geht, Dinge aus der Sicht eines technisch eher geneigten Desktop-Benutzers zu übersetzen.

CPUScheduling {Richtlinie | Priorität}

Der Link sagt Ihnen, dass CPUSchedulingPrioritynur für fifooder rr("Echtzeit") Aufgaben eingestellt werden sollte. Sie möchten den Diensten keine Echtzeitplanung aufzwingen.

CPUSchedulingPolicy=other ist die Standardeinstellung.

Das lässt batchund idle. Der Unterschied zwischen ihnen ist nur relevant, wenn mehrere Aufgaben mit Leerlaufpriorität gleichzeitig CPU verbrauchen. Theoretisch batchergibt sich ein höherer Durchsatz (im Austausch für längere Latenzen). Aber es ist kein großer Gewinn, also ist es in diesem Fall nicht wirklich relevant.

idleverhungert buchstäblich, wenn irgendetwas anderes die CPU will. Bei alten UNIX-Systemen mit einem einzigen Kern ist die CPU-Priorität weniger wichtig als früher. Ich wäre glücklicher nice, wenn ich mit Level 10 oder 14 anfangen würde , bevor ich darauf zurückgreifen würde idle. Siehe nächster Abschnitt.

Die meisten Desktops sind jedoch die meiste Zeit relativ inaktiv. Und wenn Sie ein CPU-Schwein haben, das die Hintergrundaufgabe vorwegnimmt, verwendet das Schwein häufig nur eine Ihrer CPUs. In diesem Sinne würde ich mich idleim Kontext eines durchschnittlichen Desktops oder Laptops nicht zu riskant fühlen . Es sei denn, es verfügt über eine Atom / Celeron / ARM-CPU mit einer Leistung von 15 Watt oder weniger . dann würde ich mir die Dinge etwas genauer ansehen wollen.

Wird das nette Level durch die Kernel-Autogruppen-Funktion "untergraben"?

Ja.

Autogrouping ist etwas seltsam. Der Autor von systemdmochte die Heuristik nicht einmal für Desktops. Wenn Sie das Deaktivieren der automatischen Gruppierung testen möchten, können Sie sysctl kernel.sched_autogroup_enabled auf einstellen 0. Ich denke, es ist am besten zu testen, indem Sie das System auf permanente Konfiguration einstellen und neu starten, um sicherzustellen, dass Sie alle Autogruppen entfernen.

Dann sollten Sie in der Lage sein, problemlos gute Level für Ihre Dienste zu erreichen. Zumindest in aktuellen Versionen von systemd - siehe nächster Abschnitt.

Zum Beispiel reduziert nette Stufe 10 das Gewicht, das jeder Thread im Linux-CPU-Scheduler hat, auf ungefähr 10%. Nizza Level 14 liegt unter 5%. (Link: vollständige Formel )

Anhang: Wird das nette Level von systemd cgroups 'untergraben'?

Die aktuelle DefaultCPUAccounting= Einstellung ist standardmäßig deaktiviert, es sei denn, sie kann aktiviert werden, ohne dass auch die CPU-Steuerung pro Dienst aktiviert wird. Also sollte es gut sein. Sie können dies in Ihrer aktuellen Dokumentation überprüfen:man systemd-system.conf

Beachten Sie, dass die CPU-Steuerung pro Dienst auch aktiviert wird, wenn ein Dienst CPUAccounting / CPUWeight / StartupCPUWeight / CPUShares / StartupCPUShares festlegt.

Der folgende Blog-Auszug ist veraltet (aber immer noch online). Das Standardverhalten hat sich seitdem geändert und die Referenzdokumentation wurde entsprechend aktualisiert.

Wenn der CPU-Controller im Kernel aktiviert ist, erstellt systemd beim Starten standardmäßig eine cgroup für jeden Dienst. Ohne weitere Konfiguration hat dies bereits einen schönen Effekt: Auf einem Systemd-System erhält jeder Systemdienst eine gleichmäßige Menge an CPU, unabhängig davon, aus wie vielen Prozessen er besteht. Oder mit anderen Worten: Auf Ihrem Webserver erhält MySQL ungefähr die gleiche CPU-Menge wie Apache, selbst wenn letzterer aus 1000 CGI-Skriptprozessen besteht, der erstere jedoch nur aus wenigen Arbeitsaufgaben. (Dieses Verhalten kann deaktiviert werden, siehe DefaultControllers = in /etc/systemd/system.conf.)

Zusätzlich zu dieser Standardeinstellung ist es möglich, die CPU-Freigaben, die ein Dienst mit der Einstellung CPUShares = erhält, explizit zu konfigurieren. Der Standardwert ist 1024. Wenn Sie diese Zahl erhöhen, weisen Sie einem Dienst mehr CPU zu als einem unveränderten bei 1024, wenn Sie ihn verringern, weniger.

http://0pointer.de/blog/projects/resources.html

Der klassische Tuning-Ratschlag lautet "Don't Optimize, Benchmark".

Beginnen Sie mit einem bestimmten Fall, bei dem Sie Bedenken hinsichtlich einer Verbesserung haben und der mit einem bestimmten Leistungsmaßstab verglichen wurde, anstatt sich um allgemeine Ratschläge zu kümmern . Lassen Sie sich mit den Daten auf die richtige Direktive einstellen. Bei Daten kann klar sein, ob Ihr Prozess unter einer schlechten Priorität leidet, die CPU überlastet oder ein anderes Problem aufweist.

Moderne Desktops sind oft sehr schnell zu bedienen, ohne dass eine Abstimmung erforderlich ist.