Проблемы с пулками Glassfish

Мы используем Glassfish 3.0.1 и испытываем очень длительное время отклика; в течение 5 минут для 25% наших запросов POST/PUT, к тому времени, когда ответ вернется, фронтальный балансировщик нагрузки истечет.

Моя теория заключается в том, что запросы находятся в очереди и ждут доступного потока.

Я думаю, это связано с тем, что журналы доступа показывают, что запросы занимают несколько секунд, но время, в которое выполняются запросы, на пять минут позже, чем я ожидал.

Есть ли у кого-нибудь советы по отладке того, что происходит с пулами потоков? или какие оптимальные настройки должны быть для них?

Требуется ли периодически выполнять дамп потока или будет достаточным один дамп?

Ответ 1

На первый взгляд это, похоже, очень мало связано с самими потоковыми пулами. Не зная об остальной части вашей сети, вот некоторые вещи, которые я хотел бы проверить:

Есть ли мертвый/невосприимчивый node в пуле балансировки нагрузки? Это может привести к тому, что все запросы будут протестированы против этого node до тех пор, пока они не будут выполнены из-за таймаута, прежде чем перенаправляться на другой node.
Есть ли проблема с начальными соединениями между балансировщиком нагрузки и сервером Glassfish? Это может быть медленный или неправильный поиск DNS (хотя сервер должен кэшировать результаты), отсутствующий прокси или некоторые другие проблемы, связанные с сетью.
Вы проверили, синхронизированы ли часы между машинами? Это может привести к сбою синхронизации журналов. 5мин - довольно странный период ожидания.

Если все это становится пустым, вы можете просто иметь несоответствие импеданса между балансировщиком нагрузки и веб-сервером, и вам может потребоваться добавить веб-серверы для обработки нагрузки. Балансировщик нагрузки должен быть в состоянии дать вам много статистики о входящем трафике и о том, как он складывается.

Ответ 2

Обычно вы получаете это поведение, если на вашем сервере недостаточно рабочих потоков. Значения по умолчанию варьируются от 15 до 100 потоков в общих веб-серверах. Однако, если ваше приложение блокирует потоки рабочего сервера (например, ожидая запросов), значения по умолчанию слишком низки часто. Вы можете увеличить число рабочих до 1000 без проблем (заверить 64 бит). Также проверяйте количество рабочих потоков (иногда называемых "максимальными одновременными/открытыми запросами" ) любого промежуточного сервера (например, прокси или переадресации apache через mod_proxy).

Другая распространенная ошибка заключается в том, что ваше программное обеспечение отправляет запросы самому себе (например, пытается перенаправить или переслать запрос), блокируя входящий запрос.

Ответ 3

Взятие threaddump - лучший способ отладить то, что происходит с файловыми пулами. Пожалуйста, возьмите 3-4 резьбонаклада один за другим с интервалом в 1-2 секунды между каждым потоком.

Из threaddump вы можете найти количество рабочих потоков по их имени. Узнайте о длинных потоках из нескольких потоков.

Вы можете использовать инструмент TDA (http://java.net/projects/tda/downloads/download/tda-bin-2.2.zip) для анализа потоковых дампов.