Thanks Willy, this usually happens when i send restart signals to a process while the older process has not finished.
ej. proces 1000 is currently active so i send restart to haproxy with -sf 1000 new process is 1001 the killing of process 1000 takes say 30 secs in that same 30 seconds my auto scale adds or removes another server and sends restarts haproxy with -sh 1001 im not sure which of the both gets in D state but it only happens when im doing scaling of more than 1 host at the time. the server is currently processing about 200k requests per minute so it takes a bit to restart an instance. I've changed my script to only add or remove 1 server at the time see if that helps. On another note, I've been looking for a concise guide on what kernel parameters i can tweak to improve performance. I gotta say im impressed already on how well it handles traffic. but i would like to perhaps try to squeeze a bit more. out of it on peaks each one of my load balancer is balancing about 100 backend servers and processing an average of 3k- 5k requests per second. On Nov 19, 2009, at 1:36 PM, Willy Tarreau wrote: > On Wed, Nov 18, 2009 at 09:00:22PM -0800, Jose Avila(Tachu) wrote: >> i've been noticing some of my load balancers show up processes in D stat. >> this processes obviously cant be killed and if i look at my server load it >> shows a higher load than servers with no processes in D stat. Any ideas on >> what I can do to get rid of these processes?? other than rebooting? > > A process in D state means the process is waiting in the kernel > for something. The only thing I can see is that your kernel is > very ill, because haproxy only does non-blocking accesses, so I > think that if you run "dmesg", you'd see some odd messages. > Most likely you're on a deadlock inside the kernel. Check your > version and try to update it from your distro's repository. And > from your description, I think you'll have to reboot anyway to > get rid of that. > > Willy >
