Thank you for such detailed explanation. This clears it up!
Roberto De Ioris wrote: > --limit-as set the limit at the kernel level (using setrlimit()). > > This is a perfect system of isolation, but if the apps is not written in a > safe way you can end > with a blocked worker. (but in such case harakiri would really help) > > > If you check in the uWSGI source you will see that uwsgi_malloc will exit() > in case of problems. > > This will allow to force a respawn if the address space is finished. > > Python will raise a MemoryError, but c extensions can do whatever they want > (including trying to malloc > indefinitely). > > So, setrlimit() is good for security/isolation but bad for reliability (even > if i have had problems only with ruby and lua and > never with python). > > --reload-on-* is a more gentle way (customer will never notice their > presence). They monitor the memory usage after each request, > end eventually recycle the worker. all gracefully and without spitting out > errors. > > Obviously you can get both to reach isolation and reliability. > > As an example (from now on) i will set all of my apps in this way: > > --limit-as 768 --reload-on-rss 256 > > This will allow me to never occupy more than 256 megs of physical memory but > will allow me using unix features like mmap() > to extend and abuse the address space. > > This particular setup will even prevent a logic bug when a single requests > will enter a loop and start growing memory before the worker will check for > memory usage: > --limit-as will avoid the process to fill all the memory > -- > Roberto De Ioris > http://unbit.it > > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > -- Juliusz Gonera http://juliuszgonera.com/ _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
