On Mon, Mar 01, 2010 at 02:48:50PM +0100, Henning Brauer wrote: > * Pete Vickers <[email protected]> [2010-03-01 12:28]: > > okay, sounds reasonable. I've also 'fiddled with other knobs' too, so I hope > > my kern.maxclusters at 8192 should not cause exhaustion conjunction with: > > > > > > net.inet.ip.ifq.maxlen=512 > > net.inet.tcp.recvspace=262144 > > net.inet.tcp.sendspace=262144 > > kern.maxfiles=8192 > > kern.maxclusters=8192 > > > > > > BTW, when the system runs out of (these?) resources, it sometimes prevents > > SSH > > access or squid use, but still keeps a CARP peering alive, preventing > > failover > > to it's backup partner, which is somewhat frustrating (I know I could script > > around this). > > this is perfectly sane and the intended bahaviour. no mbufs / clusters > available -> packet dropped. >
Actually carp(4) still works since it sends small packets which fit in an mbuf. And we have far enough mbufs available. I'm not sure if it is carp's duty to check if a resource shortage causes a subsytem to fail. > > On other occasions, it drops into ddb> , which at least allows > > the CARP backup to take over duties. (I know I should file a bug report for > > this) > > yes, in an idea world that doesn't happen and the system copes with > the ressource shortage. > Sometimes coping with an allocation failure is very hard. On the other hand the network stack should not panic or crash the system on resource shortage. -- :wq Claudio
