Dnia czwartek, 1 grudnia 2011 04:46:25 Roberto De Ioris pisze: > No, workers are forked from the master(). > > Does the memory report you get is from "ps" or from the uwsgi stats server ?
Both of them, uwsgi stats shows what can be confirmed with htop. > In the second case, be sure to have this patch applied: > > http://projects.unbit.it/uwsgi/changeset/4b94dbd1c7c3be3622cae0dbb2747767693 > de5b8 I'm using revision 1740 and this was applied in 1720 so I have this patch, and it does work this way as I noticed that: 1. during worker reload uwsgi shows that it is using 0 bytes of memory, and right after it finishes rss field is back to pre-reload value (this is happening with reloads caused by hitting max-requests) 2. when I hit "reload bomb" - uwsgi stats are showing that all workers have rss field = 0 as they are reloading all the time I can reproduce the "reload bomb", it goes like this: 1. I start my vassal with django app 2. I'm hitting view that is generating avatars for all users with different sizes (~8k of unique urls), avatars are generated from user photo so it takes some memory, I'm doing 256 concurrent hits using slamd and I suspect that with such rate python's garbage collector isn't able to keep up and my workers are slowly eating more and more memory 3. when any worker hits max-requests it is being reloaded by uwsgi (logs show that, pids are changing) but it's memory usage doesn't change 4. when workers will eat up enough memory (evil)-reload-as kicks in and starts to reload them, but again after reload they continue to eat the same amount of memory so they are reloaded again and again I'll try to debug this issue more and verify that this in not problem on my side so I will let You know. Łukasz Mierzwa _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
