Мониторинг и настройка производительности Oracle Application Server (высокая загрузка ЦП)
Я только что нанял компанию, и мой начальник предложил мне решить проблему производительности как можно скорее. У меня раньше не было опыта работы с Java EE на стороне сервера.
Позвольте мне начать то, что я узнал о системе, но все еще не мог найти решения:
У нас есть сервер приложений Oracle (10.1.) и сервер Oracle Database (9.2.), разработчики программного обеспечения написали своего рода большой проект J2EE (проект X), в частности, используя JSF 1.2 с Ajax, который используется только в этом проекте. Они активно используют PL / SQL в своем коде.
Итак, мы запустили сервер приложений (машина Solaris), все вроде нормально. пользователи начинают использовать приложение, начиная с понедельника, из разных мест (у приложения 200 есть учетные записи пользователей, я только что проверил и вижу, что пул подключений настроен правильно, сеанс активен только 15 минут).
Через некоторое время (2 дня) загрузка ЦП станет высокой,% 60, ночью все то же самое ничего не изменилось (количество онлайн-пользователей сейчас примерно 1-2), даже он начинает использовать процессор, выделенный для других приложений на том же сервере, потому что они освободили Если мы не перезапустим сервер, загрузка через 2 дня станет% 90, приложение работает настолько медленно, что конечные пользователи начинают звонить.
Основная проблема заключается в том, что разработчики программного обеспечения говорят, что код ясен, а менеджеры системы и администраторы баз данных говорят, что у нас правильная конфигурация, другие приложения кажутся нормальными, почему эта проблема возникает только для приложения X.
Я начинаю копировать БД на тестовую платформу и обновляю ее до последней версии, то же самое сделал и с сервером приложений (Weblogic), если есть ошибка или нет. Я тестировал только одного пользователя и панель администратора weblogic, я могу отслеживать потоки и сбрасывать их. Я заметил, что некоторые темы отображаются как возиться. когда я проверял руководства и контролировал трассировку, я вижу, что он указывает мне номер строки, в которой вызывается код PL / SQL из файла .java. Программное обеспечение англ. говорит, что да, у нас действительно сложные коды PL / SQL, но какая связь с сервером приложений? это проблема сервера БД, я думаю, они правы ...
Я знаю, что в этом вопросе много пробелов, я хотел бы рассказать подробнее, но я ценю то, как вы меня ведете.
Заранее спасибо ...
Изменить: сервер как в ЦП, так и в памяти, достаточно для запуска более сложных приложений.
Тяжелые вызовы PL / SQL должны блокировать поток, поэтому загрузка ЦП должна упасть.
Мой первый порт обращения к медленному серверу приложений - это проверка журналов gc - поиск частых основных коллекций (которые указывают либо на утечку памяти, либо на то, что JVM просто требует больше памяти).
Системы, за которыми я ухаживаю, стали много более стабильная после перехода с толстых драйверов Oracle на облегченные драйверы jdbc - хотя проблемы в основном проявлялись в сбое контейнера.
Журналы должны быть хорошим индикатором любых проблем в системе, но многое зависит от того, что разработчики решат записать в них. Медленный SQL может привести к исчерпанию пула соединений - убедитесь, что пул регистрирует статистику соединений. Также убедитесь, что ulimit установлен правильно для JVM.
Поскольку вы используете 9i на уровне БД, у вас не будет функциональности AWR - вам придется запустить пакет статистики (но это уже должно быть стандартной практикой для управления производительностью вашего сайта), чтобы определить, что вызывает проблемы в БД.
Постепенное снижение производительности свидетельствует об утечке памяти в приложении - обычно это вызвано тем, что объекты не имеют ссылок на объекты и, следовательно, имеют право на сборку мусора - то есть проблема программирования. Это должно быть очевидно из большинства инструментов профилирования Java.
Я заметил, что некоторые темы отображаются как
Если вы не тестируете это на реальной нагрузке, результаты будут бесполезны.