J'ai un problème avec mon environnement Java. Je suis en cours d'exécution Solr 1.3 (moteur de recherche) depuis plus d'un an maintenant et tout à coup, j'ai eu beaucoup de problèmes avec elle. Toute ma piscine de fil (250) a été bloquée au hasard une ou deux fois par jour. Je n'ai apporté aucune modification sur mon application SOLR ou mon serveur Tomcat.
Je couronne Tomcat 5.5.25 et Solr 1.3. J'ai un vidage de fil lorsque le système est totalement surchargé: p>
igot comme 240 thread comme celui-ci: p> Nous pouvons voir que ce fil est bloqué et en attente de: P> Le fil qui possédait réellement le est celui-ci: p> et c'est la dernière partie de mon Dump du thread: p> "ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon prio=10 tid=0x00007f6510349800 nid=0xbff waiting on condition [0x0000000041d8d000..0x0000000041d8dd20]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1548)
at java.lang.Thread.run(Thread.java:619)
"pool-1-thread-1" prio=10 tid=0x0000000000c26400 nid=0xbfe waiting on condition [0x000000004200e000..0x000000004200eca0]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00007f651b275510> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:946)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:906)
at java.lang.Thread.run(Thread.java:619)
"Low Memory Detector" daemon prio=10 tid=0x00007f6510004400 nid=0xbfa runnable [0x0000000000000000..0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"CompilerThread1" daemon prio=10 tid=0x00007f6510001000 nid=0xbf9 waiting on condition [0x0000000000000000..0x0000000040d5e340]
java.lang.Thread.State: RUNNABLE
"CompilerThread0" daemon prio=10 tid=0x00000000006bc400 nid=0xbf8 waiting on condition [0x0000000000000000..0x0000000040c5d2d0]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" daemon prio=10 tid=0x00000000006bb000 nid=0xbf7 runnable [0x0000000000000000..0x0000000040b5da30]
java.lang.Thread.State: RUNNABLE
"Finalizer" daemon prio=10 tid=0x0000000000690c00 nid=0xbf6 in Object.wait() [0x000000004065e000..0x000000004065ed20]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00007f651aa10258> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
- locked <0x00007f651aa10258> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=0x000000000068f400 nid=0xbf5 in Object.wait() [0x000000004055d000..0x000000004055dca0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00007f651aa10338> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x00007f651aa10338> (a java.lang.ref.Reference$Lock)
"main" prio=10 tid=0x0000000000622400 nid=0xbeb runnable [0x0000000000000000..0x00007fff69fcbba0]
java.lang.Thread.State: RUNNABLE
"VM Thread" prio=10 tid=0x000000000068a000 nid=0xbf4 runnable
"GC task thread#0 (ParallelGC)" prio=10 tid=0x000000000062cc00 nid=0xbec runnable
"GC task thread#1 (ParallelGC)" prio=10 tid=0x000000000062e000 nid=0xbed runnable
"GC task thread#2 (ParallelGC)" prio=10 tid=0x000000000062f400 nid=0xbee runnable
"GC task thread#3 (ParallelGC)" prio=10 tid=0x0000000000630400 nid=0xbef runnable
"GC task thread#4 (ParallelGC)" prio=10 tid=0x0000000000631800 nid=0xbf0 runnable
"GC task thread#5 (ParallelGC)" prio=10 tid=0x0000000000632c00 nid=0xbf1 runnable
"GC task thread#6 (ParallelGC)" prio=10 tid=0x0000000000634000 nid=0xbf2 runnable
"GC task thread#7 (ParallelGC)" prio=10 tid=0x0000000000635400 nid=0xbf3 runnable
"VM Periodic Task Thread" prio=10 tid=0x00007f6510006800 nid=0xbfb waiting on condition
JNI global references: 1201
6 Réponses :
Je n'ai jamais utilisé java.util.logging , donc je ne sais pas si ma suggestion est utile, mais sans rien:
Essayez d'utiliser une instance différente de java.util.logging.logger , donc tous les threads 240 seront bloqués sur le même moniteur
(Cela aidera si des instances différentes de enregistreur utilisent différentes instances de java.util.logging.consolehandler ).
Il semble que le fil qui possède "0x00007FE37E72B340" soit bloqué au niveau de l'IO. Peut-être un problème de disque (raid?)?
Pouvez-vous faire une vidage de thread 5 minutes plus tard, voir si le même thread est toujours bloqué?
Merci pour les conseils, je vais essayer de surveiller l'activité de thread lors de l'accident suivant en quelques heures;)
Tous vos discussions sont de la journalisation des choses. Ils ont tous besoin d'écrire sur le disque de temps en temps. Chaque fois que l'un de vos fils 240 frappe une ligne de journalisation, il y aura des problèmes d'accès au disque.
Il me perturbe que le fil ayant la serrure est dans l'état runnable.
Je pense que cela peut attendre que des ressources externes soient libérées (comme un accès disque par exemple)
Excellent-tu bas sur l'espace disque? Avez-vous récemment changé quelque chose dans votre système de stockage?
Je pense que c'est la bonne voie. Je regarderais des facteurs externes. De plus, si cela écrit pas à un fichier traditionnel, mais à un tuyau nommé Unix, assurez-vous que quelqu'un lit l'autre extrémité du tuyau à un rythme suffisant. Si le tampon remplit, vous bloquerez simplement.
L'espace disque va bien et nous n'avons rien changé sur le système. Nous avons essayé de changer le système sur un autre serveur et nous avons eu le même prob.
Je ne pense pas que ce soit un problème avec la sécurité du fil. Cela aurait brisé beaucoup plus tôt. 240 threads n'est pas un problème pour la JVM. 240 threads Modification d'un seul fichier pourrait être. Un correctif laid serait de réduire la quantité de messages enregistrés. Essayez de peaufiner la chose avec getlogernames (), getlogger () et setlevel () de télécharger-lnw.oracle.com/javase/1.4.2/docs/apl/java/util/... et télécharger-lnw.oracle.com/javase/1.4.2/docs/api / Java / Util / ...
rinçage après chaque enregistrement de journal sera coûteux si vous avez des grumes très verbeuses.
Un correctif de qualité serait de nettoyer la journalisation, probablement basée sur l'audit.
comme solution rapide, remplacez streamhandler.flush ou sortiestream.flush pour ne pas le faire immédiatement. Seulement affleurer une fois de temps en temps. Notez cependant que vous pouvez potentiellement perdre des données de journalisation immédiatement avant un crash si vous faites cela.
Si vous utilisez sous Windows et que l'application Java démarre une console, veillez à ne pas cliquer sur la case DOS. Marque de merde de la fenêtre et copie des blocs "Fonction" de sortie sur la consoleHandler. Donc, tout enregistreur essayant d'écrire à l'écran bloquera. L'écriture sur la console est effectuée dans un appel natif et le thread Java semble donc être dans un état d'exécution lorsqu'il est bloqué, il n'est qu'aucun moyen de nourrir ce statut bloqué à la demande (parce que vous êtes natif espace).
Si l'application est bloquée (vous avez cliqué sur la case DOS) Appuyez sur Echap pour continuer.
Selon votre journal, le problème concerne l'utilisation de Java.Util.logging.ConsoleHandler.
Essayez d'abord de désactiver le gestionnaire de la console en le supprimant de la liste des «gestionnaires» et «HandLers» dans '$ {tomcat_home} /conf/logging.properties'. Voir si le problème survient toujours.
Si cela aide, il est certainement un problème avec la sortie de la consoleHandler. Essayez de vérifier s'il existe des problèmes concernant le fichier «catalina.out». Ceci est le fichier sur lequel Tomcat redirige sa sortie de console.