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

Среда: Debian + Sun JDK 1.6.26

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

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

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

Добавлено через 9 минут и 29 секунд
attach

Присоединённый файл ( Кол-во скачиваний: 7 )
 jstack.txt 41,45 Kb

shainsky, 




Было у меня такое, когда на одном сервере висли потоки. Когда на других все работало без проблем.


Особо разбираться не стал - попросил переставить систему. Не помогло. Попросил заменить железо - вопрос решился.


Был как-то случай, когда приложение падало на одном сервере с непонятной ошибкой (давно на этом форуме даже постил лог, сейчас и не найти). Проблема была в бракованной планке памяти сервера.
Так что я бы начал с диагностики железа сервера. Посмотрел бы на его температурный режим. 



Забыли прикрепить?


п.с. как Ваше приложение грузит сервер?  Количество максимально разрешенных открытых файлов в системе достаточно для всех потоков? 

Это сообщение отредактировал(а) Vasay - 6.9.2012, 15:18

Сейчас вроде прикрепилось.

Независимо от состояния (зависло или нет) приложение отжирает 3 ядра из 16.

Доступные файлы не смотрел. А что - просветите неграмотного - для каждого потока ОС открывает временный файл?

Каждое socket соединение в *nix считается открытым файлом.

Обычно после установки linux ограничение стоит в 1024 открытых файла (а у Вас я там смотрю номера потоков за 10000)

В коде могут быть ошибки, которые не закрывают файлы/сокеты  и постепенно количество открытых файлов растет.

Для того что бы посмотреть и установить лимиты можно воспользоваться командой ulimit с разными параметрами.
 
 

Это сообщение отредактировал(а) Vasay - 6.9.2012, 16:36

и вообще любой ресурс, который берется из ограниченного пула, но не возвращается.  Или классический thread deadlock. Moe предположение - это ошибка программирования.

Есть профайлеры, умеющие снимать статистику удаленно, например JProfiler. Меня в похожей ситуации выручил именно он. 

О, за JProfiler спасибо. Он еще и по расписанию, оказывается, умеет.

Добавлено через 12 минут и 3 секунды

Проверил с помощью lsof, за 2 часа активной работы сокеты не "утекли".