Solución 1:
Sin memoria.
18 de diciembre 23:24:59 ip-10-0-3-36 kernel:[ 775.566936] Memoria insuficiente :Eliminar proceso 4973 (java) puntuación 0 o sacrificar niño
Desde el mismo registro (ps);
[ 775.561798] [ 4973] 500 4973 4295425981 2435 71 50 0 java
4295425.981 es de alrededor de 4 TB. y la línea total-vm:17181703924kB muestra alrededor de 17 TB.
¿Puedes depurar tu rutina de asignación de memoria? en cuanto a mí, su aplicación tiene un bucle defectuoso en alguna parte y debe tomar todos los recursos disponibles, y también el intercambio disponible.
Solución 2:
Dec 18 23:24:59 ip-10-0-3-36 kernel: [ 775.214705] shmem_fallocate+0x32d/0x440
Dec 18 23:24:59 ip-10-0-3-36 kernel: [ 775.217182] vfs_fallocate+0x13f/0x260
Dec 18 23:24:59 ip-10-0-3-36 kernel: [ 775.219525] SyS_fallocate+0x43/0x80
Dec 18 23:24:59 ip-10-0-3-36 kernel: [ 775.221657] do_syscall_64+0x67/0x100
Su proceso de solicitud está intentando invocar fallocate en el sistema de archivos shmem. Desde una búsqueda rápida en Google, parece que ZGC usa fallacate para tomar la memoria del montón inicial del sistema de archivos shm y procede a usar fallacate para expandir el montón. Tal uso de llamada al sistema de fallocate es bastante inusual, por lo que se trata de un error de ZGC (como ya sospechaba) o algo más está perdiendo mucha memoria, lo que hace que la expansión del almacenamiento dinámico falle.
Le sugiero que configure ZGC para evitar asignaciones adicionales de tiempo de ejecución (establezca Xms y Xmx al mismo valor). Es posible que esto no resuelva su problema, si la pérdida de memoria ocurre debido a algo no relacionado, pero al menos tendrá una mejor oportunidad de encontrar al verdadero culpable.
Tenga en cuenta que su configuración general es algo peligrosa:aparentemente, a ZGC le gusta tener mucha memoria contigua, pero si tiene un montón de 190 G en una máquina con 240 G de RAM, es posible que no haya una región contigua lo suficientemente grande para fallocate de. En ese caso, ZGC recurrirá a seleccionar pequeñas regiones de memoria con más fallocate llamadas (consulte la descripción del informe de error vinculado), y el problema se oscurecerá nuevamente... Habilite la compatibilidad con páginas enormes en JVM (páginas enormes normales , no páginas enormes transparentes !) y preasignar páginas enormes durante el arranque (con el argumento del kernel); de todos modos, se recomienda usar páginas enormes para los tamaños de almacenamiento dinámico.