<font size="2"><font face="georgia,serif">I forgot about your min_free_kbytes question:</font></font><div><font size="2"><font face="georgia,serif"><br></font></font></div><meta charset="utf-8"><div><font size="2"><font face="georgia,serif">While I would personally recommend 131072 as <i>a starting point</i>, this value does not translate directly to what is actually retained as free RAM. In my experience, the kernel's behavior is non-linear, non-deterministic, and very delicate. Usually the kernel will keep much more free RAM than specified (2-3x), and modifying this value too often under load will cause permanent behavior problems in the kernel.</font></font></div>
<div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><font size="2"><font face="georgia,serif"></font></font><font class="Apple-style-span" face="georgia, serif">Setting it to 10% is a terrible idea under any circumstance I can imagine. The goal with this setting in the context of a backing-store cache is to set it high enough that you have 5-15 seconds of read/write I/O throughput available for bursts. For example, if Varnish is committing 5MB/s to/from disk, make sure you have 25-75MB of RAM free at a minimum. This might only translate to a min_free_kbytes of 12000-30000.<br>
</font><div><font size="2"><font face="georgia,serif"><br></font></font></div><div><font size="2"><font face="georgia,serif">I'd strongly suggest modifying the value slowly and carefully, ideally only once after a reboot via sysctl.conf. But once done, my 1TB -spersistent Varnish instances became very stable.<br clear="all">
</font></font><font face="georgia, serif">-- </font><div><font face="georgia, serif">kb</font></div><br>
<br><br><div class="gmail_quote">On Fri, Apr 8, 2011 at 13:55, Ken Brownfield <span dir="ltr"><<a href="mailto:kbrownfield@google.com">kbrownfield@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font size="2"><font face="georgia,serif">This means the child process died and restarted (the reason for this should appear earlier in the log; perhaps your cli_timeout is too low under a heavily loaded system -- try 20s).</font></font><div>
<font size="2"><font face="georgia,serif"><br></font></font></div><div><font size="2"><font face="georgia,serif">"-sfile" is not persistent storage, so when the child process restarts it uses a new, empty storage structure. You should have luck with "-spersistent" on the latest Varnish or trunk, at least for child process restarts.</font></font></div>
<div><font size="2"><font face="georgia,serif"><br></font></font></div><div><font size="2"><font face="georgia,serif">FWIW,<br clear="all"></font></font><font face="georgia, serif">-- </font><div><font face="georgia, serif">kb</font></div>
<br>
<br><br><div class="gmail_quote">On Fri, Apr 8, 2011 at 01:55, Jean-Francois Laurens <span dir="ltr"><<a href="mailto:jean-francois.laurens@rts.ch" target="_blank">jean-francois.laurens@rts.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<font size="4"><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Hi Ken,<br>
<br>
Thanks for the hint ! <br>
You’re affecting here 128Mb, how did you get to this munber ? I read somewhere that this value can be set to 10% of the actual memory size which would be in my case 800Mb, does it make sense for you ?<br>
I read aswell that setting this value to high would crash the system immediately.<br>
<br>
<br>
Yesterday evening, the system was in heavy load but varnish did not hang !<br>
Instead it dropped all its objects ! Then the load went back fine.<br>
It seems setting –sfile to 40Gb suits better the memory capability for this server.<br>
A question remains though ... Why all the objects were dropped ?<br>
Attached is a plot from cacti regarding the number of objects.<br>
<br>
The only thing I could get form the messages log is this :<br>
Apr 7 19:00:29 server-01-39 varnishd[3732]: Child (3733) died signal=3<br>
Apr 7 19:00:29 server-01-39 varnishd[3732]: Child cleanup complete<br>
Apr 7 19:00:29 server-01-39 varnishd[3732]: child (29359) Started<br>
Apr 7 19:00:29 server-01-39 varnishd[3732]: Child (29359) said <br>
Apr 7 19:00:29 server-01-39 varnishd[3732]: Child (29359) said Child starts<br>
Apr 7 19:00:29 server-01-39 varnishd[3732]: Child (29359) said managed to mmap 42949672960 bytes of 42949672960<br>
<br>
<br>
How could I get to know what is realy happening that could explain this behaviour ?<br>
<br>
Cheers,<br>
Jef</span></font></font></div></blockquote></div></div>
</blockquote></div><br></div></div>