COO Service memory usage not equivalent to Cache Size Setting

First published: 12. December 2023 (cf, gs)

Summary

Every Fabasoft Folio COO-Service uses RAM for caching objects. The Maximum Cache Size (MB) can be adjusted in every COO Service object in the Domain Administration / Domain Objects / Services. Changing the Maximum Cache Size (MB) is applied directly without restart of the COO Services.

The Maximum Cache Size (MB) setting is not directly reflected by the memory usage of the process. The COO Service process may be bigger (or much bigger) in memory than configured in the cache setting.

This behaviour is by design of Fabasoft Folio COO Service memory management.

Information

The Fabasoft Folio COO-Service assigns memory to process the requested operations, and assigns memory for object cache. This memory is managed in memory pools held by the glibc memory routines.

This means, that if any request by a Fabasoft Folio Kernel needs much processing memory, this memory is allocated from the operating system, used and formally freed. But the glibc heap memory management keeps freed memory for re-use on demand. Therefore, currently unused memory is not returned to the operating system.

The required processing memory depends on request count, user count, maximum/used threads, result sizes/object counts on specific requests, also on implementation details like Get actions (needs to read objects to calculate values). In one sentence, it is dependent to the general load of the specific COO Service.

Solution

An unexpected high memory usage for a COO Services means that it has to process requests with high amount of temporary memory demand.

Reducing the Maximum Cache Size (MB) usually will not help, because more objects are dropped from the cache, but freed up into the “ready-for-re-use” pooled memory, not affecting the process memory.

We recommend to increase the physical memory / assigned VM memory of the backendserver to allow bigger process memory.

Also increasing the Maximum Cache Size (MB) for the specific COO Service can increase memory usage and performance, as cached objects will reduce processing memory.

To completely free the assigned memory of the COO Services, a restart of the services is required.

There are no “memory management” or “garbage collection” settings for glibc, therefore Fabasoft cannot control the size of “ready-to-re-use” pooled memory.

References

https://sourceware.org/glibc/wiki/MallocInternals#Free_Algorithm (glibc Wiki)