Контроль Производительности Oracle Application Server и Настройка (загрузка ЦП высоко)

Heavy PL/SQL calls should block the thread - so the CPU usage should drop.

My first port of call for a slow application server is to check the gc logs - looking for frequent major collections (which indicate either a memory leak or that the JVM simply eeds more memory).

The systems I look after became a lot more stable after switching from the thick Oracle drivers to the lightweight jdbc drivers - although the issues had mainly manifested as the container crashing.

The logs should be a good indicator of any problems on the system - but a lot depends on what the developers choose to write in there. Slow SQL could result in the connection pool being exhausted - make sure that the pool is logging connection stats. Also make sure the ulimit is set correctly for the JVM.

Since you're running 9i at the DB tier you wont have the AWR functionality - you'll have to run the statspack (but this should already be standard practice for your sites performance management) to identify what's causing problems at the DB.

THe gradual degrading of performance is indicative of a memory leak in the application - usually this is caused by objects not being de-referenced and hence eligible for garbage collection - i.e. a programming issue. This should be apparent from most Java profiling tools.

ı noticed that there are some threads showing as a hogging

Unless you're testing this with a realistic workload the results are pretty much useless.