<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 24, 2010, at 10:40 AM, Angelo Höngens wrote:</div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>According to top, the CPU usage for the varnishd process is 0.0% at 400<br>req/sec. The load over the past 15 minutes is 0.45, probably mostly<br>because of haproxy running on the same machine. So I don't think load is<br>a problem.. My problem is that varnish sometimes just crashes or stops<br>responding.<br><br>My hit cache ratio is not that high, around 80%, and the backend servers<br>can be slow at times (quite complex .net web apps). But I've changed<br>some settings, and I am waiting for the next time varnish starts to stop<br>responding.. I'm beginning to think it's something that grows over time,<br>after restarting the varnish process things tend to run smooth for a<br>while. I'll just keep monitoring it.</div></blockquote><br></div><div>The other most common reason why the varnish supervisor can start killing off children is when they are blocked waiting on a page-in, which is usually due to VM overcommit (i.e., storage file size significantly exceeds RAM and you have a very large hot working set). You can usually see that when "iostat -x" output shows the I/O busy % is close to 100, meaning the disk is saturated. You can also see that in vmstat (look at the pi/po columns if you're using a file, or si/so if you're using malloc).</div><div><br></div><div>--Michael</div><br></body></html>