[Mono-dev] Size of thread in Mono (65MB per thread?)
Marek Habersack
grendel at twistedcode.net
Fri Dec 20 11:16:08 UTC 2013
On 12/20/2013 10:48 , Nicolas Antoniazzi wrote:
> Ok, I understand better the underline mechanism. I will try change my virtualization system with cgroups to simulate
> limitation of physical memory.
>
> But in the meantime, I am curious to know what is the need for a thread to reserve 64MB of virtual memory. I understand
> a need of 1 or 2MB for its stack plus few other kilos. But 64MB seems a lot to me :)
I don't think it's the thread itself that reserves the memory. Your test program stashed that much of data/code in RAM
and the figure is simply reported by each thread/LWP. As for the actual per-thread memory usage, you'd need to defer to
somebody who worked on their implementation in the Mono runtime (I didn't), but I would be surprised if it was a large
number.
marek
>
> Thanks a lot for your help!
>
>
>
> 2013/12/20 Marek Habersack <grendel at twistedcode.net <mailto:grendel at twistedcode.net>>
>
> 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> <mailto: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>
> <mailto: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>
> <mailto:Mono-devel-list at lists.__ximian.com <mailto:Mono-devel-list at lists.ximian.com>>
>
> http://lists.ximian.com/__mailman/listinfo/mono-devel-__list
> <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>
> <mailto:Mono-devel-list at lists.__ximian.com <mailto:Mono-devel-list at lists.ximian.com>>
>
> http://lists.ximian.com/__mailman/listinfo/mono-devel-__list
> <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
> <http://lists.ximian.com/mailman/listinfo/mono-devel-list>
>
>
>
More information about the Mono-devel-list
mailing list