On Fri, Feb 26, 2010 at 11:30:30AM +0100, Pete Vickers wrote:
> On 26. feb. 2010, at 03.01, Aaron Mason wrote:
> 
> > On Thu, Feb 25, 2010 at 10:04 AM, Pete Vickers <p...@systemnet.no> wrote:
> >> Hi,
> >>
> >> A proxy (squid) server running i368/4.6RELEASE with around 800 users, what
> >> would be a reasonable value to increase  kern.maxclusters too, to cure this
> :
> >>
> >>
> >> r...@proxy-s ~> grep mcl   /var/log/messages
> >> Dec 10 10:13:43 proxy-s /bsd: WARNING: mclpools limit reached; increase
> >> kern.maxclusters
> >> Dec 10 11:06:07 proxy-s /bsd: WARNING: mclpools limit reached; increase
> >> kern.maxclusters
> >> Dec 15 13:41:48 proxy-s /bsd: WARNING: mclpools limit reached; increase
> >> kern.maxclusters
> >>
> >>
> >> r...@proxy-s ~> sysctl kern.maxclusters
> >> kern.maxclusters=6144
> >>
> >>
> >> r...@proxy-s ~> netstat -m
> >> 4098 mbufs in use:
> >>        1131 mbufs allocated to data
> >>        2962 mbufs allocated to packet headers
> >>        5 mbufs allocated to socket names and addresses
> >> 1084/6152/6144 mbuf 2048 byte clusters in use (current/peak/max)
> >> 0/8/6144 mbuf 4096 byte clusters in use (current/peak/max)
> >> 0/8/6144 mbuf 8192 byte clusters in use (current/peak/max)
> >> 0/8/6144 mbuf 9216 byte clusters in use (current/peak/max)
> >> 0/8/6144 mbuf 12288 byte clusters in use (current/peak/max)
> >> 0/8/6144 mbuf 16384 byte clusters in use (current/peak/max)
> >> 0/8/6144 mbuf 65536 byte clusters in use (current/peak/max)
> >> 14176 Kbytes allocated to network (22% in use)
> >> 0 requests for memory denied
> >> 0 requests for memory delayed
> >> 0 calls to protocol drain routines
> >>
> >>
> >> something like kern.maxclusters=10000 or ?
> >>
> >>
> >>
> >> /Pete
> >>
> >>
> >
> > Only you can answer that, Pete.
> >
> > Try increasing it gradually until the errors go away.  And if the
> > error returns, increase it again.  If it makes your system unstable,
> > lower it until it returns to stability.  Increments (and decrements,
> > if necessary) of 256 would probably be wise.
> >
> > Getting the right balance with any system is all about trial and error
> > - trying different things until things are running smoothly - or
> > acceptably so in some situations.  It's also about the balance between
> > workability and stability.  Sometimes you just can't have your cake
> > and eat it too - stability must be the priority.
> >
> > My $0.02 there.
> >
> > --
> > Aaron Mason - Programmer, open source addict
> > I've taken my software vows - for beta or for worse
> >
> 
> Hi,
> 
> 
> Indeed, the only problem is that if it's too low, then the system hangs.

I guess only the network hangs. Since there is no clusters available to be
used by drivers or other sockets. Normaly the system should not hangup
itself because of that.

> Presumably if it's too high, then the 'system instability' manifests itself
> has hanging too, so it's tricky to tell which way to go, once you deviate from
> the norm ...
> 

Yes, if set too high you can run out the kernel of memory (physical or
virtual) which is normaly causing a panic or freze.

> Anyway for the archives I'm trying 8192 currently, hopefully that will reduce
> the crashes...
> 
> 
> 6016 mbufs in use:
>         2151 mbufs allocated to data
>         3860 mbufs allocated to packet headers
>         5 mbufs allocated to socket names and addresses
> 1979/5664/8192 mbuf 2048 byte clusters in use (current/peak/max)
> 0/8/8192 mbuf 4096 byte clusters in use (current/peak/max)
> 0/8/8192 mbuf 8192 byte clusters in use (current/peak/max)
> 0/8/8192 mbuf 9216 byte clusters in use (current/peak/max)
> 0/8/8192 mbuf 12288 byte clusters in use (current/peak/max)
> 0/8/8192 mbuf 16384 byte clusters in use (current/peak/max)
> 0/8/8192 mbuf 65536 byte clusters in use (current/peak/max)
> 14048 Kbytes allocated to network (38% in use)
> 

Your allocationg a max of 8192 2k buffers or 4096 4k pages or 16MB of
memory. On a modern system with > 1GB of memory everything below 64MB or
128k clusters should work if you don't fiddle with other knobs that rob
all memory from the kernel.

-- 
:wq Claudio

Reply via email to