Optimierte Profile für die Workload-Optimierung von Linux-Servern

Optimierte Profile zur Optimierung der Serverauslastung

Die Standard-Einstellungen von Linux sind auf Kompatibilität und nicht auf Leistung ausgelegt. Der „tuned“-Daemon enthält vordefinierte Profile, die CPU-Governer, I/O-Scheduler, Kernel-Parameter und Netzwerkpuffer an eine bestimmte Auslastung anpassen. Dieser Beitrag behandelt, wie die Profile funktionieren, welches Profil für gängige Serverrollen geeignet ist und wie man benutzerdefinierte Profile erstellt und in einer Serverflotte bereitstellt.

So funktionieren abgestimmte Profile

Ein Profil ist ein Verzeichnis unter /usr/lib/tuned/profiles/ (system) oder /etc/tuned/profiles/ (custom), das eine tuned.conf Datei enthält. Die Konfigurationsdatei gruppiert die Parameter nach Plugins: [cpu], [disk], [sysctl], [vm], [bootloader], und so weiter. Wenn Sie ein Profil aktivieren, wendet der „tuned“-Daemon alle Parameter auf einmal an, anstatt Dutzende von sysctl und sysfs Befehle manuell auszuführen.

Profile können mithilfe der include Anweisung. Das throughput-performance Profil kann beispielsweise als Grundlage für ein benutzerdefiniertes Datenbankprofil dienen, das lediglich vm.swappiness die Einstellung für „Transparent Huge Pages“ überschreibt.

„tuned“ läuft in zwei Modi. Bei der statischen Optimierung wird das Profil einmalig bei der Aktivierung angewendet und das System anschließend nicht weiter beeinflusst – genau das, was Sie auf Produktionsservern benötigen, bei denen Konsistenz wichtiger ist als Energieeinsparungen. Die dynamische Optimierung überwacht die Festplatten-, Netzwerk- und Auslastungsnutzung in Echtzeit und passt die Einstellungen spontan an. Leistungsprofile deaktivieren die dynamische Optimierung standardmäßig, um den Overhead durch die Überwachung zu vermeiden.

Auswahl des richtigen Profils für Ihre Arbeitslast

tuned liefert ein Dutzend Profile aus, die die gängigsten Workloads abdecken. Wählen Sie das Profil aus, das der tatsächlichen Nutzung des Servers entspricht, anstatt das Standardprofil balanced beizubehalten.

Für bestimmte Datenbank-Engines wird „tuned“ zusätzlich mitgeliefert postgresql, mssqlsowie oracle Profile, die über throughput-performance durch die Optimierung der Parameter für den gemeinsamen Speicher und den Kernel-Scheduler für diese Engines.

Auf Servern mit mehreren Sockeln spielt die NUMA-Topologie eine Rolle. Der Speicherzugriff auf entfernte Knoten kann zwei- bis dreimal langsamer sein als der lokale Zugriff. Deaktivieren Sie bei latenzkritischen Workloads auf Systemen mit zwei Sockeln den automatischen NUMA-Ausgleich im Profil und weisen Sie Prozesse manuell bestimmten Knoten zu.

Installation und Anwendung von Profilen

Installieren Sie tuned unter RHEL, Rocky, AlmaLinux oder Fedora:

dnf install tuned
systemctl enable --now tuned

Unter Debian und Ubuntu heißt das Paket ebenfalls tuned und wird über apt. Falls power-profiles-daemon bereits läuft, deaktivieren Sie es, um Konflikte zu vermeiden:

systemctl mask --now power-profiles-daemon

Listen Sie die verfügbaren Profile auf, fragen Sie „tuned“, was es für die Hardware empfiehlt, wenden Sie ein Profil an und überprüfen Sie es:

tuned-adm list
tuned-adm recommend
tuned-adm profile throughput-performance
tuned-adm verify

Das aktive Profil wird in /etc/tuned/active_profile und bleibt auch nach einem Neustart erhalten. Um die Optimierung vollständig zu deaktivieren und den Ausgangszustand zu ermitteln, führen Sie folgenden Befehl aus: tuned-adm off.

Erstellen eines benutzerdefinierten Profils für KI-, ML- und Workloads mit hoher Bandbreite

Wenn Sie mit den Standardprofilen bereits zu 90 % am Ziel sind, erstellen Sie ein benutzerdefiniertes Profil, das von dem am besten passenden Profil abgeleitet wird und die verbleibenden Parameter überschreibt. Beginnen Sie mit einem Verzeichnis und einer Konfigurationsdatei:

mkdir -p /etc/tuned/ai-gpu
cat > /etc/tuned/ai-gpu/tuned.conf <<'EOF'
[main]
summary=Custom profile for GPU training with high-bandwidth networking
include=accelerator-performance
 
[cpu]
governor=performance
 
[sysctl]
kernel.numa_balancing=0
net.core.rmem_max=268435456
net.core.wmem_max=268435456
net.ipv4.tcp_rmem=4096 87380 268435456
net.ipv4.tcp_wmem=4096 65536 268435456
 
[vm]
transparent_hugepages=never
 
[bootloader]
cmdline=hugepagesz=2M hugepages=16384 <a target="_blank" rel="noopener noreferrer" href="https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit">iommu</a>=pt
EOF
 
tuned-adm profile ai-gpu

Die wichtigsten Einstellungen hierbei:

• numa_balancing=0 verhindert, dass der Kernel während des Trainings Speicher zwischen den Sockeln verschiebt – eine häufige Ursache für Verzögerungen bei Dual-Socket-GPU-Systemen.
• Die rmem_max und tcp_rmem erhöhen die Obergrenze des Socket-Puffers auf 256 MB. Bei 25G-, 40G- oder 100G-Verbindungen zwischen Trainingsknoten begrenzen die Standardpuffergrößen den Durchsatz deutlich unterhalb der Leitungsrate.
• transparent_hugepages=never beseitigt den durch THP verursachten Latenz-Jitter bei Frameworks wie PyTorch und TensorFlow, die große Tensoren zuweisen.
• iommu=pt versetzt IOMMU in den Passthrough-Modus, der für GPU- und NIC-Passthrough erforderlich ist, und reduziert den Overhead bei Bare-Metal-DMA.

Alles unter [bootloader] erfordert einen Neustart. Führen Sie nach der Aktivierung des Profils tuned-adm verify aus, um zu überprüfen, ob die Laufzeitparameter übernommen wurden, und journalctl -u tuned auf Fehler. Führen Sie vor und nach der Änderung einen Benchmark mit iostat -xz, numastatund dem entsprechenden Workload-Tool (iperf3, fiooder den eigentlichen Trainingslauf).

Ein Kompromiss, der ausdrücklich erwähnt werden sollte: Das Deaktivieren der CPU-Sicherheitsmaßnahmen bringt bei GPU-Workloads einen Gewinn von etwa 3–8 %, kostet jedoch 15–30 % bei Workloads mit intensiven Systemaufrufmustern. Treffen Sie Ihre Entscheidung auf der Grundlage des Bedrohungsmodells für den Rechner. Innerhalb eines dedizierten Trainingsclusters hinter einer Firewall spricht die Bilanz in der Regel für eine Deaktivierung. Auf einem Multi-Tenant-Host sollten Sie sie aktiviert lassen.

Verwaltung von Profilen über eine Serverflotte hinweg

Die manuelle Anwendung von „tuned“ ist ab einer Handvoll Servern nicht mehr praktikabel. Ansible löst dieses Problem sauber. Ein einziges Playbook installiert „tuned“ und legt benutzerdefinierte Profilverzeichnisse unter /etc/tuned/ über das template Modul und wendet das richtige Profil je nach Inventargruppe an.

Zuordnung von Profilen zu Rollen im Inventar:

• GPU- und KI-Knoten: accelerator-performanceoder ein benutzerdefiniertes Profil, das davon erbt
• Datenbankserver: throughput-performance oder das enginespezifische Profil
• CDN- und Edge-Knoten, die Datenverkehr mit hoher Bandbreite übertragen: network-throughput
• API- und Webserver hinter einem Load Balancer: network-latency
• VPS- und KVM-Gäste: virtual-guest
• Hypervisor-Hosts: virtual-host

Abweichungen sind das eigentliche Betriebsproblem. Manuelle sysctl Änderungen, Paket-Upgrades mit neuen Standardeinstellungen oder ein anderes Konfigurationsmanagement-Tool, das „tuned“ überschreibt, führen dazu, dass die Einstellungen von den Vorgaben des Profils abweichen. Planen Sie einen Ansible-Job ein, der tuned-adm active und tuned-adm verify über Cron ausgeführt wird und bei Fehlern eine Warnmeldung ausgibt. Achten Sie /var/log/tuned/tuned.log auf Zeilen mit dem Hinweis „Verification failed“.

Fazit

„tuned“ nimmt den Kernel- und sysctl-Tuning das Rätselraten weitgehend ab. Die Standardeinstellungen sind für den allgemeinen Gebrauch gut genug, und die arbeitslastspezifischen Profile wie accelerator-performance, throughput-performanceund network-throughput bringen Sie schon fast zur Optimierung, ohne dass Sie eine einzige Konfigurationsdatei schreiben müssen.

• Wählen Sie das am besten passende Standardprofil aus, führen Sie tuned-adm verifyund führen Sie anschließend einen Benchmark durch
• Erstellen Sie benutzerdefinierte Profile, indem Sie von einem Standardprofil erben und nur die erforderlichen Einstellungen überschreiben
• Gehen Sie bei der NUMA-Auslastung, bei Hugepages und bei den Netzwerkpuffergrößen auf GPU- und Hochbandbreiten-Systemen bewusst vor
• Stellen Sie die Umgebung mit Ansible bereit und führen Sie planmäßige Audits durch, um Abweichungen zu erkennen

Benötigen Sie Bare-Metal-Kapazität mit ausreichendem Bandbreiten-Spielraum, um diese Einstellungen tatsächlich nutzen zu können? Sprechen Sie mit FDC über dedizierte Server, die speziell für Workloads mit hohem Durchsatz und GPU-Anwendungen ausgelegt sind.