2010-11-11 11 views
7

J'ai besoin d'un moyen de déclencher un GC complet à partir d'un script de console Linux sur Ubuntu. Je sais que c'est une très mauvaise pratique, mais sans trop entrer dans les détails, cela permet à mon serveur de fonctionner. Cela ne dure qu'un ou deux jours alors que je répare le problème, je n'ai pas besoin de me réveiller effectuer une GC manuelle via jconsole ou jvisualvm.Comment déclencher le GC manuel à partir de la console Linux sans X11

Sinon, je dois faire un script de souris qui clique sur le bouton toutes les 3 ou 4 heures, ce qui est encore pire.

Aidez-nous s'il vous plaît.

Répondre

11

Si vous pouvez avoir votre application démarrer un serveur JMX (qui je crois est sous-entendu de votre utilisation de jconsole/jvisualvm), alors vous pouvez appeler l'opération de mémoire MBean gc par des utilitaires de ligne de commande. D'abord, vous aurez besoin d'un client JMX en ligne de commande. J'ai déjà utilisé this one dans le passé pour des invocations de ligne de commande simples et cela a bien fonctionné. (Edit: En fait, je l'ai utilisé juste maintenant pour tester la commande suivante, et il a appelé GC avec succès sur un processus Tomcat local)

Ensuite, vous devrez élaborer la commande pour déclencher le garbage collection. Je pense que cela devrait fonctionner (vous aurez bien sûr besoin de changer les hôtes/ports/lettres de créance, selon le cas):

java -jar cmdline-jmxclient-X.X.jar - localhost:8081 java.lang:type=Memory gc 

Enfin, vous pouvez programmer l'invocation de cette commande par cron ou équivalent.

Voila!

+2

Cela va fonctionner. C'est un peu effrayant que vous ayez besoin de faire cela, mais ça marchera. –

+0

+1 à ce commentaire, bien que d'après la question, j'ai l'impression que Ævar est déjà conscient de cela, et utilise cette technique comme solution provisoire. –

+0

Merci beaucoup, j'ai essayé et cela a fonctionné, permettra d'économiser la nuit, même si je suis très proche de la résolution du problème réel. Pour clarifier un peu le problème, j'ai étudié les paramètres du GC pendant un certain temps et j'ai beaucoup travaillé.Le problème n'est pas que la JVM manque de mémoire et que le serveur fonctionne correctement, mais qu'il fuit les sockets CLOSE_WAIT, qui ne sont nettoyées que pendant le GC complet. Ce qui est également très étrange, cela remplit les pools de connexion et les limites de descripteur de fichier, et se termine par la suspension du serveur. –

-2

Ce n'est pas une mauvaise pratique, c'est impossible - même si l'application Java est exécutée par la JVM. Il y a un appel de gc() disponible mais même un conseil à la JVM pour exécuter la récupération de place. À partir de la console, il n'y a normalement aucun moyen d'influencer la machine virtuelle Java pendant son exécution.

Certains ont posé cette question pour la plate-forme Windows, voir la question How to request JVM garbage collection (not from code) when run from Windows command-line

Vous pouvez vérifier les arguments JVM pour les tailles pile/tas (à la fois min et max). Il y a beaucoup de réglages que vous pouvez faire dans ce domaine mais ils sont surtout spécifiques à la JVM que vous utilisez.

JVM performance tuning for large applications

+0

Ceci est spécifique à la JVM. –

7

Si vous possédez oracle jvm 1.7, vous pouvez utiliser jcmd pour lister les PID jvm, puis jcmd <pid> GC.run pour GC.

jcmd <pid> help vous montrera quelles autres commandes sont disponibles.

3
jcmd <pid> GC.run 

Exemple:

jcmd 20350 GC.run