Seite 12 - Linux

Auf Multi-Socket-Servern ist nicht jeder Arbeitsspeicher fuer jede CPU gleich schnell erreichbar. NUMA beschreibt genau diese Asymmetrie, und wer MySQL oder PHP-FPM ohne Ruecksicht auf NUMA-Nodes betreibt, riskiert stille Latenzverluste, die kein einzelner Konfigurationswert im Anwendungslayer erklaeren kann.

Ein überlasteter Webserver liegt selten allein am Anwendungscode, sondern häufig an unpassenden Betriebssystem-Limits und falsch dimensionierten PHP-FPM-Pools, die unter echter Last kollabieren. Dieser Artikel zeigt praxisnah, wie Nginx-Worker-Prozesse, Datei-Deskriptor-Limits, der TCP-Backlog und pm.max_children anhand des tatsächlich verfügbaren Arbeitsspeichers korrekt dimensioniert werden, und wie sich jede einzelne Änderung mit echten Benchmark-Messwerten belegen lässt, statt sich auf reine Vermutungen zu verlassen.

Wo Docker eine komplette Runtime samt Image-Format, Registry-Anbindung und Orchestrierung mitbringt, setzt systemd-nspawn auf das Gegenteil: ein minimalistisches, tief in systemd integriertes Werkzeug, das ein chroot-artiges Verzeichnis oder Image in wenigen Sekunden in einen vollwertig isolierten Container verwandelt, ganz ohne Daemon, Registry oder Compose-Datei.

Huge Pages reduzieren die Anzahl der Page-Table-Eintraege, die die CPU fuer den grossen InnoDB Buffer Pool verwalten muss, und senken damit die Rate an teuren Translation-Lookaside-Buffer-Fehlschlaegen. Wer dabei Transparent Huge Pages mit klassischen Huge Pages verwechselt, riskiert genau die Latenzspitzen, die eigentlich vermieden werden sollten.

Bare Metal, virtuelle Maschinen und Container bilden ein Spektrum aus Isolation, Overhead und Bereitstellungsgeschwindigkeit, keine einfache Entweder-oder-Entscheidung. Dieser Artikel erklärt, wann volle Hardware-Kontrolle nötig ist, wann Hypervisor-Isolation für Multi-Tenancy sinnvoll wird und wann Container die schnellere Wahl sind, sowie den hybriden Ansatz, den die meisten produktiven Hosting-Umgebungen tatsächlich einsetzen, um Kosten, Sicherheit und Betriebsaufwand auszubalancieren.

Eine Umgebungsvariable, die in der Shell des Administrators funktioniert, aber im PHP-FPM-Prozess einer Magento-Anwendung schlicht fehlt, ist eines der häufigsten Rätsel im Serveralltag. Der Grund liegt fast immer im Scope: Umgebungsvariablen werden nur an Kindprozesse vererbt, niemals rückwärts oder quer zu unabhängigen Prozessbäumen, und systemweiter Scope funktioniert grundlegend anders als benutzerspezifischer Scope.

Die Warnung 'overcommit_memory is set to 0, background save may fail' beim Start von Redis gehört zu den häufigsten Kernel-Tuning-Hinweisen in Magento-Hosting-Umgebungen. Wer die drei Overcommit-Modi und ihren Zusammenhang mit dem OOM-Killer versteht, trifft die richtige Entscheidung statt blind einer Copy-Paste-Empfehlung zu folgen.

Ein einzelner Netzwerk-Port ist auf produktiven Servern ein struktureller Single Point of Failure, egal wie zuverlässig die restliche Hardware ist. Linux Bonding bündelt mehrere physische Interfaces zu einem logischen Bond und schafft damit, je nach gewähltem Modus, entweder Ausfallsicherheit, gebündelte Bandbreite oder beides gleichzeitig.

Der PHP-FPM Process Manager entscheidet, wie viele parallele Requests ein Magento-Server verarbeiten kann, bevor Anfragen in der Warteschlange stehen bleiben oder der Arbeitsspeicher durch zu viele Worker aufgebraucht wird. Wer pm.max_children nach Bauchgefuehl setzt, riskiert entweder verschenkte Kapazitaet oder einen Out-of-Memory-Absturz unter Last.

Ein Reindex, ein Backup oder ein grosser Cron-Job konkurriert ohne gezielte Prioritaeten direkt mit den PHP-FPM-Workern um dieselbe CPU-Zeit und denselben Festplattenzugriff. nice und ionice erlauben, Hintergrundjobs bewusst zurueckzustufen, sodass sie erst dann Ressourcen bekommen, wenn der Webserver sie gerade nicht braucht.