Mois : octobre 2007

100% CPU explorer.exe sur Vista après une recherche dans le menu Démarrer

Avec mon Vista, j’avais un problème embêtant et difficile (pour moi) à supporter. De temps en temps j’avais la consommation de mon processeur à 100% sur le processus explorer.exe. Bizarre.

Quand je regardais sur le moniteur de ressources Vista (nouvel outil bien pratique accessible depuis le gestionnaire des tâches), je voyais que le processus explorer.exe qui utilisait 100% CPU, lisait des fichiers sur mon répertoire utilisateur (mon home directory), en particulier mes workspaces Eclipse (plein de petits fichiers java).

Au début, je me suis dit que c’était l’indexation des fichiers, et j’ai donc réduit le périmètre d’indexation pour notamment exclure mes workspaces Eclipse. Mais les 100% CPU continuait, même sur les fichiers exclus de l’indexation…

D’autant que même en utilisation sur batterie (j’ai un portable), j’avais le 100% CPU !

J’ai enfin trouvé la solution.

Continuer la lecture de 100% CPU explorer.exe sur Vista après une recherche dans le menu Démarrer

SAP Memory Analyzer : voilà un vrai outil pour analyser des Heap Dump Java !

Vous avez développé une application JEE, et depuis son passage en production au moins une fois par jour il y a une erreur Java « OutOfMemoryError ». La première réaction a été de dire : mauvaise configuration de la taille maximale de la JVM… vous avez préconisé 1Go de Max Heap Size, cela n’a pas fonctionné, l’erreur OOME arrive encore… Alors on est passé à 2Go… Toujours l’erreur d’OOME… Aie, et que faire…

Quand vous êtes à ce point, vous pouvez être certain que vous avez une fuite de mémoire (memory leaks) quelque part. Oh, ce n’est pas que vous êtes un mauvais développeur 😉 et que vous ne savez pas bien gerer la mémoire, en effet, parfois un problème de fuite de mémoire peut survenir à cause d’une fonctionnalité activée du serveur d’applications de production et qui rentre en « conflit » avec une brique de l’application. (Je citerai un exemple vécu : le cache (activé) JDBC de la source de données WebSphere 5.1 et un framework maison de mapping O/R)

Quand on a un problème d’OutOfMemory, on commence souvent par activer le mode verbeux du Garbage Collector (GC), c’est une très bonne idée, cela permet d’avoir une petite idée sur le déroulement du problème de mémoire (on peut utiliser l’outil Extensible Verbose Toolkit d’IBM pour ce travail, cf références). Cependant c’est insuffisant pour trouver la cause du problème. Quelques recherches sur Internet vous apprennent qu’il est possible d’avoir une image de la mémoire Java avec la génération d’un « heap dump », ensuite il suffit de l’analyser pour trouver la cause de la fuite de mémoire. Facile à écrire, mais dur à faire…

Continuer la lecture de SAP Memory Analyzer : voilà un vrai outil pour analyser des Heap Dump Java !

[Tutorial] Variabiliser un test de charges JMeter

Voici un nouveau tutorial sur JMeter. L’objectif de ce tutorial est montrer comment il est possible de variabliser les données saisies dans un formulaire HTML. C’est-à-dire de faire en sorte qu’à chaque exécution du scénario de tir de charges, les données saisies « changent ».

La variabilisation permet de faire par exemple des tirs de charges orientés « fonctionnels ». On peut ainsi imaginer un tir de charges qui serait plutôt l’exécution de cas de tests d’une application, permettant de vérifier que un traitement fonctionnel est correct. On peut même penser à des tests de non-régressions.

Pour découvrir ce tutorial sur la variabilisation, il faut voir cette page.

Bon courage dans vos aventures JMeter.