Discussion :

[natha]

Bonjour à tous,

Nous travaillons dans ma boite avec un serveur de développement sur lequel tous les développeurs lancent Eclipse.
Nous rencontrons actuellement des lenteurs et il semblerait que ça date de la période où j'ai installé Eclipse 3.3

Nous avons peu de plugins :
- Subversive 1.1.7
- XMLBuddy 2.0.72
- CheckStyle 4.3.2
- Caps Toggle 1.0.2

La question : avez-vous constaté une utilisation mémoire plus élevée ou des ralentissement avec Eclipse 3.3 par opposition à Eclipse 3.2 ?

Merci,
Natha

[Baptiste Wicht]

Non, chez moi c'est assez équivalent à la version 3.2. Tu as combien d'occuppation mémoire pour une instance d'Eclipse ?

[natha]

En début de journée autour de 200, en fin de journée je frôle les 400Mo.
Mais je ne contrôle pas particulièrement donc je ne saurais pas dire si j'ai parfois 450... ou si mes collègues ont, en moyenne, plus qu'avant.

Je vais un peu monitorer ça ces prochains jours en espérant que ça ne soit pas ça parce que bon, Eclipse 3.3 apporte quand même pas mal de choses

[Baptiste Wicht]

Ah ouais, c'est quand même assez énorme. Le mien monte au plus haut à 250Mo lorsque je build un gros projet, mais en général, il me semble que je suis vers les 120-150 Mo...

En plus des plugins que tu as listés, tu as installé les packages Europa ? C'est à dire tout les projets qui sont accessibles depuis le site Europa.

[natha]

L'installation d'Eclipse est light... aucun package d'Europa.

Disons que nous travaillons avec 11 projets dont 5 gros projets de sources. C'est sûrement pas la meilleure façon de faire mais voilà, y a un historique et des raisons à ça.

Niveau volume ça fait un workspace d'environ 300 Mo (tout compris : images, fichiers java, class, properties...).
10871 fichiers .java au jour d'aujourd'hui.
On a également une compilation des .jrxml (jasper reports) intégré dans Eclipse.

[nolofinwe]

je ne sais pas si ca a un rapport mais plusieurs développeurs dans la boite ou je travaille m'ont dis que si tu travaille sous windows il faut pas hésiter a alloué plus de mémoire a eclipse (notamment pour le démarrage) parce que la derniere version a tendance a "crashé" assez facilement... j'ai pas encore pu le vérifié mais ca arrive vite si on utilise javajet et svn selon eux.

voila c'est tous ce que je sais mais c'est a vérifié.

[aperrin]

Bonjour à tous,

Nous avons également eu des problèmes de crash d'eclipse 3.3.1.1. Après investigation c'est liée à un problème de PermGen Out of Space.

Le problème à été résolu avec cette configuration d'eclispe.ini :
-showsplash
org.eclipse.platform
-vmargs
-Dsun.lang.ClassLoader.allowArraySyntax=true
-XX:MaxPermSize=256m
-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx512m


Mais avec cette configuration nous avons maintenant des problèmes de lenteur des machines (pc sous windows xp mis à jour).
De plus après un certains nombres de relance (stop start) de tomcat en mode debug avec le plugin wtp, le serveur tomcat ne redémarre plus en mode debug (il redémarre en mode normal mais très lentement) et nous sommes alors obligées de redemarrer le PC. En effet l'arret d'eclipse ne suffit pas.
J'ai de fort soupcon vis à vis du plugin wtp mais je n'ai pour l'instant aucune certitude.
Pour l'instant je teste cette nouvelle configuration du fichier eclispe.ini:
-showsplash
org.eclipse.platform
-vmargs
-Dsun.lang.ClassLoader.allowArraySyntax=true
-XX:MaxPermSize=256m
-XX:+CMSPermGenSweepingEnabled
-XX:+CMSClassUnloadingEnabled
-Dosgi.requiredJavaVersion=1.5
-Xms64m
-Xmx512m

Après plusieurs recherches j'ai trouvé ce poste qui explique le mécanisme de déploiement à chaud :
Les mécanismes de déploiement à chaud ou d'interception impliquent généralement la génération de classes (.class) par des bibliotheques telle asm, cglib. Tout ces nouveaux objets sont instanciés dans une zone spéciale de la JVM, la mémoire permanente, PermGen. Apres plusieurs utilisations, ces mécanisment peuvent provoquer un remplissage complet de cette zone et provoquer des erreurs du type PermGen Out of Space. Deux solutions:

* augmenter cette zone avec les parametres -XXermSize -XX:MaxPermSize, mais cela reste un pansement, tôt ou tard, la PermGen sera pleine
* permettre à la JVM d'effectuer des déchargements et du nettoyage de ces objets: -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

[djo.mos]

Bonjour.

* permettre à la JVM d'effectuer des déchargements et du nettoyage de ces objets: -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

ça, c'est zoli !
Je ne connaisais pas avant, et je ne suis pas tombé la dessus au cours de mes googlages intensifs lorsque j'ai eu ce problème.

Vivement que Sun entendra nos voix (et des autres victimes du PermGenSpace) et ôtera cette monstruosité de la JVM !
Car c'est bien une spécificité des JVMs de Sun !
En utilisant IcedTea sur linux par exemple, mystérieusement les plantages d'eclipse ont disparu.

[aperrin]

Chez nous le problème est résolu avec cette configuration du fichier eclispe.ini :

-showsplash
org.eclipse.platform
-vmargs
-Dsun.lang.ClassLoader.allowArraySyntax=true
-XX:MaxPermSize=256m
-XX:+CMSPermGenSweepingEnabled
-XX:+CMSClassUnloadingEnabled
-Dosgi.requiredJavaVersion=1.5
-Xms96m
-Xmx768m

[liquideshark]

Chez nous le problème est résolu avec cette configuration du fichier eclispe.ini :

-showsplash
org.eclipse.platform
-vmargs
-Dsun.lang.ClassLoader.allowArraySyntax=true
-XX:MaxPermSize=256m
-XX:+CMSPermGenSweepingEnabled
-XX:+CMSClassUnloadingEnabled
-Dosgi.requiredJavaVersion=1.5
-Xms96m
-Xmx768m

Salut

J'ai le probleme de PermGen Out of Space sur Tomcat, et mon serveur à 2GB de ram. Cependant je ne peux que mettre plus que -Xms64m, sinon le serveur ne démmare pas. J'aimerais savoir pourquoi sachant qu'il y a 2gb de ram. Une autre question::

Code :

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

permettre à la JVM d'effectuer des déchargements et du nettoyage de ces objets: -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

le déchargement de la mémoire se fait avec quel fréquence?

Merci