Utilisation élevée du processeur dans Eclipse en veille

Sur mon ordinateur multicœur, Eclipse utilise entre 100 et 250% de la puissance du processeur, même en cas d’inactivité sur une nouvelle installation simple et dans un espace de travail vide. En fait, cela devient lent et ne répond plus.

J’ai essayé de définir les parameters de mémoire comme suggéré ici: Eclipse utilise 100% de CPU de manière aléatoire . Cela n’a pas aidé. J’ai également essayé différentes versions de Java, à savoir OpenJDK et Oracle Java 7, et les versions Eclipse Juno et Indigo. Je suis sur Ubuntu 12.04 LTS.

Comme un autre problème peut-être sans rapport lorsque je ferme Eclipse, le processus Java rest toujours ouvert avec plus de 200% d’utilisation du processeur et doit être détruit manuellement.

J’ai eu le même problème aujourd’hui, et il s’est avéré être un thread d’indexation qui occupait le processeur. J’avais récemment ajouté un certain nombre de fichiers à un projet et je l’avais oublié. Je me rends compte qu’il est peu probable que quelqu’un d’autre ait ce problème, mais il pourrait être utile de poster comment je l’ai étudié.

J’utilise Ubuntu 12.10 avec STS basé sur éclipse Juno.

Lancez eclipse à partir de la ligne de commande et redirigez la sortie vers un fichier pour obtenir un vidage de thread
Permettez-lui de se contenter d’un peu, puis obtenez une liste de l’utilisation du processeur pour chaque thread: ps -mo ‘pid lwp stime time pcpu’ -C java. Voici un exemple du résultat qui a identifié mon thread affamé cpu:

PID LWP STIME TIME% CPU

6974 – 07:42 00:15:51 133

7067 07:42 00:09:49 86.1
Convertissez l’ID de thread (dans mon cas 7067) en hexadécimal 0x1b9b (par exemple dans la ligne de commande en utilisant: printf “0x% x \ n” 7067)
Effectuez un vidage de thread du processus java en utilisant kill -3: kill -3 6974. La sortie est enregistrée dans le fichier que vous avez redirigé stdout lorsque vous avez démarré eclipse
Ouvrez le fichier et recherchez l’ID hexadécimal du thread:

“Link Indexer Delayed Write-10” prio = 10 tid = 0x00007f66b801a800 nid = 0x1b9b exécutable [0x00007f66a9e46000]

java.lang.Thread.State: RUNNABLE

at com.ibm.etools.references.internal.bplustree.db.ExtentManager $ WriteBack.r

J’ai eu ce problème avec les plugins, mais jamais avec Eclipse lui-même.

Vous pouvez essayer de le déboguer en allant dans Help > About Eclipse > Installation details et en désactivant les plug-ins un par un.

J’ai vu un tel comportement uniquement lorsque le ramasse-miettes est devenu fou parce que la mémoire allouée atteignait vraiment les limites de mémoire maximum configurées de la machine virtuelle. Si vous avez une grande installation Eclipse, votre première étape devrait toujours être d’ augmenter les parameters de mémoire dans le fichier eclipse.ini .

Veuillez également activer Window -> Preferences -> General -> Afficher l’état du tas . Il vous montrera combien de mémoire Eclipse utilise actuellement (dans la ligne d’état). Si cela monte au maximum autorisé et ne baisse plus (c.-à-d. Que le ramasse-miettes ne peut pas nettoyer les objects inutilisés), c’est exactement ce qui est indiqué ci-dessus.

Edit: Il serait également bon de savoir quel package Eclipse vous utilisez, car ceux-ci contiennent différents plugins par défaut. Classic, Modélisation, développeurs Java EE, …?

La désinstallation des plugins mylyn a résolu le problème pour moi et le gain de performance a été si drastique que je l’ai posté en réponse à une question de 6 ans.

Allez dans Help->About Eclipse->Installation Details->Installed Software et désinstallez tous les plug-ins que vous savez ne pas utiliser. Je n’ai désinstallé que les plugins mylyn et cela m’a fait merveille.

Le ramasse-miettes Java multi-thread est une erreur. Ajoutez l’option -XX: -UseLoopPredicate à la ligne de commande Java. Voir par exemple le bogue https://bugzilla.redhat.com/show_bug.cgi?id=882968

A été confronté au même problème, Passé à la suite de VM Argument dans éclipse et cela a bien fonctionné pour moi.

-Xmx1300m -XX: TailleSélection = 256m -XX: MaxPermSize = 256m