Re: Memcached, out of sockets
On Jun 16, 3:38 pm, Brian Neal wrote: > Wellinstead of ranting about this here, why don't you open a > ticket and detail your findings. It is in the communities best > interest to have something like this fixed if it is indeed a problem. > Thanks. Because the "fix" will introduce the original problem again - you need to clean up all socket or they might leak when you do a apache2ctl graceful, or when you have a high MaxClients count with mod_python (think large installations with worker mpm). So, what is less evil? Keep the connection alive, or kill it after every request? For us, keeping it alive works, but for others, it might break. You can't really file that as a bug, right? Reopened the original ticket, if it gets rejected, at least people can find the solution on google :P Miles --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Memcached, out of sockets
On Jun 15, 7:28 pm, Miles wrote: > I've been running the python memcached connector for a while, without > much trouble. But just today during a stress test of one of the feeds > (read: many many requests expected), I've ran into an out of sockets > situation. > > After every single request, the cache backend forces a disconnect from > all memcached servers. That's no problem if you don't get too many > hits, but after about ~5k requests in a minute, python just fails to > connect to memcached and falls back to database access. > > Cause: > > Fixed #5133 -- Explicitly close memcached connections after each > request > (similar to database connection management). We can't effectively > manage the > lifecycle by pooling connections and recent versions of python- > memcache can > lead to connection exhaustion in some quite reasonable setups. > > Memcached is designed to help web apps hit insane throughput, not kill > the whole server by exhausting all available sockets by forcing them > all in TIME_WAIT... Without a decent amount of traffic, people > wouldn't even bother to run memcached. > > Oh well, I'll be nooping the fix locally. That it added another 30% > throughput on windows is just a bonus. If you plan to disable close > with something like > django.core.cache.backends.memcached.CacheClass.close = lambda x: > None, make sure you also set memcache._Host._DEAD_RETRY = 5. Otherwise > a broken socket can cause 30s of no cache on a thread, or worse, 30s > of no cache at all when you restart memcached, instead of reconnecting > on the next request. I thought I hit a bug the first I saw it happen. > > With a mod_wsgi deamon mode setup, max-requests=500, I'm not scared of > leaking some sockets which gets freed after a few minutes at most. Wellinstead of ranting about this here, why don't you open a ticket and detail your findings. It is in the communities best interest to have something like this fixed if it is indeed a problem. Thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Memcached, out of sockets
I've been running the python memcached connector for a while, without much trouble. But just today during a stress test of one of the feeds (read: many many requests expected), I've ran into an out of sockets situation. After every single request, the cache backend forces a disconnect from all memcached servers. That's no problem if you don't get too many hits, but after about ~5k requests in a minute, python just fails to connect to memcached and falls back to database access. Cause: Fixed #5133 -- Explicitly close memcached connections after each request (similar to database connection management). We can't effectively manage the lifecycle by pooling connections and recent versions of python- memcache can lead to connection exhaustion in some quite reasonable setups. Memcached is designed to help web apps hit insane throughput, not kill the whole server by exhausting all available sockets by forcing them all in TIME_WAIT... Without a decent amount of traffic, people wouldn't even bother to run memcached. Oh well, I'll be nooping the fix locally. That it added another 30% throughput on windows is just a bonus. If you plan to disable close with something like django.core.cache.backends.memcached.CacheClass.close = lambda x: None, make sure you also set memcache._Host._DEAD_RETRY = 5. Otherwise a broken socket can cause 30s of no cache on a thread, or worse, 30s of no cache at all when you restart memcached, instead of reconnecting on the next request. I thought I hit a bug the first I saw it happen. With a mod_wsgi deamon mode setup, max-requests=500, I'm not scared of leaking some sockets which gets freed after a few minutes at most. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
