...
Try to keep the session data small. Specifically, do not use large maps or lists in the sessions. These will take up a lot of memory.
If memory issues are encountered, try decreasing the Max Cached Sessions . In order to find out if the cache size is overdimensionedover-dimensioned, you can study the memory of the Execution Context that is hosting the workflow in System Statistics. For information about System Statistics, see 6.16 System Statistics.
To avoid a large aggregation cache causing out-of-memory errors, the aggregation cache detects that the memory limit is reached. Once this is detected, sessions will be moved from the memory cache to the file system.
| Note | ||
|---|---|---|
| ||
This has a performance impact , since the agent will have to read these sessions from the file system if they are accessed again. The Aggregation agent will log information in the EC's log file if the memory limit has been reached and the size of the cache needs to be adjusted. |
You can also specify when updated aggregation sessions shall be moved from the cache to the file system by setting the Execution Context property mz.aggregation.storage.maxneedssync property in in the relevant <pico>.conf file. This property shall be set to a value lower than Max Cached Sessions. For performance reasons, this property should be given a reasonably high value, but consider the risk of a server restart. If this happens, the cached data might be lost.
| Tip | ||
|---|---|---|
| ||
To speed up the start of workflows that run locally (on the EC), set the Execution Context property By doing so, the aggregation cache will be kept in memory for up to 10 minutes after a workflow has stopped. This, in turn, enables another workflow, that runs within a 10-minute interval after the first workflow has stopped, and that is configured with the same profile, to use the very same allocated cache. Note that since the cache remains in memory for up to 10 minutes after a workflow stopped executing, other workflows using other profiles might create caches of their own during this time. The memory space of the respective aggregation caches will add up in the heap. If the EC at a certain point runs out of memory, performance deteriorates as the cache is cleared and, as a result, sessions have to be read from and written to disk. The profile session cache functionality is only enabled in batch workflows where the Aggregation profile is not set to read-only, and the storage is placed locally to the EC. |
Memory Handling in Real-Time
| Warning | ||
|---|---|---|
| ||
In real-time, when memory caching without any file storage, i e Storage Commit Interval is set to zero, make sure that you carefully scale the cache size to avoid losing a session due to cache over-runs. An over-run cache is recorded by the system event in the System Log. For further information, see 9.3.8 Aggregation Session Inspector. |
...
| Info | |||||||
|---|---|---|---|---|---|---|---|
| |||||||
|
| Scroll ignore | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||