<div dir="ltr"><div>Ok, I understand better the underline mechanism. I will try change my virtualization system with cgroups to simulate limitation of physical memory.</div><div><br></div><div>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 :)</div>

<div><br></div><div>Thanks a lot for your help!</div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/20 Marek Habersack <span dir="ltr"><<a href="mailto:grendel@twistedcode.net" target="_blank">grendel@twistedcode.net</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 12/20/2013 09:10 , Nicolas Antoniazzi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am not using OpenVZ but a solution that we developed based on Linux kernel calls because we really need to bootstrap a<br>
virtual environment in less than 50ms.<br>
I tested the same program on a .Net platform and after 1000 threads created, the whole application used 48MB of RAM. It<br>
sounds really strange to me that a Thread, that in theory should be a light process, takes 65MB of virtual memory.<br>
<br>
In the meantime, I am not expert in differences between virtual and physical memory, but, does your answer mean that if<br>
mono would detects that my system only has 500MB of physical memory, it would reserve less amount of memory per thread?<br>
</blockquote></div>
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:<br>


<br>
  ps axu|less<br>
<br>
now look at the headers at the top of the display:<br>
<br>
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND<br>
root      1203  0.0  0.1   3436  1140 ?        S    Nov30   0:00 upstart-udev-bridge --daemon<br>
root      1209  0.0  0.1   9552  1416 ?        Ss   Nov30   0:00 /lib/systemd/systemd-udevd --daemon<br>
<br>
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.<br>


<br>
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.<br>


<br>
hope that helps a bit,<br>
<br>
marek<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
Maybe there is a way to send some parameters to mono or to change some content in /proc to simulate a smaller amount of<br>
physical memory?<br>
<br>
Thanks for your answer!<br>
<br>
<br>
<br></div>
2013/12/20 Nikita Tsukanov <<a href="mailto:keks9n@gmail.com" target="_blank">keks9n@gmail.com</a> <mailto:<a href="mailto:keks9n@gmail.com" target="_blank">keks9n@gmail.com</a>>><div class="im"><br>
<br>
    Don't use OpenVZ, it limits _virtual_ memory, not physical. Mono threads use a small amount of physical memory, but<br>
    might reserve high of virtual memory space. You'd rather try KVM/Xen virtualization.<br>
<br>
    Regards,<br>
    Nikita<br>
<br></div>
    2013/12/19 Nicolas Antoniazzi <<a href="mailto:nicolas.antoniazzi@gmail.com" target="_blank">nicolas.antoniazzi@gmail.com</a> <mailto:<a href="mailto:nicolas.antoniazzi@gmail.com" target="_blank">nicolas.antoniazzi@<u></u>gmail.com</a>>><div class="im">

<br>
<br>
        Hi,<br>
<br>
        I am using Mono in a virtualized environment with 512MB of RAM.<br>
        I made a very simple program which starts 10 threads in a loop and apparently, every time that I start a new<br>
        thread, approximately 65MB of memory is used.<br>
<br>
        In my case, I can run 5 threads, but for the 6th, the program crashes (without any exception). 150MB are already<br>
        consumed without the use of any thread.<br>
<br>
        Is it a normal behavior?<br>
<br>
        P.S: Sorry I double posted this message on mono-list because I did not understood that third party programmers<br>
        also had to come on this devel list.<br>
<br>
        Thanks!<br>
        --<br>
        Nicolas Antoniazzi<br>
<br>
        ______________________________<u></u>_________________<br>
        Mono-devel-list mailing list<br></div>
        <a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.<u></u>com</a> <mailto:<a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.<u></u>ximian.com</a>><div class="im">

<br>
        <a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/<u></u>mailman/listinfo/mono-devel-<u></u>list</a><br>
<br>
<br>
<br>
    ______________________________<u></u>_________________<br>
    Mono-devel-list mailing list<br></div>
    <a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.<u></u>com</a> <mailto:<a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.<u></u>ximian.com</a>><div class="im">

<br>
    <a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/<u></u>mailman/listinfo/mono-devel-<u></u>list</a><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.<u></u>com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/<u></u>mailman/listinfo/mono-devel-<u></u>list</a><br>
<br>
</div></blockquote>
<br>
</blockquote></div><br></div></div>