Il giorno 06/apr/2011, alle ore 17.40, Juliusz Gonera ha scritto: > Yann Malet wrote: >> Julius, >> Harakiri is time based where the feature above recycle the the worker if >> the memory consumption get higher than the limit you fix. >> regards, > > I'm sorry, I confused harakiri with --limit-as. What is the difference > between those new options and --limit-as? > -- >
--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
