38,789
edits
Java/fr: Difference between revisions
Updating to match new version of source page
(Updating to match new version of source page) |
(Updating to match new version of source page) |
||
| Line 34: | Line 34: | ||
== Pièges == | == Pièges == | ||
<div class="mw-translate-fuzzy"> | |||
===Mémoire === | ===Mémoire === | ||
Java utilise un mécanisme de désallocation automatique de la mémoire (''garbage collector'') pour identifier les variables qui ne s'appliquent pas et retourner la mémoire qui leur est associée au système d'exploitation; plusieurs programmes Java nécessitent tout de même beaucoup de mémoire pour bien fonctionner. Au lancement avec la commande <tt>java</tt>, la taille du tas Java (''heap size'') est initialement fixée à 1/64e avec un maximum de 1/4 de la mémoire physique. Ces proportions, et particulièrement la valeur maximale, peuvent s'avérer inadéquates et font en sorte qu'une part importante de la mémoire reste inutilisée. Pour éviter cette situation, spécifiez la quantité maximale de mémoire à utiliser avec la commande | Java utilise un mécanisme de désallocation automatique de la mémoire (''garbage collector'') pour identifier les variables qui ne s'appliquent pas et retourner la mémoire qui leur est associée au système d'exploitation; plusieurs programmes Java nécessitent tout de même beaucoup de mémoire pour bien fonctionner. Au lancement avec la commande <tt>java</tt>, la taille du tas Java (''heap size'') est initialement fixée à 1/64e avec un maximum de 1/4 de la mémoire physique. Ces proportions, et particulièrement la valeur maximale, peuvent s'avérer inadéquates et font en sorte qu'une part importante de la mémoire reste inutilisée. Pour éviter cette situation, spécifiez la quantité maximale de mémoire à utiliser avec la commande | ||
| Line 39: | Line 40: | ||
{{Commande|java -Xmx8192m -jar file.jar}} | {{Commande|java -Xmx8192m -jar file.jar}} | ||
Dans cet exemple, le maximum est de 8192Mo (8Go). Indiquez la taille initiale du tas avec l'argument <tt>Xms</tt> et voyez toutes les options en ligne de commande que la JVM exécutera avec l'indicateur <tt>-XX:+PrintCommandLineFlags</tt>. | Dans cet exemple, le maximum est de 8192Mo (8Go). Indiquez la taille initiale du tas avec l'argument <tt>Xms</tt> et voyez toutes les options en ligne de commande que la JVM exécutera avec l'indicateur <tt>-XX:+PrintCommandLineFlags</tt>. | ||
</div> | |||
When the Java VM starts, it sets two memory parameters according to the amount of physical rather than available memory as follows: | |||
* Initial heap size of 1/64 of physical memory | |||
* Maximum heap size of 1/4 of physical memory | |||
On a system with a lot of physical memory, the 1/4 can easily exceed default the memory limits imposed by a shell or by the scheduler, and Java will fail with messages like these | |||
Could not reserve enough space for object heap | |||
There is insufficient memory for the Java Runtime Environment to continue. | |||
The two run-time memory parameters, however, can be explicitly controlled on the command line by following either syntax below: | |||
java -Xms256m -Xmx4g -version | |||
or | |||
java -XX:InitialHeapSize=256m -XX:MaxHeapSize=4g -version | |||
You can see all the command line options the JVM is going to run with by specifying the following flag <code>-XX:+PrintCommandLineFlags</code>, like so: | |||
<pre> | |||
$ java -Xms256m -Xmx4g -XX:+PrintCommandLineFlags -version | |||
-XX:InitialHeapSize=268435456 -XX:MaxHeapSize=4294967296 -XX:ParallelGCThreads=4 -XX:+PrintCommandLineFlags -XX:+UseCompressedOops -XX:+UseParallelGC | |||
</pre> | |||
Vous pouvez utiliser la variable d'environnement <tt>_JAVA_OPTIONS</tt> pour configurer les options d'exécution plutôt que de les spécifier en ligne de commande. Ceci s'avère utile quand des appels multiples sont lancés ou qu'un programme est appelé par un autre programme Java. Voici un exemple : | Vous pouvez utiliser la variable d'environnement <tt>_JAVA_OPTIONS</tt> pour configurer les options d'exécution plutôt que de les spécifier en ligne de commande. Ceci s'avère utile quand des appels multiples sont lancés ou qu'un programme est appelé par un autre programme Java. Voici un exemple : | ||
| Line 48: | Line 69: | ||
N'oubliez pas que l'instance Java crée elle-même une réserve d'utilisation de la mémoire. Nous recommandons que la limite par tâche soit fixée à 1 ou 2Go de plus que la valeur de l'option <tt>-Xmx</tt>. | N'oubliez pas que l'instance Java crée elle-même une réserve d'utilisation de la mémoire. Nous recommandons que la limite par tâche soit fixée à 1 ou 2Go de plus que la valeur de l'option <tt>-Xmx</tt>. | ||
<div class="mw-translate-fuzzy"> | |||
===Garbage Collector (GC)=== | ===Garbage Collector (GC)=== | ||
Que la tâche soit ou non multifil, Java utilise par défaut le mécanisme de désallocation parallèle ''Garbage Collector'' avec autant de fils que le nombre de cœurs CPU dans le nœud. Chacun des fils du GC consomme une portion de la mémoire physique proportionnelle au total. Nous recommandons fortement de définir le même nombre de fils pour le GC que le nombre de cœurs CPU demandé à l'ordonnanceur lors de la soumission de votre script, par exemple <tt>-XX:ParallelGCThreads=12</tt>. Même si la tâche est parallèle, vous pouvez invoquer le GC série avec l'option <tt>-XX:+UseSerialGC</tt>. | Que la tâche soit ou non multifil, Java utilise par défaut le mécanisme de désallocation parallèle ''Garbage Collector'' avec autant de fils que le nombre de cœurs CPU dans le nœud. Chacun des fils du GC consomme une portion de la mémoire physique proportionnelle au total. Nous recommandons fortement de définir le même nombre de fils pour le GC que le nombre de cœurs CPU demandé à l'ordonnanceur lors de la soumission de votre script, par exemple <tt>-XX:ParallelGCThreads=12</tt>. Même si la tâche est parallèle, vous pouvez invoquer le GC série avec l'option <tt>-XX:+UseSerialGC</tt>. | ||
</div> | |||
By default, the Java VM uses a parallel garbage collector (GC) and sets a number of GC threads equal to the number of CPU cores on a given node, whether a Java job is threaded or not. Each GC thread consumes memory. Moreover, the amount of memory each GC thread consumes is proportional to the amount of physical memory. Therefore, we highly recommend matching the number of GC threads to the number of CPU cores you requested from the scheduler in your job submission script, like so <tt>-XX:ParallelGCThreads=12</tt> for example. You can also use the serial garbage collector by specifying the following option <tt>-XX:+UseSerialGC</tt>, whether your job is parallel or not. | |||
===Mot-clé <tt>volatile</tt> === | ===Mot-clé <tt>volatile</tt> === | ||