Назад | Перейти на главную страницу

Запуск некоторых тестов с использованием ab, и tomcat начинает действительно тормозить

Я запускаю несколько тестов с использованием apache bench для Java-приложения, работающего на tomcat.

Скажем, я провожу такой тест:

ab -c 10 -n 10000 http://localhost:8080/hello/world

Он будет работать нормально. Если я последую за ним:

ab -c 50 -n 50000 http://localhost:8080/hello/world

Опять же, он будет работать нормально, но если я попробую еще раз, он начнет замедляться после примерно 3500 выполненных запросов.

Мне нужна помощь, чтобы попытаться отладить основную причину этого.

Я запустил топ, и у меня есть несколько гигабайт памяти, которые не используются, так что память, похоже, не проблема.

Процесс tomcat6 действительно идет на 70-80 или даже 107%.

Кажется, что перезапуск tomcat решает проблему, но иногда требуется перезагрузка сервера.

Это при установке Tomcat по умолчанию, которой выделено 200 потоков.

Журналы Tomcat пусты.

Обновить

Итак, я изменил tcp_tw_recycle / reuse на 1, и запуск netstat показывает очень низкий счет.

Перед изменением tcp_tw_recycle / reuse я заметил, что все замедляется, и запустил netstat, и у меня было 32400 tcp соединений TIME_WAIT.

Итак, обновление по запуску тестов сейчас, с переключателем -k я вижу НАМНОГО большую пропускную способность. НО, в какой-то момент все снова начинает замедляться, но перезапуск tomcat теперь возвращает все в норму. Раньше, даже если я перезапускал tomcat, время отклика при запуске ab было бы очень медленным. Теперь после изменения tcp_tw_recycle / reuse перезапуск tomcat вернет все в норму. В верхней части отображается tomcat только около 20% от процессора, поэтому кажется, что проблема сейчас в tomcat, но как я могу понять, что?

Здесь может происходить несколько вещей. Приведенная выше команда преобразует 50 одновременных подключений, каждое из которых отправляет 1000 запросов. Здесь следует отметить, что, если я правильно помню, apachebench не поддерживает сохранение активности по умолчанию. Возможно, стоит добавить это (передайте -k к вашей команде выше). В любом случае это будет скорее реальный тест, поскольку большинство пользовательских агентов используют keep-alive, как и Tomcat, по умолчанию. Это должно помочь решить проблему, если мои теории ниже верны.

1) Я подозреваю, что вы закрываете этот пул потоков слишком большим количеством запросов, поскольку каждый из них срывается. Это довольно большой удар для этих потоков, а также для стека TCP / IP в системе. Что приводит меня к ...

2) Возможно (да, возможно, у вас) заканчиваются эфемерные порты и / или вы используете сокеты TIME_WAIT. Если каждый запрос действительно является новым, уникальным запросом, вы, скорее всего, столкнетесь с ситуацией TIME_WAIT с тысячами сокетов в этом состоянии (посмотрите netstat -an | grep -ic TIME_WAIT, чтобы узнать их количество во время ваш груз). Эти сокеты не будут допущены к повторному использованию, если вы не включите time_wait_reuse в своей системе. Тот факт, что вы используете localhost, только усугубляет ситуацию.

Для получения дополнительной информации о настройке повторного использования time_wait см. Вот. Также обратите внимание, что этот поток правильно указывает, что установка тайм-аута fin_wait неверный в контексте time_wait, так что избегайте этого. Щекотать fin_wait в контексте TIME_WAIT неправильно и вам не поможет.

Так что посмотрите и, возможно, настройте tcp_tw_recycle / reuse специально. Они помогут вам пройти тесты, как и keep-alive.