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.
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 ...
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)
/Pete
