KB#01205-Troubleshooting BBj crashing
Troubleshooting BBj crashing
The most common reason for BBj to crash is "OUT OF MEMORY" errors. Check the BBjServices.err logs for "OUT OF MEMORY" errors. The logs are located in the <bbj_install_dir>/log directory. These are text files that can be opened with any text editor. They can also be viewed in Enterprise Manager :
Sample BBjServices.err log with "OUT OF MEMORY" errors:
OUT OF MEMORY
Date: Mon May 18 14:27:27 CDT 2009
Not Responding: 0
Connected: 18/05/2009 02:27:02 PM
Current Line Listing:  READ RECORD(AR,KEY=ARGV(1),ERR=TERMINA)
java.lang.OutOfMemoryError: GC overhead limit exceeded
Mon May 18 14:27:32 CDT 2009
OUT OF MEMORY
If memory errors are found in the logs, immediately increase the -Xmx parameter for BBjServices in Enterprise Manager. Select the JVM tab. Select BBjServices in the drop down menu next to the Application box. Increase the -Xmx value in the Java Args box.
The default -Xmx setting for BBjServices prior to BBj 10.03* is -Xmx256m. The -Xmx parameter for java is the total top amount that Java is allowed. If more memory is required than this value allows, BBjServices will crash. Depending on the number of users and the specific application the default value may not be enough. Setting the value too low will cause BBjServices to crash. It is better to error on the side of too much memory. Keep increasing the -Xmx value until the "OUT OF MEMORY" errors no longer occur. The value can be adjusted down once the immediate problem of BBj Services crashing is resolved. It is not necessary to adjust the -Xms parameter when the -Xmx memory setting is increased.
See the following links for more information on tuning BBjServices memory settings.
Beginning with 1.6.0_18, Java includes a "zero setting" option which dynamically allocates memory to Java applications, based on the hardware profile of the client/server and the memory needs of the application. BASIS highly recommends taking advantage of this setting; versions of BBj 10.03 and higher are pre-configured to run this way. For further detail on how Java calculates the optimal -Xmx setting for various CPU/Memory profiles, see the excerpt below from Oracle's 1.6.0_18 Release Notes:
Garbage collection improvements
Updated Client JVM heap configuration
In the Client JVM, the default Java heap configuration has been modified to improve the performance of today's rich client applications. Initial and maximum heap sizes are larger and settings related to generational garbage collection are better tuned.
The default maximum heap size is half of the physical memory up to a physical memory size of 192 megabytes and otherwise one fourth of the physical memory up to a physical memory size of 1 gigabyte.
For example, if your machine has 128 megabytes of physical memory, then the maximum heap size is 64 megabytes, and greater than or equal to 1 gigabyte of physical memory results in a maximum heap size of 256 megabytes.
The maximum heap size is not actually used by the JVM unless your program creates enough objects to require it. A much smaller amount, termed the initial heap size, is allocated during JVM initialization. This amount is at least 8 megabytes and otherwise 1/64 of physical memory up to a physical memory size of 1 gigabyte.
The maximum amount of space allocated to the young generation is one third of the total heap size.
The updated heap configuration ergonomics apply to all collectors except Concurrent Mark-Sweep (CMS). CMS heap configuration ergonomics remain the same.
Server JVM heap configuration ergonomics are now the same as the Client, except that the default maximum heap size for 32-bit JVMs is 1 gigabyte, corresponding to a physical memory size of 4 gigabytes, and for 64-bit JVMs is 32 gigabytes, corresponding to a physical memory size of 128 gigabytes.
There are few situations when the automatic memory tuning may not be warranted and setting -Xmx parameter should be set manually. BBj provides this ability to manually set the JVM memory arguments in Enterprise Manager under the Server Information\ JVM tab. See http://documentation.basis.com/BASISHelp/WebHelp/b3odbc/enterprise_manager_-_server_information.htm for further information on this topic.
1. Running in BBj in a terminal server environment, Java assumes that physical memory on the system is for one virtual machine. In a terminal server scenario this is multiplied by the number of terminal server connections allowed with each allocation based off the total memory of the server. Allowing Java to allocate memory dynamically will quickly cause the server to run out of memory based on the algorithm outlined. Tune the -Xmx argument manually for the TCProxyServer jvm in this situation.
2. Over all physical memory on the system is low. There are some situations where physical memory may be small on the host hardware and using the dynamic allocation may be more than necessary to run the specific application resulting in taking valuable memory from the OS unnecessarily.
3. Using some non Oracle JVMs.
4. Large BBj installations that are seeing excessively long GC times. See http://documentation.basis.com/kb/kb01166.html for further information on tuning large systems.
Last Modified: 03/05/2012 Product: BBj Operating System: All platforms
BASIS structures five components of their technology into the BBx Generations