This page discusses the settings that affect the amount of memory usable by StreamBase Studio and StreamBase Server. See also the related page, Garbage Collection Policy Settings.
The Java VM memory settings for StreamBase Studio and StreamBase Server are defined independently in different ways, as described in later sections of this page. The default settings are slightly different between Studio and Server. The settings in this table apply to 64-bit Server running on Windows and UNIX systems:
|Java VM Memory Setting||Default StreamBase Studio Settings||Default StreamBase Server Settings|
In most cases, you only need to be concerned with the JVM settings for StreamBase Server, discussed in the following sections. For editing very large applications in Studio, you might need to separately increase Studio's memory footprint, as described in JVM Memory for StreamBase Studio.
If you make an explicit setting for any of the JVM memory parameters for the Server from the table above, then all of the
StreamBase Server default settings are disabled and no longer apply. Thus, if you explicitly set, for example,
-Xmx4g, then the default settings for
-Xms no longer applies. The simplest solution is to always set both settings at the same time if you set any one of them.
You can make explicit JVM settings that override the defaults in several ways: in the server configuration file, at the command
-J options, with the
STREAMBASE_JVM_ARGS environment variable, or in custom startup scripts. This note applies to all the ways you might set the JVM memory settings.
Remember that StreamBase Studio running in one Java VM launches StreamBase Server in a separate JVM process with its own memory constraints. Increasing only Studio's memory settings does not help the server load a large application; in fact, it could hamper it.
In a sense, Studio and Server must compete for memory resources on memory-constrained systems. For this reason, only increase Studio's JVM memory settings by the minimum amount that supports acceptable response times for typechecking and editing large applications. For example, on an 8 GB 64-bit system used for editing a large StreamBase application, you might allocate up to 2 GB for Studio, and leave the rest for server launches.
Any memory allocated by native code in the Server startup process is allocated before the JVM starts. Thus, memory allocated by native code Server components is outside the JVM heap and competes for overall memory resources with both Studio and Server.
Native code memory allocations include any memory allocated by the native code portion of the sbd launcher, as well as memory allocated by native code operators and adapters, and by native code DLLs or
.so files called by operators or adapters. For example, the native code portion of the sbd launcher allocates some memory for use as a cache for disk-based Query Tables (if your license enables their use). If you increase the
disk-querytable-cache parameter of the <server> element of the server configuration file to a large value, the memory allocated is unavailable for use in the server's JVM
It bears repeating that Studio is designed for authoring, testing, and debugging of applications, but is not designed to host high performance runs of StreamBase Server or for benchmarking of server runs, as discussed in Studio Performance Note.
If you start StreamBase Server without a configuration file, it starts with the internal default settings shown in the table above. You can adjust JVM memory settings for StreamBase Server in the server configuration file. The overall XML syntax for configuration files is described in StreamBase Server Configuration File XML Reference, in the <java-vm> section.
When you generate a default StreamBase Server configuration file in Studio and you opt to include the default contents, or
when you generate a default configuration file with sbd –s, the new file contains the following suggested settings for the
<java-vm> <param name="jvm-args" value=" -XX:+UseG1GC -XX:MaxGCPauseMillis=500 "/> </java-vm>
The default GC settings are described in Garbage Collection Policy Settings.
Increase the memory available to the next launch of the server by adding entries for the
-X settings from the table above. For a medium sized application, use settings like the following:
For a large application, use settings like these:
In general, StreamBase users do not need to adjust the JVM memory settings for running Studio. When Studio runs or debugs an application on the same machine, it launches StreamBase Server as a separate Java process with its own memory settings.
When Studio launches an application, it honors the
<java-vm> settings in a server configuration file named
sbd.sbconf that is placed at the root of the application's project folder. (Studio does not use configuration files with other names,
or those placed in other folders.) Thus, Studio running with its default memory settings can launch a server process with
larger memory settings defined in
sbd.sbconf, as long as there is enough system memory (including virtual memory) to support the launch.
An exception exists for those editing very large StreamBase applications with hundreds of components and many sub-modules. In this case, typechecking time and system response time can improve with larger Studio memory settings.
Adjust Studio's JVM memory settings by setting the
STREAMBASE_STUDIO_VMARGS environment variable for the environment in which Studio starts, as described in STREAMBASE_STUDIO_VMARGS. For example, the following setting provides an increase the default values:
Verify that your machine has enough system memory to support simultaneous editing and launching of large applications. 64-bit Windows and Linux systems should have 4 GB to take advantage of large JVM settings, with more recommended.
Follow these rules when changing Studio JVM memory settings:
You can use the
STREAMBASE_STUDIO_VMARGSenvironment variable to set Java properties for Studio as well as its JVM memory settings, as described in STREAMBASE_STUDIO_VMARGS. Remember to always specify memory settings when you add a property setting to the variable. This may mean re-specifying the default settings.
-XX:MaxPermSizesetting is ignored by the JDK 8 provided with StreamBase.
-Xmxsetting incrementally, stopping to test the results. Try adding 512M at a time to the
-Xmxvalue, then run Studio to test its responsiveness:
and so on.
When running 64-bit Studio to edit large applications on a 64-bit system with 8 GB of installed RAM, consider the following settings:
You can configure StreamBase Studio to display its own Java heap memory usage. Run General page, and select the Show heap status check box. Thereafter, Studio shows current and maximum reserved heap memory usage on the far right of the status bar, in the lower right corner of the Studio window.→ , select the top-level
To diagnose and troubleshoot memory usage with StreamBase Server, consider adding these additional settings in the
jvm-args parameter. These settings cause additional information to be reported to the server console (or to the Console view in Studio)
unless specifically overridden.
To view information about the Java Just-In-Time (JIT) compiler (HotSpot), try adding:
If the JVM is using an excessive amount of memory, or spending too much time performing garbage collection, try adding this argument to get more specific information:
With this argument, the JVM periodically generates output telling you how large the Java heap size is and how much time is being spent in garbage collection. The garbage collection subsystem of Java 8 is much improved over earlier versions, so this setting is likely to be less necessary with StreamBase releases 7.6.0 and later, which bundle JDK 8.
If the generated code for StreamBase operator execution is not optimal, try adding
-Xprofto the set of JVM arguments. Run your application again, and then send the generated information to your TIBCO StreamBase representative.
You can also use the following tools provided by StreamBase or included as part of its Java installation to inspect memory usage. The tools are listed in order of application-level to Java object-level inspection.
Use StreamBase profiling to review operator and queue changes over time.
Use the Java JConsole utility to see the JVM-level memory use pattern, real-time objects, and threads.
Use the Java jmap utility to see what Java objects are on the heap at any point in time. You can also use the Eclipse plug-in MAT (Memory Analyzer Tool) to show the output of jmap in graphical form.
Use the Java jstack utility to see what Java threads are working at any point in time.