- Se descapó
- 25 de agosto de 2026 a las 19:39 UTC
- Autor
- Kamo
- Compromit
- c22edbb
Dos faltas, una de ellas mía. MINE PRIMERO: la puerta más o más "nodo" añadido con el script de auto-reconexión puntiagudo en una DIRECTORY, y el nodo del corredor resuelve un directorio desnudo como módulo a ejecutar " MODULE-NOT-FOUND, exit 1, desplegable fallido. Ambos empujan después de él (el solución condicional-restart y la solución de false-alarma canaria) por lo tanto nunca se envió; Falló 9150 y 9152 y el grupo se quedó en 3342ccd. Nombrar la prueba el archivo lo arregla. Verificado con el comando exacto que el comando CI corre, desde la raíz repo. LA OMM: "se ha producido un error" de la nada a las 19:30 fue una OOMKill (salida 137), no una fuga y no el reinicio del despliegue. En la vaina en vivo informó MaxHeapSize=32210157568 un techo de 32 GB de montón dentro de un 2 GiB recipiente. Este es Java 8 en un huésped cgroup v2: su detección de contenedores nunca lee /sys/fs/cgroup/memory.max (el límite ES visible allí, 2147483648), por lo que en su lugar se enfrentó a los 128 GB del huésped. Edén creció a 1,0 GB y viejo gen a 0,93 GB, mientras que el set en vivo era de 23 MB; sin presión para cobrar, RSS Subió 821 MiB - 1963 MiB durante cuatro horas y el núcleo lo mató en el límite. Prometeo muestra esa curva exactamente, y comenzó ANTES del canario existió, por lo que el canario no está implicado. -Xmx768m elimina la dependencia de la detección de contenedores por completo. MALLOC-ARENA-MAX y ActiveProcessorCount stop glibc y el GC se dimensionar contra el Nodo es 48 CPUs. Leer el límite de nuevo fue el movimiento equivocado por sí solo: 1Gi-2Gi Ya se había probado y sólo había cambiado el tiempo que tardó. Alertas añadidas tanto para el enfoque (-85% del límite) como para el evento (OOMKilled), porque la puerta no se degrada cuando se queda sin memoria, se mata, y cada escritorio abierto va con él.