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
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
| Your thread count is too low if: § CPU is waiting to do work, but there is work that could be done. | ||
| 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:
- 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.
- In the Name column, click directly on the default execute queue name to display the Configuration tab for modifying execute queues.
For more information please refer this URL.
http://e-docs.bea.com/wls/docs81/perform/WLSTuning.html
