I SHOULD BE INCLUDING MANY THINGS OF MY RESEARCH RANDOMLY

HERE I SHALL ADD INFORMATION AND THAT IS IT
NO HEADINGS NO CATEGORIZATION NO ORGANIZATION JUST INFORMATION

I suggested increasing the min and max heap size (-Xms and -Xmx) because we don't know for sure if the heap is just to small at this point. If we find out that we don't need to have that much heap defined, we can always reduce it later. But for now, better to have to much allocated then not enough.

The -XX:PermSize and -XX:MaxPermSize params set the size of the Permanent Generation. The Permanent Generation is the section of memory used by the JVM to store reflective objects and other items (i.e. JSP class files for instance).
My own experience and that of a lot of testing at BEA has revealed that if the New Generation is sized to approximately 1/4 of the total heap, you tend to get good results for a wide variety of J2EE apps. The -XX:NewSize and -XX:MaxNewSize set the size of the New Generation of the heap. The New Generation is where all objects are allocated (with the exception of reflective/class objects). -Xint flag will force the JVM to run in interpreted mode (no code generation).
The -XX:SurvivorRatio is the ratio of the size of Eden to the size of the Survivor spaces. Our experience points to the fact that a survivor ratio of 4 tends to produce good GC related results.
The -XX:TargetSurvivorRatio is used to help control when objects are promoted from the New Generation to the Old Generation.



http://java.sun.com/javase/6/docs/technotes/tools/share/jhat.html

http://weblogs.java.net/blog/gsporar/archive/2007/05/tracking_down_m_1.html
http://weblogs.java.net/blog/gsporar/archive/2007/04/tracking_down_m.html

http://dev.eclipse.org/blogs/memoryanalyzer/2008/05/17/the-unknown-generation-perm/

http://www.alessandroribeiro.com/?q=en/node/33


The permanent generation (or: perm space) is a different beast: It is used to store class and method data as well as interned strings. Just like heap space, you can also run out of perm space. That’s what happens for example if you install too many plug-ins

Development vs. Production Mode Default Tuning Values

You can indicate whether a domain is to be used in a development environment or a production environment. WebLogic Server uses different default values for various services depending on the type of environment you specify.

The following table lists the performance-related configuration parameters that differ when switching from development to production startup mode.

Development and Production Startup Mode Tuning Defaults

Tuning Parameter	Development Mode Default	Production Mode Default
Execute Queue: ThreadCount	15 threads	25 threads
JDBC Connection Pool: MaxCapacity	15 connections	25 connections

The tuning defaults discussed in throughout WebLogic Performance and Tuning Guide refer to the "development mode" defaults, which is the default startup mode when WebLogic Server is installed. For information on switching the startup mode from development to production, see Changing the Runtime Mode in the Administration Console Online Help.

For a complete listing of the differences between development and production startup modes, see the "Differences Between Configuration Startup Modes" section in Creating WebLogic Configurations Using the Configuration Wizard.

If CPU utilization is consistently at or near 100 percent, increase the ratio of CPUs to servers by adding an additional CPU. Add additional CPUs until utilization reaches an acceptable level. Remember, always reserve some spare CPU cycles on your production systems to perform any administration tasks that may occur

Scenarios for Modifying the Default Thread Count

When...	Results	Do This:
Thread Count <>	Your thread count is too low if: § CPU is waiting to do work, but there is work that could be done. § Cannot get 100 percent CPU utilization rate.	Increase the thread count.
Thread Count = number of CPUs	Theoretically ideal, but the CPUs are still under-utilized.	Increase the thread count.
Thread Count > number of CPUs (by a moderate number of threads)	Practically ideal, with a moderate amount of context switching and a high CPU utilization rate.	Tune the moderate number of threads and compare performance results.
Thread Count > number of CPUs (by a large number of threads)	Too much context switching, which can lead to significant performance degradation. Your performance may increase as you decrease the number of threads.	Reduce the number of threads so that it equals the number of CPUs, and then add only the number of "stuck" threads that you have determined. For example, if you have four processors, then four threads can be running concurrently with the number of stuck threads. So, you want the execute threads to be 4 + the number of stuck threads. To determine the amount of stuck threads, see Tuning the Execute Thread Detection Behavior. Note: This recommendation is highly application-dependent. For instance, the length of time the application might block threads can invalidate the formula.

Modifying the Default Thread Count

To modify the default execute queue thread count using the Administration Console:

1. Start the Administration Server if it is not already running.

2. Access the Administration Console for the domain.

3. Expand the Servers node in the left pane to display the servers configured in your domain.

4. Right-click the name of the server instance that contains the execute queue you want to configure, and then select View Execute Queues on the pop-up menu to display a table of execute queues that can be modified.

Note: You can only modify the default execute queue for the server or a user-defined execute queue.

5. In the Name column, click directly on the default execute queue name to display the Configuration tab for modifying execute queues.

6. Locate the Thread Count value and increase or decrease it, as appropriate.

7. Click Apply to save your changes.

8. Reboot the selected server to enable the new execute queue settings.

For more information please refer this URL.

http://e-docs.bea.com/wls/docs81/perform/WLSTuning.html