* Claudio Jeker <[email protected]> [2010-03-01 15:32]: > 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.
of course. it is not carp's duty. if we fail over on cluster shortage the other node will be short of clusters too - bouncy bouncy. assuming we don't leak of course. > > > 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. err, yes? that's exactly what i was saying. -- Henning Brauer, [email protected], [email protected] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
