In-memory Models Management

In-memory models management is about determining, how many models can be loaded in-memory and how long filter eventlogs and calculation result caches are kept in the memory, which balance between performance and memory consumption. Note that this article only concerns the in-memory models in QPR ProcessAnalyzer.

Memory usage behavior

QPR ProcessAnalyzer (as all .Net applications) use the garbage collection mechanism, which works automatically, i.e., when applications need more memory, the garbage collection releases unused memory. When models are loaded into memory, QPR ProcessAnalyzer (IIS worker process) memory consumption increases. When models are dropped, memory consumption doesn't decrease instantly, and this is because the memory allocated to QPR ProcessAnalyzer might not be released if there is sufficient memory in the server computer. When there is lack of memory, the reserved memory is freed if it's not actually used by QPR ProcessAnalyzer. When models are loaded into memory after dropping models, the memory consumption might not increase because the reserved memory (previously used by the dropped models) can be used by the newly loaded models.

When using a model, the memory consumption further increases because filter eventlogs are cached to the memory. If there is lack of memory, older filter eventlogs are dropped from the memory to get more space. This on the other hand decreases performance because if the filter eventlog is needed again, it needs to be recalculated.

Loaded models reserve the space in the memory and they are not dropped there automatically (only when explicitly dropped by a user). The rest of the space is available for other cached objects, and they may be dropped if memory is becoming full. The more there is memory available, the better the performance because models and calculation results are more often available in the memory cache (i.e., higher hit rate). QPR ProcessAnalyzer is thus flexible in terms of the memory usage, as it will use more memory if there is memory available, but it can also work with less memory (although with decreased performance).

If the QPR ProcessAnalyzer server doesn't have enough memory to store more objects, already stored filters, calculation results and datatables are dropped from the memory starting from the one having the longest time since the last usage. Thus, when there is a memory shortage, objects may be dropped earlier than their settings define. Filters, calculation results and datatables are dropped during the memory shortage, but model are never dropped automatically. This is because recalculating filters and calculation results is usually faster than loading models from the database. That is why, when trying to load more models than there is available memory in the server, an out of memory error situation may occur.

Memory usage monitoring

QPR ProcessAnalyzer memory usage can be monitored in following sources:

• Server Windows Task Manager shows how much memory is reserved to QPR ProcessAnalyzer (i.e., the IIS worker process, w3wp.exe).
• User Settings dialog in the QPR ProcessAnalyzer UI shows how much memory is used by QPR ProcessAnalyzer (click details and see QPR ProcessAnalyzer memory usage).

Based on the memory usage, it may be difficult to identify how much there is unused memory in the server because some of the memory may just be reserved to the w3wp.exe process but it's not currently in use by eventlogs. To see how much memory is actually in use, the administrator can run a manual garbage collection in the server. It can be done in the Expression Designer by running the following commands:

GarbageCollection();
Sleep(2000);
GarbageCollection();
Sleep(2000);
GarbageCollection();
Sleep(2000);
"Memory consumption: " + Round((UsedProcessMemory / 1024 / 1024), 0) + "MB"

These commands runs the garbage collection three times and after that shows the QPR ProcessAnalyzer memory usage (same as in the User Settings dialog).

Best practices for memory management

Follow these best practices for the QPR ProcessAnalyzer server memory configuration:

• Make sure that the total Estimated memory usage as displayed in the System Reports | Models is less than the amount of memory available for the QPR ProcessAnalyzer server. The Estimated memory usage takes into account the estimated memory consumption needed for simultaneous user sessions, cached filters, calculation results, working memory and other on-time required computing resources. The actual memory consumption for each model immediately after it has been loaded into the memory is lower than the Estimated memory usage. Please make sure there is enough memory available after the models have been loaded so that the simultaneous usage does not result in running out of memory.
• Disable extending memory into disk (the page file), because it will slow down the system remarkably. Instead, make sure that there is enough memory in the system for workloads for QPR ProcessAnalyzer. (more information: https://docs.microsoft.com/en-us/windows/client-management/introduction-page-file)
• Configure the Drop Unused Filters After setting available for models (in the Model properties dialog). The setting determines the duration after which unused filters are dropped from the memory. The Drop Unused Filters After setting is defined in format HH:mm:ss or d.HH:mm:ss, for example 01:00:00 (one hour), 00:30:00 (30 minutes) or 1.00:00:00 (24 hours). If this setting is not defined, the server level default setting is used. When any calculation is performed using a filter, the filter's last used time is updated. Note that the allowed value for this setting is greater than zero seconds.

Objects stored to memory

There are following types of in-memory objects that are managed by the QPR ProcessAnalyzer server:

Stored object	Contents	Unused objects dropped after	Time to recreate	Memory consumption
Models (model eventlogs)	Models contain the eventlog data (events, cases), and objects calculated from the (e.g., event types, variations and flows).	Models are never dropped automatically from the memory, even when there is a memory shortage in the server. To drop a model from memory, you need to drop the model in the Workspace. Note that if the server has been restarted, only models that have the automatic loading set are loaded into memory models directly after the restart.	Slow Models are loaded from the database requiring to transfer considerable amount of data, which takes much more time than e.g. calculating filters and analyses.	High
Filters (filter eventlogs)	Filters contain all filtered data in model, which includes similar structures than the models.	Primarily defined by the Drop Unused Filters After setting in the Model settings dialog. If this not set for a model, the server level DropUnusedFiltersAfter setting is used. If the server setting is not defined, a default value of 1 hour is used. When the is a memory shortage in the server, they may be dropped from the memory earlier to free memory.	Fast Filters are calculated from the model data that already exists in the memory. Practically, filters are subsets of models.	Medium
Calculation results	Results of the calculations made in dashboards.	Unused calculation results are kept 30 minutes in the memory. When the is a memory shortage in the server, they may be dropped from the memory earlier to free memory.	Fast Analysis results are calculated from filters, which already exist in memory.	Low
Datatables	Contents of datatables.	There is a fixed duration of 1 hour. When the is a memory shortage in the server, they may be dropped from the memory earlier to free memory.	Depends on how much there is data in the datatable.	Depends on how much there is data in the datatable.