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