- Shipped
- 23 settembre 2026 alle ore 10:30 UTC
- Author
- Kamo
- Commit
- 3e76660
Il dispiegamento non aveva risorse: bloccare affatto. Nessuna richiesta, quindi scheduler non poteva ragionare sull'impronta di questo pod; nessun limite, quindi nulla ha bloccato il JVM's -XX:MaxRAMPercentage=70.0 heap a corto del RAM del nodo (ogni nodo qui è ~126GiB). Questo servizio anche completamente tamponi ogni richiesta e corpo di risposta in avanti nel mucchio (readAllBytes / ByteArrayResource), buffers a multipart upload a SECOND tempo in cui la ricostruisce per l'upstream hop, e permette di caricare fino a multipart.max-file-size: 500MB -- così un singolo grande upload può transiently bisogno approssimativamente 1Gi solo per byte corpo, sull'unico servizio che fronti ogni chiamata /api/** sulla piattaforma (2 repliche). request.memory: 512Mi. limit.memory: 4Gi -- sopra il pavimento 2Gi questo Il modello Dockerfile richiede altrove (sotto questo, heap-at-70%-of-limit plus non-sapone non si chiude e il pod OOMKills in uso normale; vedere la distribuzione di emailservice/mediaservice. yaml commenta questo prestiti), e dimensionato come MediaService, l'altro grande servizio corpo su questo modello, piuttosto che il pavimento altri servizi utilizzano qui. Corrente uso per pod è ~610Mi RSS (kubectl top), quindi questo è headroom, non un correzione di un OOM osservato. Questo è un stopgap, non la correzione reale: lo streaming del proxy invece di tamponare i corpi pieni è la difesa reale contro un inondazione deliberata grandi upload concorrenti, ed è un cambiamento più grande di questo compito copre. 500MB è un cappuccio già deliberato esistente (si trova sotto MediaService's indennità interna 3GB e corrisponde al livello di gateway del servizio di sicurezza cap), quindi è lasciato come è piuttosto che ristretto come un sostituto streaming. DeploymentResourcesTest spills che il manifesto ha effettivamente risorse blocco con una richiesta e un limite; la cancellazione fallisce il test.