Vanrish 2.1.5 eating memory, hit % decrease
kbrownfield at google.com
Fri Apr 8 22:55:29 CEST 2011
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
On Fri, Apr 8, 2011 at 01:55, Jean-Francois Laurens <
jean-francois.laurens at rts.ch> 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
> 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
> 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: Child (3733) died signal=3
> Apr 7 19:00:29 server-01-39 varnishd: Child cleanup complete
> Apr 7 19:00:29 server-01-39 varnishd: child (29359) Started
> Apr 7 19:00:29 server-01-39 varnishd: Child (29359) said
> Apr 7 19:00:29 server-01-39 varnishd: Child (29359) said Child
> Apr 7 19:00:29 server-01-39 varnishd: 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 ?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the varnish-misc