On Mon, Jul 5, 2010 at 9:08 AM, Per Buer <[email protected]> wrote: > There is only one place where SIGQUIT is used and that is where you're > hitting it. I'd try to disable the whole check by setting the > cli_timeout ridiculously high. If you have proper monitoring the risk > isn't high.
That makes sense. I was slow in catching onto the fact that Varnish was simply killing its child because it was slow in responding to the pings; from my point of view it looked more like Varnish was hanging. > You might be having issues with your io scheduler (cfq > can be a real disaster) or a bigger working set then your memory can > handle (swap on Linux doesn't work very well). How do I go about determining the underlying cause? As far as I can see, it's not caused by any increase in traffic. I am tracking every varnishstat metric using Munin, and not seeing anything out of the ordinary at the instances when Varnish kills itself -- nor with any of the other system metrics tracked with Munin. There should be plenty of memory available, and I'm not seeing any swapping. Linux 2.6.24 + CFQ reports weird CPU usage [1] that screws up our graphs, but that's hardly an indication of anything. However, we should probably try to switch away from CFQ. [1] http://grab.by/grabs/af573a30e5be0774edcfffc77294f4d8.png _______________________________________________ varnish-misc mailing list [email protected] http://lists.varnish-cache.org/mailman/listinfo/varnish-misc
