Constat
Sur une architecture 64 bits une référence consomme 16 o dans une application Java (source). Ce qui est vraiment beaucoup !
C'est dû au fait que la JRE s'est orientée vers des architecture avec plusieurs To de RAM, et le marché s'est orienté à l'extrême opposé parce qu'un tel serveur se transformerait aussitôt en SPOF (Single Point Of Failure), sans même aborder la question du prix (rappel, c'est Oracle derrière qui tente de vendre ses infras).
Optimisation
- Si vous êtes sur une architecture 64 Bits
- Si votre HEAP est inférieur à 32 Go (i.e. -Xmx32g ou moins)
Alors vous devriez ajouter l'option -UseCompressedOops
à votre ligne de commande Java. Ainsi la taille des références passera de 16 o à 4 o.
Cadeau :P
Comprendre comment lire les informations de la commande free sous Linux.
Merci à Philou pour l'info.
Quand vous faites un HTOP, vous voyez souvent la consommation de NetBeans dépasser les 16Go de mémoire alors que votre système en a moins que ça. Cela est du à la GLIBC et sa manière de gérer la pagination avec les applications multi-thread.
En gros le calcul est le suivant :
Seuil mémoire de la JVM x taille d'un long sur votre architecture x nb coeurs...
- De base une JVM est à 64 Mo et en général 512 Mo pour NetBeans
- La taille d'un long sur un processeur 64 bits c'est 8 octets
- Le nombre de coeur, ici 8.
ME concernant la mémoire virtuel est donc à 512 Mo x 8 x 8 = 32768 Go... Voilà voilà.
Alors pour corriger le tire est améliorer A MORT ses perfs il faut ajouter dans votre fichier .profile :
export MALLOC_ARENA_MAX=4
N.B : où dans le script qui lance netbeans ça marche aussi si vous en avez un.
Cela va diviser la mémoire virtuel en général par 2 voir par 4. On dit merci qui ?
Trouver la quantité de mémoire vidéo allouée à votre carte grahique sous Linux.
Rhooo Chrome.... stellemenvrai
Comme choper les processus qui bouffent toutes vos ressources machine.