MATLAB R2024a memory issues with Chromium Browser (JCEF) on Linux server

Hi everyone.

We have installed R2024a rev. 5 on our multi-user (+100 users) Linux server, which is a power machine equipped with the following:

RHEL 8.8 ootpa

kernel 4.18.0-477.27.1.el8_8.x86_64

40 cores Intel(R) Xeon(R) Gold 6248 CPU @ 2.50GHz

1.2TB RAM

Previous Matlab releases at startup only require ~10GB of RAM; on the other hand, the new R2024a release at startup creates a lot of processes (e.g., MATLABWebUI), each requiring more than 40GB of Virtual Memory per user.

Mathworks confirmed that this is a normal behavior in a Linux server having dozens of cores and hundreds of GB of RAM (despite the system requirements for Matlab, available on their public website, only state of 8GB minimum required RAM)

I have to say that each MATLABWebUI process requires more than 40GB of Virtual Memory, although only a few GB are actually allocated in the RSS physical memory. BUT anyway, in our multi-user server, we must have mandatory memory limits per user, and we cannot afford to allow Matlab users to have such high limits on ulimits -v (as reader knows, ulimit only takes into account the whole Virtual Memory, and not the RSS)

Mathworks confirmed that such memory requirements are tied to the Java-based Chromium Browser (JCEF) default behavior, that is a Matlab GUI component on these new releases, and that in multi-core and huge RAM machines requires at startup a huge Virtual Memory.

Finally, my question: does anyone know a way to reduce the virtual memory requirements for the Chromium component of the Matlab GUI in R2024 Linux releases ?

cgroups or containers are not a solution in our case.

Best.

Answer 1

[Kautuk Raj]

I understand you are looking to decrease the virtual memory usage of the Chromium components within the MATLAB GUI for the R2024a Linux versions.

According to a discussion on Stack Exchange at https://unix.stackexchange.com/questions/706243/why-google-chrome-is-reserving-terabytes-scale-virtual-memory, this level of virtual memory consumption is typical. The ‘MATLABWebUI’ process, which is a Java-based Chromium Browser (JCEF) process, handles the MATLAB UI and requires substantial virtual memory, leading to increased memory usage. These processes are essential for rendering the editor and other windows in MATLAB, such as the Add-On Explorer.

Consequently, reducing the virtual memory demands for these components isn't feasible. However, if graphical interfaces are not crucial for your work, you might consider launching MATLAB with the ‘-nodesktop’ flag.

[Andrea Luciani]

Thanks for reply Raj.

I do not think a software component that requires GB or TB of virtual memory is well designed, and a major company should evaluate such adoption with care. I understand we are talking about virtual memory and not resident memory.

But:

1 - in the Linux environment, for decades, admins have limited user memory using the ulimit command, which works by monitoring only the virtual memory (and not the resident memory rss)

2 - allowing Matlab to allocate 60GB of virtual memory implies that admins cannot deny users to allocate 60GB of rss in their data, and, in a multi-user server, this is a substantial risk for server memory saturation;

3 - I have never seen an open-source software component with no directives to limit its memory usage, and I would have adopted it with care.

Best.