- Spegnimento
- 5 settembre 2026 alle ore 15:18 UTC
- Autore
- Kamo
- Impegno
- 4d5ccc4
Correggere il commit precedente, che era a metà destra e ha causato un corto esodo. La diagnosi di memoria era corretta: quattro lavoratori, ciascuno carica la propria copia ~3GB del set di modelli argos, non si adatta a un limite di 12Gi, e il kernel che reclama mmapped model pages è quello che ha fatto ogni coppia di lingua fredda prendere secondi. La caduta a due lavoratori era il rimedio sbagliato. /lingue è servito da questi stessi lavoratori del gunicorn, così con entrambi all'interno di una lunga traduzione il sonda di prontezza non può essere risposto — e il 2026-09-05 entrambe le repliche hanno lasciato la Servizio endpoint in una sola volta e la traduzione si è fermata completamente. Il punto finale della salute ha bisogno di un lavoratore libero di rispondere. Quattro lavoratori con la memoria per tenere in realtà i loro modelli soddisfa entrambi vincoli. Quella memoria non esiste su k1m1, che trasporta il controllo aereo, il database e i costruttori CI al ~95% delle sue richieste di memoria — chiedendo per esso c'è quello che ha fatto la seconda replica non riescono a programmare mid-rollout. Quindi... il pod si sposta a k3m1, al ~63% e già tenendo lo stesso modello impostato a questo hostPath da un periodo precedente. Entrambe le repliche sono sempre state fissate ad un singolo nodo; questo cambia quale nodo, non la storia ridondanza. Verificato dopo rollout: entrambe le repliche Pronti su k3m1, entrambe nel Servizio endpoints, en->ru ritorno output corretto.