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).
"-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. FWIW, -- kb On Fri, Apr 8, 2011 at 01:55, Jean-Francois Laurens < [email protected]> wrote: > Hi Ken, > > Thanks for the hint ! > 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 ? > I read aswell that setting this value to high would crash the system > immediately. > > > Yesterday evening, the system was in heavy load but varnish did not hang ! > Instead it dropped all its objects ! Then the load went back fine. > It seems setting –sfile to 40Gb suits better the memory capability for this > server. > A question remains though ... Why all the objects were dropped ? > Attached is a plot from cacti regarding the number of objects. > > The only thing I could get form the messages log is this : > Apr 7 19:00:29 server-01-39 varnishd[3732]: Child (3733) died signal=3 > Apr 7 19:00:29 server-01-39 varnishd[3732]: Child cleanup complete > Apr 7 19:00:29 server-01-39 varnishd[3732]: child (29359) Started > Apr 7 19:00:29 server-01-39 varnishd[3732]: Child (29359) said > Apr 7 19:00:29 server-01-39 varnishd[3732]: Child (29359) said Child > starts > Apr 7 19:00:29 server-01-39 varnishd[3732]: Child (29359) said managed to > mmap 42949672960 bytes of 42949672960 > > > How could I get to know what is realy happening that could explain this > behaviour ? > > Cheers, > Jef >
_______________________________________________ varnish-misc mailing list [email protected] http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
