Имеется серверное приложение, которое через сокеты слушает другие серверные приложения, а также своих клиентов.
Реализовано на стороннем фреймворке для гетерогенных систем (легковесный аналог Корбы).
Фреймворк использует ТредПул для обработки запросов, и ещё один ТредПул используется нами для реализации бизнес-логики.
Приложение работает на серваке с 16 ядрами, 4 гига отдано под кучу.
Где-то раз в неделю приложение наглухо виснет.
Треддамп получается снять только в forced-режиме (jstack -F), внутри него все потоки в состоянии BLOCKED.
После снятия тред-дампа в принудительном порядке приложение, как правило, "развисает".

Среда: Debian + Sun JDK 1.6.26

Были попытки воспроизвести баг на разработческих машинах (ОС и JDK те же), но даже в случае
ограничения размеров кучи и размеров ТредПула получали только тормоза или OutOfMemory,
при этом потоки не зависали.

В связи с этим 2 вопроса:
1. Глобальный - нет ли у коллективного разума подозрений, в чем может быть проблема?
2. Локальный - может ли кто-нибудь посоветовать профайлер, который бы с некоторой периодичностью делал текстовые отчеты
о состоянии памяти/потоков/GC? Графического интерфейса от продакшн-сервера я получить, увы, не могу, иначе юзал бы JVisualVM.

В аттаче - треддамп зависшего приложения.

Blazkowicz,

Логирование GC включили, но с тех пор пока что не было зависаний. :)

BlazkowiczСудя по вот этому, подозрение все же падает на stop-the-world-gc
Thread 4764: (state = BLOCKED)
- java.lang.AbstractStringBuilder.<init>(int) @bci=6, line=45 (Compiled frame)
- java.lang.StringBuilder.<init>() @bci=3, line=68 (Compiled frame)


У меня было такое же подозрение, тем более, что память где-то подтекает, и YoungGen медленно растет. Но на разработческой машине с кучей=8Мб (!) воспроизвести зависание мне не удалось, я просто получил OutOfMemory.

BlazkowiczА CPU отжирается при этом почти полностью?

3 ядра отжираются.