Discussion :

[sinoquet]

Bonsoir,

Je dispose d'une RAM de 2 Go.

Au début de son exécution, mon programme Java indique "total memory in the JVM 5 177 344 bytes". J'ai vérifié que le chargement d'un programme avec peu d'instructions fournit le même résultat (Runtime.getRuntime().totalMemory()).

Runtime.getRuntime().maxMemory() fournit : 66 650 112 bytes.


Au cours de l'exécution, je crée des objets Java jusqu'à ce que Runtime.getRuntime().freeMemory() indique 316 574 bytes disponibles.


Comment faire utiliser plus de RAM à un programme Java ?

Merci par avance de votre réponse.

Cordialement

[tchize_]

par défaut, la jvm est limitée à 64M. Pour utiliser plus, il faut passer le paramètre -Xmx à la jvm:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

java -Xmx1024m -jar monappli.jar

Utilisera maximum 1G

Attention que, quand java prend de la mémoire système pour sa jvm (exemple il est à 32M il a besoin de passer à 40M), celle-ci ne sera pas rendue tant que la JVM ne quittera pas. Si ton programme doit tourner longtemps, il faut faire gaffe à ne pas donner à la JVM plus que nécessaire.

[natha]

Attention que, quand java prend de la mémoire système pour sa jvm (exemple il est à 32M il a besoin de passer à 40M), celle-ci ne sera pas rendue tant que la JVM ne quittera pas. Si ton programme doit tourner longtemps, il faut faire gaffe à ne pas donner à la JVM plus que nécessaire.

Ce n'est pas tout à fait exact.
Par défaut java rend la mémoire sous un certain ratio de mémoire utilisée / mémoire allouée. Je crois que par défaut c'est 70%.

Pour qu'il libère plus souvent (genre 25% + 2 ou 3 petites choses) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

-XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=25 -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

Sinon allouer 1Go directement c'est un peu barbare. Prévoir 128Mo déjà pour commencer serait pas mal. Il faut penser à trouver les mauvaises gestions de mémoire dans le programme.

[tchize_]

Ce n'est pas tout à fait exact.
Par défaut java rend la mémoire sous un certain ratio de mémoire utilisée / mémoire allouée. Je crois que par défaut c'est 70%.

Pour qu'il libère plus souvent (genre 25% + 2 ou 3 petites choses) :

Faut pas confondre la gestion mémoire au niveau du système et la gestion de la mémoire au sein de la jvm. Les objets java sont alloué au sein de la mémoire de la jvm. La jvm stocke cette mémoire dans un segment continu de mémoire système. Bien des des objets peuvent être désalloué dans la jvm (garbage collecting), le segment mémoire lui ne peut pas être diminué, et pour cause, il se pourrait qu'un objet "actif" se trouve toujours tout au bout du segment. On ne peut donc pas le diminuer. Pour pouvoir diminuer ce segment, il faudrait que la jvm implémente une politique de défragmentation de sa mémoire. Autant que je sache les expérience de sun dans ce domaine sont assez catastrophique (performances fortement dégradées de la jvm)

Ce code te permettra de confirmer ce comportement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
package test;
import java.util.*;
import java.io.*;
public class Test {
 
 
    public static void main(String[] args) throws Exception{
        BufferedReader r = new BufferedReader(new InputStreamReader(System.in));
        Runtime.getRuntime().gc();
        System.out.println("Total memory: "+Runtime.getRuntime().totalMemory()+", free memory: "+Runtime.getRuntime().freeMemory()+", max memory: "+Runtime.getRuntime().maxMemory());
        System.out.println("Regardez la taille du process java. Puis tappez enter commencer l'allocation");
        r.readLine();
        System.out.println("Allocation de 700000 byte[] de 1k");
        List l = new ArrayList();
        for (int i=0; i< 700000; i++){
          if (i%10000==9999)
             System.out.print(".");
          l.add(new byte[1024]);
        }
        System.out.println();
        byte[] b = new byte[1024];
        System.out.println("Total memory: "+Runtime.getRuntime().totalMemory()+", free memory: "+Runtime.getRuntime().freeMemory()+", max memory: "+Runtime.getRuntime().maxMemory());
        System.out.println("Regardez la taille du process java. Puis tappez enter pour vider la heap");
        r.readLine();
        l = null;
        Runtime.getRuntime().gc();
        System.out.println("Total memory: "+Runtime.getRuntime().totalMemory()+", free memory: "+Runtime.getRuntime().freeMemory()+", max memory: "+Runtime.getRuntime().maxMemory());
        System.out.println("Heap Videe, regardez si la taille du process java à diminué? Tappez enter pour quitter");
        r.readLine();
    }
}

Chez moi, au différentes étapes, çà donne ceci:

delbd 9634 0.7 1.2 1195124 12580 pts/2 Sl+ 14:40 0:00 /usr/local/jdk1.6/bin/java -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=25 -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -Xmx1024m test.Test
delbd 9634 7.1 72.5 1195740 750812 pts/2 Sl+ 14:40 0:07 /usr/local/jdk1.6/bin/java -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=25 -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -Xmx1024m test.Test
delbd 9634 4.1 72.5 1195740 750808 pts/2 Sl+ 14:40 0:08 /usr/local/jdk1.6/bin/java -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=25 -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -Xmx1024m test.Test

Soit au départ 12M, après allocation d'un gros paquet de donnée +-750M, après libération de ce gros bloc, +- 750M. La seule chose qui a diminué, je crois, c'est la mémoire système utilisée pour l'allocation de mémoire dans la jvm (soit qqes M par rapport au 700M de donnée libérées référencées par la jvm).

Tu notera que le totalMemory() retourné par Runtime, ne diminue jamais.

[natha]

Je suis désolé de te contredire mais tu n'es pas tout à fait au clair avec le GC en Java et la gestion de la mémoire.

Voici mon output après une mini-modification de ton code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
$ java -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=25 -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -Xmx1024m Test
Total memory: 5177344, free memory: 5027936, max memory: 1065484288
Regardez la taille du process java. Puis tappez enter commencer l'allocation
 
Allocation de 700000 byte[] de 1k
......................................................................
Total memory: 777986048, free memory: 42797368, max memory: 1065484288
Regardez la taille du process java. Puis tappez enter pour vider la heap
 
Total memory: 5181440, free memory: 5036048, max memory: 1065484288
Heap Videe, regardez si la taille du process java à diminué? Tappez enter pour quitter

J'ai transformé le dernier appel au GC comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
        for (int i = 0; i < 20; i++) {
            Runtime.getRuntime().gc();
        }

Voilà, une bonne lecture pour toi : http://gfx.developpez.com/tutoriel/java/gc/

Je concluerais par : "Heureusement que la mémoire diminue pendant la vie du programme !!!"

[adiGuba]

+1 natha tu m'as devancé

L'appel à gc() ne force pas le GC à libérer la mémoire, mais demande simplement au GC de "faire ses affaires" un peu plus tôt que prévu...


En fait le GC ne libère pas immédiatement la mémoire au système, afin éventuellement la réutilisé sans avoir à la désallouer/réallouer : si ton application est amenée à utiliser beaucoup de mémoire il y a de forte chance que cela se reproduise assez rapidement.

Si tu logges la boucle indiqué par natha tu verras qu'il faut environ 4 cycles du GC pour revenir à l'état initial :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Total memory: 778412032, free memory: 777388720, max memory: 1065484288
Total memory: 701050880, free memory: 700118096, max memory: 1065484288
Total memory: 422428672, free memory: 421823272, max memory: 1065484288
Total memory: 5181440, free memory: 5054712, max memory: 1065484288

Cette libération tardive permet de grosse amélioration des performances dans des traitements itératifs.

Un exemple image une boucle de traitement qui utilise 200 Mo à chaque tours. Avec un GC "agressif" (qui libérerait la mémoire tout de suite) ou une gestion manuelle de la mémoire cela équivaut à allouer et libérer 200 Mo par itération.

Avec le GC de Java on a une seule allocation de 200 Mo et éventuellement une seule libération à la fin du traitement. Le reste étant des manipulations en mémoire bien moins couteuse qu'une vrai allocation mémoire


a++


PS : Avec Java 5.0 on peut utiliser les MemoryMXBean pour un suivi plus fin que les méthode de Runtime...

[tchize_]

Effectivement, la valeur de total Memory renvoyée par diminue, mais la mémoire occupé par le process au niveau système, en ce qui me concerne, ne change pas, elle reste à plus de 700M, et par expérience (des process java qui tournent des semaine), çà ne va jamais en diminuant....

J'a jouté la boucle, même avec 200GC, je reste au plafond en mémoire système occupé (utilisation de java 5 sous linux)

[natha]

Effectivement, la valeur de total Memory renvoyée par diminue, mais la mémoire occupé par le process au niveau système, en ce qui me concerne, ne change pas, elle reste à plus de 700M, et par expérience (des process java qui tournent des semaine), çà ne va jamais en diminuant....

J'a jouté la boucle, même avec 200GC, je reste au plafond en mémoire système occupé (utilisation de java 5 sous linux)

Pour ma part ça diminue mais pas forcément tout de suite car à ce stade c'est l'OS qui gère ainsi que mes paramètres du premier post.

Pour tester, lance 1x ton prog de test (version avec au moins 4 gc à la fin). Laisse ouvert, consulte la consommation mémoire dans ton gestionnaire système.
Lance une deuxième fois ton prog (sans fermer le précédent), et regarde l'évolution de la mémoire de chacun niveau OS.
Tu seras surpris

Sans les paramètres

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

-XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=25

effectivement il y a peu de chance que ça se libère aussi nettement durant l'utilisation d'un programme, mais depuis qu'on utilise ça, ça se libère (mais je le répète, c'est l'OS qui gère à ce stade, Java permet juste que ça soit libéré si on le demande).

[tchize_]

Yes! trouvé pourquoi çà foire!
C'est bien jolie ce rendu de mémoire, mais quoique je fasse, il ne rend *pas* (jamais si tant est que 30 minutes à 1 gc() par seconde peut être appelé toujours) la mémoire quand la jvm tourne en mode "server". Et curieusement, sur toutes mes machines, la jvm se met en mode serveur par défaut. Par comparaison, j'ajoute "-client" à la commande plus haut et hop, par margie, au bout de trois gc() je retombe à 10M.

Maitenant, question fondamentale, comment on force une jvm "server" à libérer sa heap? Par ce que pour le moment, en mode server à se stabilise à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
Total memory: 839122944, free memory: 838317616, max memory: 1034027008
Total memory: 839122944, free memory: 838317616, max memory: 1034027008
Total memory: 839122944, free memory: 838317616, max memory: 1034027008
Total memory: 839122944, free memory: 838317616, max memory: 1034027008