Solution 1 :
Mémoire insuffisante.
18 décembre 23:24:59 noyau ip-10-0-3-36 :[ 775.566936] Mémoire insuffisante :Tuer le processus 4973 (java) score 0 ou sacrifier l'enfant
À partir du même journal (ps);
[ 775.561798] [ 4973] 500 4973 4295425981 2435 71 50 0 Java
4295425.981 est d'environ 4 To. et la ligne total-vm:17181703924kB affiche environ 17 To.
Pouvez-vous déboguer votre routine d'allocation de mémoire ? quant à moi, votre application a une mauvaise boucle quelque part et doit prendre toutes les ressources disponibles, ainsi que le swap disponible.
Solution 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
Votre processus de candidature tente d'invoquer fallocate sur le système de fichiers shmem. D'après une recherche rapide sur Google, il semble que ZGC utilise fallocate pour récupérer la mémoire de tas initiale du système de fichiers shm et continue à utiliser fallocate pour étendre le tas. Une telle utilisation de l'appel système fallocate est plutôt inhabituelle, donc soit il s'agit d'un bogue ZGC (comme vous l'avez déjà suspecté), soit quelque chose d'autre perd beaucoup de mémoire, ce qui entraîne l'échec de l'expansion du tas.
Je vous suggère de configurer ZGC pour éviter des allocations d'exécution supplémentaires (définissez Xms et Xmx à la même valeur). Cela ne résoudra peut-être pas votre problème, si la fuite de mémoire se produit à cause de quelque chose sans rapport, mais au moins vous auriez une meilleure chance de trouver le vrai coupable.
Notez que votre configuration globale est quelque peu dangereuse - ZGC aime apparemment avoir beaucoup de mémoire contiguë, mais si vous avez un tas de 190 Go sur une machine de 240 Go de RAM, il se peut qu'il n'y ait pas une région contiguë suffisamment grande pour fallocate de. Dans ce cas, ZGC se rabattra sur la récupération de petites régions de mémoire avec davantage de fallocate appels (voir la description du rapport de bogue lié), et le problème sera à nouveau obscurci... Activer la prise en charge des pages énormes dans JVM (pages énormes normales , pas des énormes pages transparentes !) et préallouez des pages énormes lors du démarrage (avec l'argument du noyau) - l'utilisation de pages énormes est de toute façon conseillée pour vos tailles de tas.