Performance Refactoring to Reduce Garbage Creation(Advantage in tomcat 5)

The first enhancement to look at is Tomcat 5.0's memory-profiling tools. Tomcat 5 has been carefully optimized so that it produces less object garbage for the Java VM's garbage collector to have to clean up.




A typical problem with busy Java servers is that the server software constantly instantiates new objects, and when they're not needed anymore (typically, when a request ends), the objects are not reused but instead thrown out as garbage. The garbage collector must then find and reap all such objects to reclaim the memory they occupy. This takes time and CPU cycles to do, and in the meantime the whole JVM may be paused so that the garbage collector can finish its work. This means the requests currently in process must simply wait until the garbage collector is done, which makes the whole server slow down a little. Usually, this isn't a big problem because the garbage collector is pretty efficient at collecting garbage objects. But in some cases there is so much garbage being produced that it can't keep up, and eventually the amount of free memory gets low because there is a backlog of garbage objects using lots of memory. Or sometimes a web app creates very large objects that take the garbage collector longer to finalize and destroy, so the amount of free memory is lost in large chunks but isn't being replenished quite as fast.



Tomcat 5.0 has had many garbage creation (read performance enhancement) changes since Tomcat 4.1. Tomcat 5.0's single most important garbage-creation refactoring was the new request URI mapper. After some optimization profiling, Tomcat 4.1's request pipeline was found to create excess garbage while mapping a Connector's requests to the proper Container. For Tomcat 5, a whole new mapper was implemented that generates little or no garbage (lots of object recycling is going on in there), and thus Tomcat 5.0's request pipeline performs noticeably better than that of Tomcat 4.1. This also lowers the overall memory usage compared to Tomcat 4.1, which helps to prevent OutOfMemoryExceptions in the web apps it runs, and helps Tomcat 5 to scale higher vertically (i.e. higher scalability on a single machine).

Restore The UBUNTU Panels

Run These Below Commands

gconftool-2 --shutdown
gconftool --recursive-unset /apps/panel  
rm -rf ~/.gconf/apps/panel
pkill gnome-panel 

Connection To Oracle Through Shell Script

Oracle environment variables; if not all then set at least the last two of the following:




export ORACLE_BASE=/path/to/oracle
export ORACLE_HOME=$ORACLE_BASE/product/11g
export ORACLE_TERM=xsun
export NLS_LANG=American_America.US7ASCII
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export ORACLE_PATH=$ORACLE_HOME/bin
export PATH=$ORACLE_HOME/bin:$PATH
Set the Path of Oracle SID


export ORACLE_SID=orcl (Optional).For More Information(http://www.orafaq.com/wiki/ORACLE_SID)



However, if you have a Service Name instead and your oracle instance runs off of a different port than the default, then use the following format for connecting.



sqlplus -s LOGIN/PASSSWD@SERVERNAME:ORA_PORT/SERVICE_NAME

sqlplus -s LOGIN/PASSSWD  (With out Service Name and with default port)

Ex:--



#!/bin/sh -e 


export ORACLE_BASE=/path/to/oracle
export ORACLE_HOME=$ORACLE_BASE/product/11g
export ORACLE_TERM=xsun
export NLS_LANG=American_America.US7ASCII
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export ORACLE_PATH=$ORACLE_HOME/bin
export PATH=$ORACLE_HOME/bin:$PATH


sqlplus -s LOGIN/PASSSWD@SERVERNAME:ORA_PORT/SERVICE_NAME << EOF > sqloutput

set pagesize 0;
select * from blah;
update blah;
commit;
exit;