У нас есть несколько веб-сервисов, работающих через Tomcat, которые используют hibernate / mysql. Я подозреваю, что у некоторых из них неправильно настроены пулы соединений, так как через несколько часов у некоторых отдельных приложений заканчиваются соединения и они перестают отвечать. Мы вносили изменения в службу пула соединений (в данном случае C3P0), но нам по-прежнему необходимо оставить старые версии приложений на сервере для обратной совместимости.
В любом случае, я подозреваю, что эти приложения также ухудшают общую стабильность работы Tomcat. Примерно раз в неделю наш сервер полностью перестает отвечать и не может обслуживать даже статические страницы. После перезапуска службы все снова будет работать еще несколько дней. Просмотр журналов почти не обнаруживает неперехваченных исключений, поэтому я не уверен, что могло вызвать сбой tomcat. К сожалению, до того, как сервер перестает отвечать, в журналах ошибок не отображается ничего примечательного.
Мы также рассматриваем возможность перехода на JBoss, поскольку он более «корпоративный», но я не уверен, что он решит эти проблемы. Есть ли веские причины для переключения веб-платформ, или мне следует продолжить отладку в наших собственных веб-приложениях? Кроме того, может ли веб-приложение вызвать сбой сервера приложений, сделав что-то плохое?
Конфигурация сервера: Windows 2003 Server, Tomcat 6.0.18 + blazeDS 3.0, Hibernate 3.2.
Я не думаю, что у кого-то будет ответ к вашей проблеме, но только наводки и идеи. Вот некоторые:
тебе нужно роботы, которые будут проверять работоспособность каждой части вашего сервиса. (тестирование единственного подключения к вашей базе данных, получение статической веб-страницы, получение динамической веб-страницы ...). Таким образом, вы увидите, что ломается первым или увеличивается время отклика.
у тебя есть сервис мониторинга / статистики? Вам необходимо отслеживать «количество активных подключений к базе данных», «количество активных веб-сессий», «количество потоков tomcat», «доступную память», ЦП ...
Мой совет: процесса tomcat не осталось, потому что все они застряли в ожидании ресурса (может быть, соединения с базой данных, или они просто бесконечный цикл!). Инструменты, которые я перечислил ранее, определенно помогут вам понять, почему ваш сервер медленно умирает каждую неделю.
netstat на своем сервере и посмотрите количество подключений к серверу базы данных (и сравните его с размером пула и мощностью сервера базы данных).Просто хотел добавить, что довольно часто проблемы с блокировкой таблиц с таблицами MyISAM могут легко вызвать скопление соединений с БД и заставить приложение, ожидающее этих результатов, сидеть и сидеть.
Вы можете проверить список процессов MySQL, чтобы увидеть, много ли запросов находится в заблокированном состоянии.
# mysqladmin processlist
-- или --
mysql> show processlist;
Если проблема заключается в блокировке, вы захотите увидеть, возможно ли изменение механизма хранения в проблемных таблицах с MyISAM на InnoDB.
Если для обслуживания статических страниц не требуется доступа к базе данных, то маловероятно, что это проблема ресурсов базы данных как таковая. Может случиться так, что все объединенные потоки где-то застряли, например, в ожидании диска с базой данных или в тупике. Первое, что я сделаю, это сделаю снимок трассировки стека с помощью jstack. Вы можете дополнительно посмотреть на процесс с помощью visualvm или jconsole.
Если вы установите лямбда-зонд webapp (получите бета-версию 1.7), вы можете получить мониторинг на уровне потоков; наблюдение за этим сообщит вам, когда потоки застряли в ожидании базы данных, а также множество других полезных диагностических средств.
Он немного староват, но все еще отлично работает в последних выпусках tomcat.