Hi, On Wed, Jan 18, 2012 at 16:52, Andreas Plesner Jacobsen <[email protected]> wrote: > > SMA.Transient.g_bytes 4409627649 . Bytes outstanding
Thanks Andreas, this is incredibly useful information. Now, since last I posted, the process in question has grown further, to 25653 nobody 20 0 59.7g 21g 81m S 22 22.4 1092:15 varnishd and varnishstat says proxy03 jan # varnishstat -1 | grep -i trans SMA.Transient.c_req 14802020 24.56 Allocator requests SMA.Transient.c_fail 0 0.00 Allocator failures SMA.Transient.c_bytes 963605906690 1598878.84 Bytes allocated SMA.Transient.c_freed 951833551349 1579345.37 Bytes freed SMA.Transient.g_alloc 1239195 . Allocations outstanding SMA.Transient.g_bytes 11772355341 . Bytes outstanding SMA.Transient.g_space 0 . Bytes available When would transient objects actually leave the storage again? Can I force/trigger/monitor this at all? The manual says "By default Varnish would use an unlimited malloc backend for this", which in my case is rather inconvenient since this varnish process sits in an LXC container, where it apparently sees the host's memory allocation and not the container's - that in turn leads to amusing situations where Varnish runs head first into the LXC resource limitations and gets OOM-killed. Best regards Jan _______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
