(édité, voir section ajoutée sur l'espace d'échange)
SHMMAX et SHMALL
Puisque vous utilisez CentOS, il se peut que vous ayez rencontré un problème similaire au sujet de l'interface de l'utilisateur. SHMMAX y SHMALL réglage du noyau comme décrit ici pour configurer la base de données Oracle . Sous ce même lien se trouve un exemple de calcul permettant d'obtenir et de définir les bons paramètres de l'indice de référence. SHMALL réglage.
Mémoire contiguë
Certains utilisateurs ont déjà signalé qu'il n'y avait pas assez de mémoire contiguë disponible, d'autres ont dit que ce n'était pas pertinent.
Je ne suis pas certain que la JVM de CentOS nécessite un bloc de mémoire contigu. Selon SAS En effet, la mémoire fragmentée peut empêcher votre JVM de démarrer avec une grande capacité de mémoire maximale. Xmx ou commencer Xms mais d'autres affirmations sur Internet disent que cela n'a pas d'importance. J'ai essayé de prouver ou d'infirmer cette affirmation sur ma station de travail Windows de 48 Go, mais j'ai réussi à démarrer la JVM avec un paramètre initial et maximal de 40 Go. Je suis pratiquement sûr qu'aucun bloc contigu de cette taille n'était disponible, mais les JVM sur différents systèmes d'exploitation peuvent se comporter différemment, car la gestion de la mémoire peut être différente d'un système d'exploitation à l'autre (par exemple, Windows cache généralement les adresses physiques des processus individuels).
Trouver le plus grand bloc de mémoire contigu
Utilice /proc/meminfo pour trouver le plus grand bloc de mémoire contigu disponible, voir la valeur sous VmAllocChunk . Voici un guide et une explication de toutes les valeurs. Si la valeur que vous voyez là est inférieure à 300 Go, essayez une valeur qui se situe juste en dessous de la valeur de VmAllocChunk .
Cependant, ce nombre est généralement plus élevé que la mémoire physiquement disponible (car il s'agit de la virtuel valeur de mémoire disponible), il peut vous donner un faux positif. C'est la valeur que vous pouvez réserver, mais une fois que vous commencez à l'utiliser, elle peut nécessiter un swapping. Vous devez donc également vérifier la valeur MemFree et le Inactive valeurs. À l'inverse, vous pouvez également examiner l'ensemble de la liste et voir quelles valeurs ne dépassent pas 300 Go.
Autres options de réglage que vous pouvez vérifier pour la JVM 64 bits
Je ne sais pas pourquoi vous semblez rencontrer un problème de limite de mémoire à 300 Go. Pendant un moment, j'ai pensé que vous aviez atteint un maximum de pages. Avec la valeur par défaut de 4kB, 300GB donne 78,643,200 pages. Cela ne ressemble pas à un nombre magique bien connu. Si, par exemple, 2^24 est le maximum, alors 16,777,216 pages, soit 64 Go, devrait être votre maximum théorique allouable.
Cependant, supposons, pour les besoins de l'argumentation, que vous ayez besoin de pages plus grandes (ce qui est, comme il s'avère, meilleur pour les performances des applications Java à grande mémoire), vous devriez consultez cette page de manuel sur JBoss qui explique comment utiliser -XX:+UseLargePages et mettre kernel.shmmax (c'est reparti), vm.nr_hugepages y vm.huge_tlb_shm_group (je ne suis pas sûr que cette dernière soit nécessaire).
Mettez votre système sous tension
D'autres l'ont déjà suggéré également. Pour vous assurer que le problème vient de la JVM et non du système d'exploitation, vous devriez effectuer un stresstest. Un outil que vous pouvez utiliser est Stresslinux . Dans ce tutoriel vous trouverez quelques options que vous pouvez utiliser. La commande suivante présente un intérêt particulier pour vous :
stress --vm 2 --vm-bytes 300G --timeout 30s --verbose
Si cette commande échoue ou bloque votre système, vous savez que le système d'exploitation limite l'utilisation de cette quantité de mémoire. Si elle réussit, nous devons essayer de modifier la JVM pour qu'elle puisse utiliser la mémoire disponible.
EDIT Avr6 : vérifier l'espace de swap
Il n'est pas rare que les systèmes dotés d'une mémoire interne très importante n'utilisent que peu ou pas d'espace d'échange. Pour de nombreuses applications, cela peut ne pas être un problème, mais la JVM exige que l'espace d'échange disponible soit plus grand que la taille de la mémoire demandée. D'après ce rapport de bogue la JVM essaiera d'augmenter elle-même l'espace d'échange, cependant, comme le montrent certaines réponses dans la rubrique ce fil de discussion SO a suggéré la JVM n'est pas toujours capable de le faire.
Par conséquent, vérifiez l'espace d'échange actuellement disponible avec cat /proc/swaps # free et, s'il est inférieur à 300 Go, suivez les instructions suivantes les instructions de cette page de manuel CentOS pour augmenter l'espace d'échange de votre système.
Note 1 : on peut déduire de rapport de bogue n° 4719001 qu'un contiguës d'espace swap disponible n'est pas une nécessité. Mais si vous n'êtes pas sûr, supprimer tout l'espace d'échange et le recréer ce qui devrait supprimer toute fragmentation.
Note 2 : J'ai vu plusieurs messages comme celui-ci reporting 0MB espace de permutation y être capable d'exécuter la JVM. Cela est probablement dû au fait que la JVM augmente elle-même l'espace d'échange. Vous pouvez toujours essayer d'augmenter l'espace d'échange à la main pour voir si cela résout votre problème.
Conclusion prématurée
Je réalise qu'aucune des réponses ci-dessus n'est une réponse toute faite à votre question. J'espère cependant vous donner quelques pistes pour essayer de faire fonctionner votre JVM. Vous pouvez également essayer d'autres JVM, si le problème s'avère être une limite de la JVM que vous utilisez actuellement, mais d'après ce que j'ai lu jusqu'à présent, aucune limite ne devrait être imposée pour les JVM 64 bits.
Le fait que vous obteniez l'erreur dès l'initialisation de la JVM m'incite à penser que le problème ne vient pas de la JVM, mais du fait que le système d'exploitation n'est pas en mesure de respecter la réservation des 300 Go de mémoire.
Mes propres tests ont montré que la JVM peut accéder à toute la mémoire virtuelle, et ne se soucie pas de la quantité de mémoire physique disponible. Il serait étrange que la mémoire virtuelle soit inférieure à la mémoire physique, mais la VmAllocChunk devrait vous donner un indice dans cette direction (il est généralement beaucoup plus grand).
