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

Веб-приложение с Hibernate, Spring и Oracle загружает до 99% ЦП

У нас есть веб-приложение в среде Linux, в котором загрузка процессора иногда достигает 99%.

Иногда на это уходят дни, а иногда - минуты. Мы используем Hibernate с Spring в веб-приложении tomcat и базе данных Oracle.

При проверке журналов выясняется следующее:

«ConnectionManager - транзакция завершена в сеансе с режимом освобождения соединения on_close; обязательно закройте сеанс, чтобы освободить ресурсы JDBC!».

И затем количество сеансов начинает расти до 256 сеансов (максимум, разрешенный нашими конфетами Apache). Это строка, которая появляется, когда счетчик сеансов становится 256:

"ContainerBackgroundProcessor [StandardEngine [Catalina]] ManagerBase - Запуск истекающих сеансов StandardManager на 1259947978384 sessioncount 256"

После этого процессор получает 99%.

Какие-либо предложения? Все будут высоко оценены.

Заранее спасибо.

Скорее всего проблема в вашем приложении (у меня была такая же проблема с Jboss).

Может быть, эта проблема возникает, когда вы выполняете определенное действие в своем веб-приложении? Я бы попытался найти связь между приложением и проблемой. Может, вам поможет разработчик?

В большинстве случаев: Tomcat, oracle, фреймворки - не проблема. Проблема в приложении :-) (утечка памяти, соединение с базой данных не закрыто ...)

Удачи

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

  • контролировать систему, пока загрузка ЦП резко возрастает, с помощью top. Убедитесь, что процессор используется Java. (К сожалению, точнее нельзя сказать).

  • отслеживать использование размера кучи с помощью VisualVM или JConsole. Нормальное поведение - видеть, что размер кучи постепенно увеличивается, а затем внезапно уменьшается, когда срабатывает сборщик мусора (пилообразный рисунок). Если объем памяти остается высоким, сборку мусора невозможно

  • это может быть очевидно, но проверьте свои журналы на наличие OutOfMemoryExceptions

  • Убедитесь, что ваша виртуальная машина использует максимально возможный размер кучи. Для 32-битной JVM это 1400 или 1500M. Используйте параметр JVM -Xmx1500M.

  • Убедитесь, что ОС не использует много памяти подкачки (проверьте с помощью верхней или свободной). Убедитесь, что у него достаточно памяти для запуска Linux и Tomcat (3 или 4 ГБ - хорошее начало для 32-битной машины).

Еще одно замечание - проверьте свое приложение на предмет утечек памяти и соединений. Весна позаботится об этом за вас. Убедитесь, что вы не помещаете в объект HttpSession (или карту в Session) материал, которого там не должно быть. Если вы выполняете прямую обработку JDBC или файлов, убедитесь, что все потоки, соединения и PreparedStatements (это то, что я всегда забываю) закрыты.