Seite 7 - Linux

Wenn ein Linux-Server Domainnamen mal auflöst und mal nicht, liegt die Ursache selten am DNS-Server selbst, sondern an der lokalen Auflösungskette davor: resolv.conf, systemd-resolved, nsswitch.conf oder ein hartnäckiger Cache. Dieser Leitfaden führt Schritt für Schritt durch die richtige Prüfreihenfolge, von der Konfigurationsdatei bis zur konkreten Anwendungslaufzeit, und zeigt, warum ein erfolgreicher dig-Aufruf allein noch nichts beweist.

Hohe Systemlast ist nicht automatisch ein Zeichen für einen langsamen Datenträger. Dieser Leitfaden zeigt, wie iostat mit Intervall-Sampling echte Trends von kurzen Lastspitzen unterscheidet, wie iotop den konkreten Prozess hinter hoher I/O-Auslastung identifiziert, und wie Kennzahlen wie %util und await zuverlässig zeigen, ob ein Disk-Problem oder ein Anwendungsproblem vorliegt.

Standard-Unix-Rechte stoppen einen kompromittierten Prozess nicht daran, alles zu lesen, was der Benutzer lesen darf. Mandatory Access Control setzt eine zweite, vom Kernel erzwungene Schranke davor. Dieser Artikel vergleicht SELinux und AppArmor, erklärt labelbasierte und pfadbasierte Policy an echten Beispielen und zeigt, wie man einen MAC-bedingten Permission-Denied zuverlässig diagnostiziert.

Wenn ein Server nach einem Kernel-Panic einfach neu startet, bleibt die eigentliche Ursache im Dunkeln, bis derselbe Absturz erneut passiert. kdump erzeugt beim Kernel-Panic automatisch einen vollständigen Speicherabzug, und das crash-Utility macht diesen vmcore lesbar, mit Backtrace, Prozesszustand und der Stelle im Kernel-Code, an der es geknallt hat.

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.

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.

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.