[Mono-dev] Size of thread in Mono (65MB per thread?)

Fri Dec 20 09:27:50 UTC 2013

On 12/20/2013 09:10 , Nicolas Antoniazzi wrote:
> I am not using OpenVZ but a solution that we developed based on Linux kernel calls because we really need to bootstrap a
> virtual environment in less than 50ms.
> I tested the same program on a .Net platform and after 1000 threads created, the whole application used 48MB of RAM. It
> sounds really strange to me that a Thread, that in theory should be a light process, takes 65MB of virtual memory.
>
> In the meantime, I am not expert in differences between virtual and physical memory, but, does your answer mean that if
> mono would detects that my system only has 500MB of physical memory, it would reserve less amount of memory per thread?
Unix systems work based on a bit different principle than the Windows ones. Namely, as Nikita mentions in his other 
mail, the virtual memory is nearly free of any limits - your process reserves the right to use that much memory, but it 
doesn't actually use ("commit") it physically. The virtual memory reservation is merely a hint of what can be consumed 
by the program, should it need it. You can observe that by running the following command on Linux:

   ps axu|less

now look at the headers at the top of the display:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1203  0.0  0.1   3436  1140 ?        S    Nov30   0:00 upstart-udev-bridge --daemon
root      1209  0.0  0.1   9552  1416 ?        Ss   Nov30   0:00 /lib/systemd/systemd-udevd --daemon

The VSZ and RSZ columns represent, respectively, the virtual (reserved) and real (committed) memory - you always want to 
look at the latter for actual memory usage of a process. Now, in my opinion, any virtualization system that limits the 
virtual memory is inherently flawed (at least on Linux) and this is because of the RSS vs VSZ difference I explained 
above but also because of another detail. Namely, each thread, as you know, is not a separate process per se (even 
though it's got its own PID) but rather a compartment in your parent process which has its own stack, own CPU state etc 
but it *still* lives in the same memory space and share the memory allocation with the parent. So if you look at the 
thread's memory usage figures you will get exactly the same numbers as for the main process - but it does not mean the 
each thread is using that much memory. In fact, memory is not allocated to the thread but to the process only.

Therefore, if your virtualization software looks at each PID's virtual memory usage and imposes a limit on that figure, 
then certainly, you will get an OOM in no time - even though the physical memory usage will be actually much lower.

hope that helps a bit,

marek
>
> Maybe there is a way to send some parameters to mono or to change some content in /proc to simulate a smaller amount of
> physical memory?
>
> Thanks for your answer!
>
>
>
> 2013/12/20 Nikita Tsukanov <keks9n at gmail.com <mailto:keks9n at gmail.com>>
>
>     Don't use OpenVZ, it limits _virtual_ memory, not physical. Mono threads use a small amount of physical memory, but
>     might reserve high of virtual memory space. You'd rather try KVM/Xen virtualization.
>
>     Regards,
>     Nikita
>
>     2013/12/19 Nicolas Antoniazzi <nicolas.antoniazzi at gmail.com <mailto:nicolas.antoniazzi at gmail.com>>
>
>         Hi,
>
>         I am using Mono in a virtualized environment with 512MB of RAM.
>         I made a very simple program which starts 10 threads in a loop and apparently, every time that I start a new
>         thread, approximately 65MB of memory is used.
>
>         In my case, I can run 5 threads, but for the 6th, the program crashes (without any exception). 150MB are already
>         consumed without the use of any thread.
>
>         Is it a normal behavior?
>
>         P.S: Sorry I double posted this message on mono-list because I did not understood that third party programmers
>         also had to come on this devel list.
>
>         Thanks!
>         --
>         Nicolas Antoniazzi
>
>         _______________________________________________
>         Mono-devel-list mailing list
>         Mono-devel-list at lists.ximian.com <mailto:Mono-devel-list at lists.ximian.com>
>         http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>     _______________________________________________
>     Mono-devel-list mailing list
>     Mono-devel-list at lists.ximian.com <mailto:Mono-devel-list at lists.ximian.com>
>     http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>