Мониторинг и настройка производительности сервера приложений Oracle (высокая загрузка процессора)
Мониторинг и настройка производительности сервера приложений Oracle (высокая загрузка процессора)
Я только что нанял компанию, и мой босс дал мне проблему производительности, чтобы решить как можно скорее. У меня нет опыта работы с Java EE на стороне сервера.
Позвольте мне начать то, что я узнал о системе и все еще не мог найти решение:
У нас есть сервер приложений Oracle (10.1.) И сервер базы данных Oracle (9.2.), Разработчики программного обеспечения написали своего рода большой проект J2EE (проект X), в котором специально используется JSF 1.2 с Ajax, который используется только в этом проекте. Они активно используют PL/SQL в своем коде.
Итак, мы запустили сервер приложений (компьютер Solaris), все кажется нормальным. пользователи начинают использовать приложение, начиная с понедельника, из разных мест (приложение 200 имеет учетные записи пользователей, я только что проверил и вижу, что пул соединений настроен правильно, сеанс активен только 15 минут).
Через некоторое время (2 дня) загрузка ЦП становится высокой,%60, ночью она все еще остается неизменной, ничего не меняется (количество активных пользователей в данный момент составляет почти 1 или 2), даже если он начинает использовать ЦП, выделенный для других приложений того же сервер, потому что они были освобождены. Если мы не перезапустим сервер, загрузка станет%90 по прошествии 2 дней, приложение работает так медленно, что конечные пользователи начинают звонить.
The main problem is software engineers say that code is clear, and the System and DBA managers say that we have the correct configuration,the other applications seems OK why this problem happens only for X application.
I start copying the DB to a test platform and upgrade it to the latest version, also did in same with the application server (Weblogic) if there is a bug or not. i only tested by myself only one user and weblogic admin panel i can track the threads and dump them. ı noticed that there are some threads showing as a hogging. when i checked the manuals and control the trace i see that it directs me the line number where PL/SQL code is called from a.java file. The software eng. says that yes we have really complex PL/SQL codes but what's the relation with Application server? this is the problem of DB server, i guess they're right...
I know the question has many holes, i'd like to give more in detail but i appreciate the way you guide me.
Заранее спасибо...
Edit: The server both in CPU and Memory enough to run more complex applications
1 ответ
Тяжелые вызовы PL/SQL должны блокировать поток - поэтому загрузка ЦП должна снизиться.
Мой первый порт для медленного сервера приложений - проверка журналов gc - поиск частых крупных коллекций (которые указывают либо на утечку памяти, либо на то, что JVM просто требует больше памяти).
Системы, за которыми я ухаживаю, стали намного стабильнее после перехода с толстых драйверов Oracle на облегченные драйверы jdbc - хотя проблемы в основном проявлялись как сбой контейнера.
Журналы должны быть хорошим индикатором любых проблем в системе, но многое зависит от того, что разработчики решат написать там. Медленный SQL может привести к исчерпанию пула соединений - убедитесь, что пул регистрирует статистику соединений. Также убедитесь, что ulimit установлен правильно для JVM.
Поскольку вы используете 9i на уровне БД, у вас не будет функции AWR - вам придется запустить statspack (но это уже должно быть стандартной практикой для управления производительностью ваших сайтов), чтобы определить, что вызывает проблемы на БД.
Постепенное снижение производительности указывает на утечку памяти в приложении - обычно это происходит из-за того, что на объекты не обращаются ссылки и, следовательно, они могут быть использованы для сборки мусора, то есть проблемы программирования. Это должно быть очевидно из большинства инструментов профилирования Java.
я заметил, что есть некоторые темы, показывающие как hogging
Если вы не тестируете это с реалистичной рабочей нагрузкой, результаты в значительной степени бесполезны.