Tune for Java and Oracle

[Wim Rombauts]

We are mainly running java-based applications on our server, which have most of their data in an Oracle database, and both (java and oracle) run on the same system.
My systems ar of type rx6600 and rx2660, single, dual and triple CPU with 24 to 32GB RAM.
Not that anything specifically is running bad or slow, but I think there are admins out there with some tuning experience in this area, that could give me a few hints and tricks to let my systems run even better.
I just want to here from you what you did to make your systems look (or feel) faster, if any of you had the luck to find such a trick.

[Steven E. Protter · Accepted solution]

Shalom,

Take a look here.
http://h21007.www2.hp.com/portal/site/dspp/PAGE.template/page.document?ciid=6508a8ea6ce02110a8ea6ce02110275d6e10RCRD

SEP

[TwoProc]

Re: Java. I'm assuming you're running Java servlets. By watching glance, you'll see your java engine at times peak, then all is well for a while, then peak strongly (CPU), and then all is well again... This, from what I've seen is garbage collection, due to memory issues. Java doesn't truly dispose of object memory when object deconstruction is called, it tags it to be handled later when needed. So, make sure you've got large enough memory areas to minimize how often this occurs, if you're doing this constantly, then initialize your java engines with more ram at startup.

Re: Java again. Assuming Java Servlets once again. Your programmers can help with this. Java runs fastest on large memory objects if they are in memory and cached already. There is no "keep" tool to pin them - so make sure memory is large enough to keep them from being purged, and try to preallocated these objects before they are needed. If you've got down or slow times at night, try to invoke routines in batch mode at these periods that will use these objects and fully populate them before users start hitting them. This will greatly increase your "appearance" of speed. It's all about memory management to achieve healthy cache management.

Re: Oracle - wow - huuuuge subject.
A) Have enough memory to cache running code. Watch your objects in the shared pool for reload.
B) Have enough memory for your buffer cache. In general - even if your hit ratio is high, if your physical I/O is higher than what you're keeping up with, then you need a higher hit ratio - which means more memory for the buffer cache, or faster physical memory or both. Keep in mind that memory is by far cheaper.
C) Watch individual queries for needed tuning. Statspack is what you'd use for this. Another watchpoint, individual queries with high sorts on disk. Another watchpoint, active connections out there that have been a long time since they've communicated (they are waiting on the server to deliver their data) - these are ones that I focus on tuning along with those id'd in statspack reports.