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

Как определить SQL, вызывающий скачки ЦП Oracle

У меня есть веб-приложение J2EE Spring / Hibernate, использующее Oracle 11g для постоянства, иногда при производстве загрузка ЦП Oracle достигает 100%, при перезапуске Tomcat ЦП Oracle падает. Я не могу воспроизвести это в тесте, даже используя экспорт из производства. Есть ли способ заставить Oracle показать мне оператор SQL, который вызывает всплеск? Или есть другой подход, который поможет мне выяснить, в чем проблема?

Дополнительная информация: Webapp и Oracle на разных ящиках (оба окна). Использование JDBC через SSL

Спасибо.

Вы можете включить отслеживание производительности в базе данных и отслеживать выполнение ваших запросов с помощью некоторых встроенных утилит.

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

http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/sqltrace.htm#sthref2019

Когда производство достигает 100% ЦП, вы (или ваш администратор базы данных) можете запустить команду «top», получить идентификатор процесса, который больше всего влияет на ЦП (при условии, что у вас их всего несколько), а затем использовать следующий запрос, чтобы поймать сеанс и чем он занимается в то время:

выберите p.SPID UnixProcess, s.SID, s.serial #, s.USERNAME, s.COMMAND, s.MACHINE, s.SQL_ADDRESS, s.SQL_HASH_VALUE, s.program, статус, cpu_time, выборки, disk_reads, buffer_gets, rows_processed , выполнение, child_latch, событие, sql_text, COMMAND_TYPE из gv $ session s левое внешнее соединение gv $ process p на p.ADDR = s.PADDR и s.inst_id = p.inst_id левое внешнее соединение gv $ sqlarea sa на sa.ADDRESS = s.SQL_ADDRESS и s.inst_id = sa.inst_id, где p.spid =

Вы действительно должны проверить, что в жизненном цикле ваших сервлетов вы правильно закрываете соединения с БД и что объекты, которые вы используете в своих сервлетах, правильно собираются мусором. иногда могут быть очень сложные утечки памяти на сервлетах, даже больше, если вы используете какую-то структуру DI.

У меня была утечка памяти на сервлете, который собирал мусор, но при выполнении некоторого RMI для другого приложения прокси-объекты не собирались, так что это съедало всю мою свободную память.

Ознакомьтесь с этой статьей с советами по тестированию производительности и проверке памяти на сервлетах.

http://www.ibm.com/developerworks/rational/library/2820.html