Calculating Weblogic Server Memory Usage
The Java process consumes more memory than simply the maximum heap size. Here we will see how to determine the expected native memory size based on the arguments we supply in the startup arguments of JVM.
Follow these steps to calculate the memory used by application:
1. We’ll set appropriate values for the weblogic administration server by modifying the stock startup scripts. Navigate to the domain’s home directory:
%MIDDLEWARE_HOME%/user_projects/domains/my_domain/
Replace my_domain with the relevant domain, as required.
2. Start the administration server by running the startWeblogic.cmd script.
3. Within the bin folder, open the setDomainEnv.cmd file. We’ll edit the file shortly, but first we’ll study the values we wish to set.
4. We’ll set the maximum and minimum Java heap sizes to the same value. This sets the heap memory size to a predefined static value so it cannot grow or shrink.
-Xms1024m –Xmx1024m
5. Add to the 1,024 MB heap a predefined Permanent Generation memory size, which we’ll set at 128 MB. Our total is now 1,152 MB.
-XX:PermSize=128m -XX:MaxPermSize=128m
6. Set the JIT code cache size to 16 MB using. This gives us a total of 1,168 MB.
-XX:ReservedCodeCacheSize=16m
7. Set the thread stack size to a known value. We’ll use 128 KB as a starting value. Weblogic makes heavy use of threads to service your business logic requests; as such we can’t just add this value to our running memory count
-Xss128k
8. In order to calculate the total amount of memory used by the threads in the JVM, we need to determine the number of threads in the WebLogic administration server process. We can do this using the jconsole application, which we’ll start on the same machine as the administration server (so that we do not have to set up any remote access policies). Within the %MIDDLEWARE_HOME%/your_hotspot_jdk_ version/bin directory, open jconsole.exe
When jconsole is running, attach it to the administration server by selecting the process from the list and clicking on Connect
Within jconsole, select the mbean tab, and then open the java.lang folder and the Threading package. Select Attributes’; you’ll see a ThreadCount attribute
We multiply this by our new Thread Stack Size value (128 KB) to give us a value of 5.504 MB. This gives us a running total of 1,173 MB.
9. Finally, make the changes to the file and run the program. Here are the complete changes we make in the setSoaSuiteDomainEnv.cmd file:
set JAVA_OPTIONS=%JAVA_OPTIONS% set DEFAULT_MEM_ARGS=-Xms1024m -Xmx1024m -Xss128k set PORT_MEM_ARGS=-Xms1024m -Xmx1024m -Xss128k @REM This section will only run on a non JRockit VM if "%JAVA_VENDOR%" == "Oracle" goto OracleJVM set DEFAULT_MEM_ARGS=%DEFAULT_MEM_ARGS% -XX:PermSize=128m -XX:MaxPermSize=128m -XX:ReservedCodeCacheSize=16m set PORT_MEM_ARGS=%PORT_MEM_ARGS% -XX:PermSize=128m -XX:MaxPermSize=128m -XX:ReservedCodeCacheSize=16m
Java processes use more memory than the object memory heap space alone. Internally, the memory layout is as shown in the following diagram:
Unfortunately, it can be hard to determine exactly how an operating system natively handles the memory of our Java process. However, there are options that we can use to control the JVM’s memory allocation.
The total native memory size of the Java process is calculated by adding together the following:
1. Maximum Object Heap Size (Xmx): The area of memory used for holding our Java objects.
2. The PermGen Memory Size (XX:MaxPermSize): The area of memory to hold Java class templates.
3. The Thread Stack Size (multiplied by the number of runtime threads) (XX:ThreadStackSize or Xss): This configures the maximum thread call stack depth.
4. The JIT Code Cache Size (XX:ReservedCodeCacheSize): This is the area of memory reserved for optimizations performed by the JVM in response to your code paths.
5. Native memory: The native memory from the JVM itself, plus any native libraries that are being used (look up JNI on the Internet).
We can now make a much closer approximation of the total memory size of our Java process. This will allow us to size our JVMs according to the available native memory on a physical or virtual host.
You can see from the above that our final native memory calculation is nearly 150 MB higher than the maximum heap space, which is not a small change if you’re trying to co-locate JVMs onto a host. You can monitor native memory using tools such as Process Explorer on Windows, the top command on Linux, or the ps and prstat commands on Solaris.
Viewing the memory used using JRMC for JRockit
JRockit Mission Control (JRMC) is a visualization and management tool for the JRockit JVM.
Perform the following steps to use JRockit to monitor your JVM memory:
1. Navigate to the domain’s home directory:
%MIDDLEWARE_HOME%/user_projects/domains/my_domain/
Replace my_domain with the relevant domain, as required.
2. Start the administration server by running the startWeblogic.cmd script.
3. Navigate to the JRockit JVM directory within the middleware home directory:
%MIDDLEWARE_HOME%/your_jrockit_jdk_version/
Replace your_jrockit_jdk_version with the relevant version number, as required.
4. Within the bin folder, you will see a number of programs and some native libraries. Open jrmc.exe on Windows; on Linux, this would simply be the jrmc executable file.
5. When booted for the first time, you may be presented with the welcome Start page.
Click on x in the tab to close this and we’ll see the local Java processes to which we have permission to attach JRMC; it will even note the different JVM types. We can see that here we have a WebLogic instance and the JRMC instance that we can load into JRMC, as well as our custom piece of code (which you can download from the book site) that simply loops around, allocating and releasing memory.
6. Load the WebLogic process (by right clicking and selecting Start Console). You’ll see the default dashboard with the default CPU dials and memory graphs:
7. More information is available for our dashboards. We can add a chart to the display by clicking on the Add Chart button:
This will add a blank dashboard as shown in the following screenshot:
8. We can now add metrics of interest that are available in the JVM. Click on the Add button and use Attribute selector to determine appropriate metrics. Here, we select metrics on garbage collections.
9. JRMC will then collect and graph the data for us.
10. The runtime view and Memory tab show us details on the memory consumption of the program as follows:
JRockit contains a bundled application called Mission Control, an application based on the Eclipse platform. This allows collation of instrumentation collected by JRockit at runtime by default. The upshot of this is that the only overhead on the JRockit JVM when using Mission Control is in the transmission of these metrics to the monitoring platform. JRockit leverages the Eclipse platform to allow the user to dynamically alter the view palettes to display the information of interest to your operation teams.
Viewing the memory used using VisualVM for HotSpot
The VisualVM application lets you view real-time JVM data such as memory and thread usage and garbage collection cycles.
Perform the following steps to view the memory used by Hotspot, using VisualVM:
1. Navigate to the domain’s home directory:
%MIDDLEWARE_HOME%/user_projects/domains/my_domain/
Replace my_domain with the relevant domain, as required.
2. Start the administration server by running the startWeblogic.cmd script.
3. Navigate to the Hotspot JVM directory within the middleware home directory:
%MIDDLEWARE_HOME%/your_hotspot_jdk_version/
Replace your_hotspot_jdk_version with the relevant version number, as required.
4. Navigate to the bin directory and open jvisualvm.exe. The following screenshot shows this for a Windows machine:
5. When booted for the first time, we’ll see the local Java processes to which we have permission to attach VisualVM. If you don’t see your process then ensure that you are running VisualVM as a user with privileges to access the WebLogic process. We can see in the following screenshot a WebLogic instance and the VisualVM instance to which we can connect VisualVM.
6. If you don’t see this view, click on the Applications button on the left gutter to display it.
7. We’ll install a plugin to visualize the GC cycles and memory usage. Go to Tools | Plugins. In Available Plugins, select Visual GC as shown in the following screenshot, and then click on Install:
8. After accepting the license agreement, restart VisualVM to enable the plugin.
9. Double-click on the test program or right-click on it and select Open.
10. Now you are able to move between tabs to view visual data on the JVM. Let’s look at the tab for our new plugin, the Visual GC tab.
11. On the left are presented the current memory size snapshots; on the right, GC’s timings are graphed on a timeline showing JVM area memory sizes.
VisualVM is a tool bundled with the JDK download package that lets you view detailed information on the internal mechanics of JVM. You can run heap dumps, thread stack listings or, as we did in this recipe, load in one of the many plugins and extrapolate the runtime data to interpret how your program is running on the existing JVM. This is a powerful tool for tuning your application as you can see how the memory is being managed in response to your application code and JVM tuning flags. For instance, the VisualGC plugin that we loaded graphed JVM young and tenured memory sizes going back in time. These were plotted alongside JVM Just In Time (JIT) compilation and GC timings; this is a good indicator of how frequently your garbage collector has to run.
JVM Statistics Monitoring Tool Daemon (jstatd) is a powerful mechanism for exposing Java processes. But bear in mind that there is no native authentication in this application. Firewall-access policies are recommended to supplement securing your machine.
In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.