App hängt sich auf futex_wait_queue_me() alle ein paar Minuten

Ich bin mit einem einfachen Skript in Groovy auf einer Ubuntu-11.10-Maschine, nimmt die Schlüssel/Wert-Paare und fügt Sie zu einem JDBM map in einer Schleife.
Alle ~3 Minuten das Skript hängt für ein paar Minuten, und dann erneut.
Wenn ich mir im Ressourcenmonitor sehe ich, dass es keine CPU-oder Speicher-Aktivität und der Prozess ist in futex_wait_queue_me().

Schlagen Sie bitte ein Mittel, um dies zu überwinden, auf einer Windows-Maschine durch die Art und Weise der Anwendung läuft ohne Hänger.

Könnte das ein OS-Problem sein? (fand viele ähnliche threads zu ähnlichen futex_wait_queue_me() Probleme in Ubuntu0

Dank

  • Kann Sie bieten eine full thread dump des wartenden threads z.B. mit jstack ? (Sie können entfernen Sie diejenigen, die nicht) ich vermute, Sie werden immer von einem niedrigeren Niveau-dump und zu sehen gibt es sleeping-threads an, die normalen. Diese sind in der Regel ignoriert. Können Sie das Programm ausführen, mit -verbosegc ?
  • Hallo Peter, vielen Dank für die schnelle Antwort, nur um sicher zu sein, dass ich Ihnen Folgen richtig du meinst hinzufügen "-verbosegc" der java-Befehl richtig? Wie die Versorgung der thread-dump, einen screenshot vom Ressourcenmonitor?
  • Fügen Sie -verbosegc auf der Kommandozeile java. Es ist möglich, wenn Sie über wenig Speicher für einen GC zu nehmen Minuten statt von einem Bruchteil einer Sekunde. Um einen stack dump, verwenden Sie jstack und ignorieren/löschen, alle schlafenden threads. Wenn Sie nicht wissen, was sleeping-threads Aussehen, werfen Sie einen stack dump, wenn das Programm verhält sich normal und zeigen nur die threads, die anders sind. Sobald Sie eingegrenzt werden ein oder zwei threads, die sind anders, Sie können den text posten Sie Ihre Frage als ein code-block.
  • OK, es zu tun, kann einige Zeit dauern. Übrigens ich weiß nicht, was GC ist, aber bezüglich Speicher bin ich mit 16GiB ram und nur 10.3% verwendet.
  • Die GC ist der garbage collector. Der Standardwert für die maximale Größe des heap ist 25% des Speichers also, wenn Ihr nicht mit 25% das Programm gar nicht über seine maximale Größe. Eine Ursache für unerklärliche langen Pausen in Java 6 versucht-lookup der IP-Adressen von Hostnamen falsch konfiguriert, die in DNS. Das sollte weniger ein problem in den neuesten updates. Ich nur erwähnen, falls Ihr Ihnen etwas bedeuten.
  • Peter du hattest Recht es war ein problem mit der GC, ich habe die heap-Größe für eine große Zahl (<16 GB) und es funktionierte. Ich würde eher einen Weg finden, um die Ausbreitung der GC-Aktivität über die Zeit, und versuchen das spielen mit den verschiedenen Parametern, aber es sieht zu Komplex. Danke trotzdem für Eure Hilfe
  • Die Lösung ist nicht so Komplex, verwerfen, weniger Objekte. Abhängig von der Anwendung, Sie können es reduzieren, um weniger als einmal pro Tag (auch monior Sammlungen)

InformationsquelleAutor user971956 | 2012-03-21
  1. 4

    Überprüfen Sie bitte die version des kernel. Ich lief in ein ähnliches problem (java-und anderen multithreaded-Anwendungen) auf Centos6 und ein Upgrade des Kernels auf version 2.6.32-504.16.2.el6.x86_64 das Problem gelöst.

    Siehe centos bug report: https://bugs.centos.org/view.php?id=8703 enthält diese Zeiger, um eine Erklärung für das problem:
    https://github.com/torvalds/linux/commit/76835b0ebf8a7fe85beb03c75121419a7dec52f0 [^]

    Mein stacktrace war:

    cat /proc/23199/stack
[<ffffffff810b226a>] futex_wait_queue_me+0xba/0xf0
[<ffffffff810b33a0>] futex_wait+0x1c0/0x310
[<ffffffff810b4c91>] do_futex+0x121/0xae0
[<ffffffff810b56cb>] sys_futex+0x7b/0x170
[<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
    • Dieser sollte gekennzeichnet sein als die eigentliche Antwort @user971956.
    • dies ist die eigentliche Antwort.
    InformationsquelleAutor John Damm Soerensen
  2. 0

    Für alle interessierten habe ich diese Parameter beim ausführen von java:

    -Xms16384M -Xmx16384M

    Finden Sie weitere GC-Optimierung-Tipps zur http://randomlyrr.blogspot.it/2012/03/java-tuning-in-nutshell-part-1.html

    InformationsquelleAutor user971956
Schreibe einen Kommentar