StreamBase 7.x and Live Datamart 2.x Production JVM Settings
Article ID: KB0083302
Updated On:
| Products | Versions |
|---|---|
| TIBCO Streaming | 7.x |
Description
What are the recommended Production settings for StreamBase 7.x and Live Datamart 2.x to make troubleshooting easier?
Issue/Introduction
Recommended settings for Production servers.
Resolution
From StreamBase 7.6.0 and Live Datamart 2.1.0 (released November 2015), Oracle Java 8 is the preferred and included JDK for building and running streaming applications.
sbd.sbconf <java-vm> configuration settings:
Description:
Line 3: Maximum Heap memory to be used by the JVM. Xmx sets the maximum Heap. Xms sets the pre-allocated memory. We recommend these be set the same to keep the garbage collector from evaluating whether to request more memory from the OS. Examine Heap use and garbage collector behavior under production-level loads to determine an appropriate value to replace the '2g' (two gigabyte) value in this example.
Line 5: The G1 garbage collector is preferred for streaming applications.
Line 6: The 500 millisecond target works well for most StreamBase applications.
Line 7: One GC thread is sufficient for most applications. If you find the garbage collector is working continuously, instead of increasing this value, consider increasing the maximum Heap value and refactoring the application to produce less garbage (smaller schemas, fewer schema changes, state stored in query tables instead of carried in the tuple, ...).
Lines 9-13: These settings write garbage collection activity to its own log for standalone analysis.
Line 16: For Live Datamart on Linux systems, this adds general OS activity levels at 10-second intervals to the server console log.
Lines 17-18: For Live Datamart, this turns on the integrated 'sbprofile' process which logs to the lv-profile/ directory. The old profile logs are removed if they are older than 48 hours to keep from using excessive disk space.
sbd.sbconf <java-vm> configuration settings:
1: <java-vm> 2: <param name="jvm-args" value=" 3: -Xms2g -Xmx2g 4: 5: -XX:+UseG1GC 6: -XX:MaxGCPauseMillis=500 7: -XX:ConcGCThreads=1 8: 9: -verbose:gc 10: -Xloggc:gc.log 11: -XX:+PrintGCDetails 12: -XX:+PrintGCDateStamps 13: -XX:+PrintVMOptions 14: "/> 15: 16: <sysproperty name="liveview.lvmonitor.enable.os.cmd" value="true" /> 17: <sysproperty name="liveview.lvmonitor.enable.profiler" value="true"/> 18: <sysproperty name="liveview.lvmonitor.profile.oldest.hours" value="48"/> 19: 20: </java-vm>
Description:
Line 3: Maximum Heap memory to be used by the JVM. Xmx sets the maximum Heap. Xms sets the pre-allocated memory. We recommend these be set the same to keep the garbage collector from evaluating whether to request more memory from the OS. Examine Heap use and garbage collector behavior under production-level loads to determine an appropriate value to replace the '2g' (two gigabyte) value in this example.
Line 5: The G1 garbage collector is preferred for streaming applications.
Line 6: The 500 millisecond target works well for most StreamBase applications.
Line 7: One GC thread is sufficient for most applications. If you find the garbage collector is working continuously, instead of increasing this value, consider increasing the maximum Heap value and refactoring the application to produce less garbage (smaller schemas, fewer schema changes, state stored in query tables instead of carried in the tuple, ...).
Lines 9-13: These settings write garbage collection activity to its own log for standalone analysis.
Line 16: For Live Datamart on Linux systems, this adds general OS activity levels at 10-second intervals to the server console log.
Lines 17-18: For Live Datamart, this turns on the integrated 'sbprofile' process which logs to the lv-profile/ directory. The old profile logs are removed if they are older than 48 hours to keep from using excessive disk space.
Feedback
Yes
No
Powered by
