Échec de construction de Maven Out of Memory


88

À partir d'aujourd'hui, ma compilation maven échoue.

[INFO] [ERROR] Unexpected
[INFO] java.lang.OutOfMemoryError: Java heap space
[INFO]  at java.util.Arrays.copyOfRange(Arrays.java:2694)
[INFO]  at java.lang.String.<init>(String.java:203)
[INFO]  at java.lang.String.substring(String.java:1877)

[ERREUR] Mémoire insuffisante; pour augmenter la quantité de mémoire, utilisez l'indicateur -Xmx au démarrage (java -Xmx128M ...)

Depuis hier, j'avais exécuté avec succès une compilation maven.

À partir d'aujourd'hui, je viens de faire passer mon tas à 3 Go . De plus, je n'ai changé que 2-3 lignes de code mineures, donc je ne comprends pas cette erreur "mémoire insuffisante".

vagrant@dev:/vagrant/workspace$ echo $MAVEN_OPTS
-Xms1024m -Xmx3000m -Dmaven.surefire.debug=-Xmx3000m

EDIT: J'ai essayé le commentaire de l'affiche en modifiant le pom.xml de mon module défaillant. Mais j'ai eu la même erreur de construction maven.

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
            <source>1.5</source>
            <target>1.5</target>
            <fork>true</fork>
            <meminitial>1024m</meminitial>
            <maxmem>2024m</maxmem>
       </configuration>
    </plugin>

1
Pourriez-vous fournir plus de stacktrace? Je suis curieux de voir ce qui pourrait provoquer une initialisation de chaîne à court de mémoire. Définir la taille du tas dans MAVEN_OPTS semble être la voie à suivre, mais je suppose que quelque part il y a une chaîne ridiculement grande que vous n'allouez peut-être pas assez -Xmx.
Edward Samson

Réponses:


136

De quel type de module «Web» parlez-vous? Est-ce une guerre simple et une guerre de type d'emballage?

Si vous n'utilisez pas la boîte à outils Web de Google (GWT), vous n'avez pas besoin de fournir gwt.extraJvmArgs

Bifurquer le processus de compilation n'est peut-être pas la meilleure idée, car cela démarre un deuxième processus qui ignore MAVEN_OPTScomplètement, rendant ainsi l'analyse plus difficile.

J'essaierais donc d'augmenter le Xmx en définissant MAVEN_OPTS

export MAVEN_OPTS="-Xmx3000m"

Et ne branchez pas le compilateur à un processus différent

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <source>1.5</source>
        <target>1.5</target>
   </configuration>
</plugin>

L'augmentation -XX:MaxPermSize=512mne devrait pas être requise car si la taille de la perm est la raison du problème, alors je m'attendrais à l'erreurjava.lang.OutOfMemoryError: PermGen space

Si cela ne résout pas votre problème, vous pouvez créer des vidages de tas pour une analyse plus approfondie en ajoutant -XX:+HeapDumpOnOutOfMemoryError. De plus, vous pouvez utiliser jconsole.exe dans votre répertoire java bin pour vous connecter au jvm pendant que la compilation est en cours d'exécution et voir ce qui se passe dans le tas du jvm.

Une autre idée (peut-être stupide) qui m'est venue, avez-vous assez de RAM dans votre machine? Définir la taille de la mémoire est bien, mais si votre hôte ne dispose que de 4 Go et que vous pourriez avoir le problème que Java ne puisse pas utiliser la mémoire définie car elle est déjà utilisée par le système d'exploitation, Java, MS-Office ...


Merci pour votre réponse. Votre suggestion de supprimer la JVM fourchue s'applique-t-elle également au 'maven-surefire-plugin?' J'ai essayé votre suggestion de faire passer ma mémoire MAVEN_OPTS à 3000. Mon compilateur maven n'avait pas de paramètre pour une JVM fourchue, donc je n'avais pas besoin de changer quoi que ce soit. Et oui, ma VM invité a 4 Go de RAM. La machine hôte dispose de 8 Go de RAM.
Kevin Meredith

2
au fait, la compilation mvn a de nouveau échoué avec vos suggestions.
Kevin Meredith

1
Habituellement, j'essaie d'éviter de bifurquer le processus tant que je ne le fais pas fonctionner. Si votre système ne dispose que de 4 Go, ~ 1 Go est utilisé par le système d'exploitation. Vous disposez donc de 3 Go de repos. Si maven commence par Xms = 1 Go, le reste de la mémoire libre est de 2 Go. Ensuite, la fourche du compilateur a commencé avec Xms = 1 Go .... qui réduit la mémoire libre à 1 Go. Maintenant, vous pouvez soustraire la mémoire PermGen 128 Mo, le processus de plug-in de sécurité fourchue, ... Comme vous pouvez le voir, votre paramètre Xmx ne pourrait probablement jamais être utilisé par la JVM car la mémoire est simple et non libre. Avez-vous essayé d'utiliser JConsole? et HeapDumpOnOutOfMemoryError?
vach le

J'ai supprimé le Xms1024m de mon MAVEN_OPTS, mais la construction mvn a toujours échoué. J'ai ajouté le "HeapDump ..." à mon MAVEN_OPTS, mais je ne sais pas où le vidage est imprimé. Regard sur JConsole maintenant.
Kevin Meredith

Les décharges sont plces dans le répertoire
jvms

36

Répondre tard pour mentionner encore une autre option plutôt que la commune MAVEN_OPTS variable d'environnement pour passer au Maven construisez les options JVM requises.

Depuis Maven 3.3.1 , vous pourriez avoir un .mvndossier dans le cadre du projet concerné et un jvm.configfichier comme emplacement idéal pour une telle option.

deux nouveaux fichiers de configuration facultatifs .mvn/jvm.configet .mvn/maven.config, situés dans le répertoire de base de l'arborescence des sources du projet. S'ils sont présents, ces fichiers fourniront les options jvm et maven par défaut. Étant donné que ces fichiers font partie de l'arborescence source du projet, ils seront présents dans toutes les extractions de projet et seront automatiquement utilisés à chaque fois que le projet est généré.

Dans le cadre des notes de publication officielles

Dans Maven, il n'est pas simple de définir la configuration JVM sur une base par projet. Le mécanisme existant basé sur une variable d'environnement MAVEN_OPTSet l'utilisation de ${user.home}/.mavenrcest une autre option avec l'inconvénient de ne pas faire partie du projet.

À partir de cette version, vous pouvez définir la configuration JVM via un ${maven.projectBasedir}/.mvn/jvm.configfichier, ce qui signifie que vous pouvez définir les options de votre build sur une base par projet. Ce fichier fera partie de votre projet et sera archivé avec votre projet. Donc pas besoin de plus pour MAVEN_OPTS, les .mavenrcfichiers. Par exemple, si vous placez les options JVM suivantes dans le ${maven.projectBasedir}/.mvn/jvm.configfichier:

-Xmx2048m -Xms1024m -XX:MaxPermSize=512m -Djava.awt.headless=true

Le principal avantage de cette approche est que la configuration est isolée du projet concerné et appliquée à l'ensemble du build également, et moins fragile que MAVEN_OPTSpour les autres développeurs travaillant sur le même projet (en oubliant de le paramétrer).
De plus, les options seront appliquées à tous les modules dans le cas d'un projet multi-modules.


2
Notez que MaxPermSize est ignoré si vous utilisez JDK 8.
GeraldScott

14

J'ai eu le même problème en essayant de compiler une "installation propre" en utilisant un VPS de 512 Mo de RAM et un bon processeur. Exécutez OutOfMemory et tué le script à plusieurs reprises.

J'ai utilisé export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=350m"et travaillé.

Encore un autre échec de compilation parce que c'est la première fois que j'ai besoin de Maven, mais le problème d'OutOfMemory a disparu.


11

Ajouter une option

-XX:MaxPermSize=512m

à MAVEN_OPTS

maven-compiler-plugin options

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.5.1</version>
    <configuration>
      <fork>true</fork>
      <meminitial>1024m</meminitial>
      <maxmem>2024m</maxmem>
    </configuration>
  </plugin>

2
J'ai en fait ajouté l'option -XX: MaxPermSize = 1024m, après avoir publié ce post. Mais j'ai toujours une erreur de mémoire insuffisante. Un autre article de SO a mentionné que je devais ajouter une option à argLine de maven-surefire-plugin pour augmenter la mémoire utilisée par les threads fourchus. Je l'ai augmenté à <argLine> -Xms256m -Xmx1024m -XX: PermSize = 128m -XX: MaxPermSize = 512m </argLine>
Kevin Meredith

J'aurais dû le mentionner ... Non, la construction du maven a toujours échoué.
Kevin Meredith

Ajouter toutes ces propriétés maven-compilier-pluginet augmenter -XX:MaxPermSize, Xmxdevrait être =XX:MaxPermSize
Ilya

Utilisez également l'option <fork> true </true> dansmaven-compilier-plugin
Ilya

J'ai essayé cela (voir l'article original), mais ma compilation mvn a toujours échoué.
Kevin Meredith

4

J'ai eu le même problème lors de la compilation de Druid.io, l'augmentation de MaxDirectMemorySize a finalement fonctionné.

export MAVEN_OPTS="-Xms8g -Xmx8g -XX:MaxDirectMemorySize=4096m"

Curieux, MaxDirectMemorySize est ostensiblement illimité par défaut (c'est-à-dire que vous avez ajouté une limite, pas ajusté une limite préexistante).
Tomer Gabel

4

Cette configuration ci-dessous fonctionne dans mon cas

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>${maven-surefire-plugin.version}</version>
    <configuration>
        <verbose>true</verbose>
        <fork>true</fork>
        <argLine>-XX:MaxPermSize=500M</argLine>
    </configuration>
</plugin>

Essayez d'utiliser -XX: MaxPermSize au lieu de -XX: MaxPermGen



3

Sur quel type de système d'exploitation utilisez-vous?

Afin d'attribuer plus de 2 Go de RAM, il doit s'agir d'au moins un système d'exploitation 64 bits.

Ensuite, il y a un autre problème. Même si votre système d'exploitation a une RAM illimitée, mais qui est fragmentée de telle sorte qu'aucun bloc gratuit de 2 Go n'est disponible, vous obtiendrez également des exceptions de mémoire. Et gardez à l'esprit que la mémoire Heap normale n'est qu'une partie de la mémoire utilisée par le processus VM. Ainsi, sur une machine 32 bits, vous ne pourrez probablement jamais définir Xmx sur 2048 Mo.

Je suggérerais également de définir min une mémoire max à la même valeur, car dans ce cas, dès que la machine virtuelle est à court de mémoire, la première fois que 1 Go est alloué depuis le début, la machine virtuelle alloue alors un nouveau bloc (en supposant qu'il augmente avec 500 Mo de blocs) de 1,5 Go après l'allocation, il copierait tout le contenu du bloc un vers le nouveau et libérerait de la mémoire après cela. S'il manque à nouveau de mémoire, les 2 Go sont alloués et les 1,5 Go sont ensuite copiés, allouant temporairement 3,5 Go de mémoire.


1

Lors de la construction du projet sur la plate-forme Unix / Linux, définissez la syntaxe des options Maven comme ci-dessous. Notez que les signes de qoutation simples, pas les qoutations doubles.

export MAVEN_OPTS='-Xmx512m -XX:MaxPermSize=128m'

0

L'utilisation de .mvn / jvm.config a fonctionné pour moi et a l'avantage supplémentaire d'être lié au projet.


0

Cela se produit dans les grands projets sous Windows lorsque cygwin ou un autre émulateur Linux est utilisé (git bash). Par hasard, les deux ne fonctionnent pas sur mon projet, ce qui est un gros projet open source. Dans un script sh, quelques commandes mvn sont appelées. La taille de la mémoire augmente pour atteindre une taille de tas plus grande que celle spécifiée dans Xmx et la plupart du temps, dans un cas, le deuxième processus Windows est démarré. Cela rend la consommation de mémoire encore plus élevée.

La solution dans ce cas est d'utiliser un fichier de commandes et une taille Xmx réduite, puis les opérations maven sont réussies. S'il y a de l'intérêt, je peux révéler plus de détails.


0

Quelqu'un a déjà évoqué le problème du système d'exploitation 32 bits. Dans mon cas, le problème était que je compilais avec JDK 32 bits.


0

L'augmentation de la taille de la mémoire dans la variable d'environnement «MAVEN_OPTS» aidera à résoudre ce problème. Pour moi, passer de -Xmx756M à -Xmx1024M a fonctionné.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.