- Verschifft
- 5. September 2026 um 15:18 UTC
- Autor
- Kamo
- Ausschuss
- 4d5ccc4
Korrektur der vorherigen Commit, die halb richtig war und einen kurzen Ausfall verursachte. Die Gedächtnisdiagnose war korrekt: vier Arbeiter, jeder lädt seine eigene 3 GB-Kopie der argos Modell-Set, passen Sie nicht auf ein 12Gi-Limit, und der Kernel-Reclaiming mmappierte Modellseiten ist das, was jedes kalte Sprachpaar Sekunden dauern ließ. Auf zwei Arbeiter zu fallen war das falsche Mittel. /Sprachen werden von diesen serviert gleiche Gunicorn Arbeiter, so mit beiden in einer langen Übersetzung der Bereitschaftssonde kann nicht beantwortet werden - und am 2026-09-05 verließen beide Repliken die Service-Endpunkte auf einmal und Übersetzung ganz eingestellt. Der gesundheitliche Endpunkt braucht einen Arbeitnehmer, der dies beantworten kann. Vier Arbeiter mit der Erinnerung, ihre Modelle tatsächlich zu halten, befriedigt beide Zwänge. Dieser Speicher existiert nicht auf k1m1, das die Steuerung trägt Flugzeug, die Datenbank und die CI-Builder bei 95% seiner Speicheranfragen für es gibt es, was die zweite Replik nicht zu planen mid-rollout. Also die Hülse bewegt sich auf k3m1, bei 63% und bereits mit dem gleichen Modell-Set an diesem hostPath aus einer früheren Periode. Beide Repliken wurden immer an eine einzige befestigt node; dies ändert, welcher Knoten, nicht die Redundanz-Geschichte. Nach dem Rollout verifiziert: Beide Repliken Ready auf k3m1, beide im Service endpoints, en--'ru Rückkehr korrekte Ausgabe.