Much larger memory consumption of OMC under Linux than under Windows

[Francesco Casella]

The memory allocated by OMC under Linux is much larger (typically a factor four) than under Windows.

As an example, get the ScalableTestLibrary and run the attached test script.

On Windows 7 64 bit (with omc still running in 32-bit emulation), the maximum memory allocation by omc is about 560 MB. On Linux Ubuntu 64 bit, it goes well beyond 2000 MB. Please note that this memory is real, not virtual or shared - if the RAM of the machine is smaller than that value, the OS starts swapping wildly onto disk.

We have experienced this behaviour extensively with larger models on a 64 GB server (you can also try out bigger models from the ScalableTestSuite library). In this latter case, the total memory allocation reported by htop is up to 40% larger than the one attributed to the omc process, possibly triggering massive disk swapping activity if the physical RAM boundaries are exceeded. What is quite weird is that, if the omc process is killed, this extra memory remains allocated, and is only very gradually reduced to zero. Who allocates and deallocates this extra memory and why is quite mysterious.

I am not sure how much of this is due to going from 32 to 64 bits, and how much it is OS specific. In any case, with larger model, this penalty is really unacceptable.

Please make sure that, at least optionally, the memory consumption under Linux matches the one under Windows.

[Francesco Casella]

Script to reproduce the problem

[Adrian Pop]

The memory consumption on a 64 bit system compared with a 32 bit one should be maximum two times.
Unfortunately on Linux the memory consumption is not easy to retrieve via "htop" or "top".
Also, a lot of memory is used for caching on Linux and is not clear how much memory a process is actually consuming.
The GC library that we use doesn't give back any memory to the OS on Linux (it does so on Windows) so basically the heap does not shrink even if the process is not using all that memory.
I'll investigate a bit more next week when I'm back in Stockholm.

[Francesco Casella]

Replying to adrpo:

The memory consumption on a 64 bit system compared with a 32 bit one should be maximum two times.

We'd have a factor two if all the data being stored were integers. I'm not sure how much of the memory used by omc is used for that purpose, I guess it's much less than 100%

Unfortunately on Linux the memory consumption is not easy to retrieve via "htop" or "top".
Also, a lot of memory is used for caching on Linux and is not clear how much memory a process is actually consuming.

I understand this, regarding the memory reported for each process. On the other hand, the overall memory consumption indicator shown by htop is definitely reliable, because as soon as that hits the total RAM of the workstation, massive disk swapping starts. The actual CPU usage of the omc process hovers around 2-5% from that moment onwards, which means that the access pattern is not confined to some well-defined sub-set of the virtual memory pool, but is spans it all, all the time. In our experiments, before omc is started, the overall memory consumption reported is a mere 300 MB, so when the 64 GB limit is hit, it means omc is actually using all of that memory.

The GC library that we use doesn't give back any memory to the OS on Linux (it does so on Windows) so basically the heap does not shrink even if the process is not using all that memory.

This might be a serious problem for larger systems. It might also be an issue for OMEdit, which runs omc in the background without ever stopping it. I never tried OMEdit under Linux, but if the memory footprint of omc keeps growing every time some model is compiled, that won't be nice.

I'll investigate a bit more next week when I'm back in Stockholm.

OK, thanks a lot!

[Martin Sjölund]

To see what overhead 32/64-bit has: use -d=gcProfiling and see how many bytes are allocated.

[Francesco Casella]

On Win/32, bytes_allocd_since_gc tops 726 MB, while on Linux/64 it tops 1573 MB.

On Win/32, allocd_bytes_before_gc gives lots of negative numbers, while on Linux/64 it grows steadily until 28 GB.

Hard to make any sense out of this :)

[Martin Sjölund]

bytes_allocd_since_gc + allocd_bytes_before_gc is what is interesting. Of course, the 32-bit version of OMC cannot represent these numbers :(

Perhaps they should have been returned as doubles on 32-bit platforms...

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

Memory usage has shrunk a lot in the last two years. I'm going to close this ticket, unless the problem shows up again seriously in some future tests.