Re: maxusers (thus mbuf etc.) autotuning capped at 384

From: Andre Oppermann <andre_at_freebsd.org>
Date: Wed, 24 Oct 2012 17:53:08 +0200
On 24.10.2012 16:26, Vadim Goncharov wrote:
> Hi,
>
> We have 'maxusers' tunable which affects many other tunables, e.g. number of
> network mbuf/clusters which is often too low on current machines.

The mbuf/cluster limit can be rethought as well.  Since it all comes
out of UMA and is not pre-allocated we could simply set it to
"physpages / 2" or "physpages / 4 * 3".  Relating it to maxusers isn't
meaningful anymore.

In the same area the kern.maxfiles, kern.maxfilesperproc and
kern.ipc.maxsockets need rethinking as well.  For modern systems and
busy servers it should be at least in the 100k area, if not more.
It should have some magic value per GB physical memory as well.

You have to make sure that this is true though:
  kern.maxfiles > kern.ipc.maxsockets > kern.maxfilesperproc

> There is code in sys/kern/subr_param.c:
>
>          if (maxusers == 0) {
> 	        maxusers = physpages / (2 * 1024 * 1024 / PAGE_SIZE);
> 		if (maxusers < 32)
> 		        maxusers = 32;
> 		if (maxusers > 384)
> 		        maxusers = 384;
> 	}
>
> It was capped to 384 for i386 KVM size limits in r89769, so that amd64, not
> constrained to 1Gb KVA, suffers from this. I suspect that 384 may be wrong even
> for i386 today, but let's be conservative and limit maxusers to 384 per 1 Gb of
> KVM, like this:
>
> #define _MAX_MAXUSERS           (((VM_MAX_KERNEL_ADDRESS - \
>      KERNBASE) / (8 * 1024 * 1024)) * 3)
>
>          if (maxusers == 0) {
> 	        maxusers = physpages / (2 * 1024 * 1024 / PAGE_SIZE);
> 		if (maxusers < 32)
> 		        maxusers = 32;
> 		if (maxusers > _MAX_MAXUSERS)
> 		        maxusers = _MAX_MAXUSERS;
> 	}
> #undef _MAX_MAXUSERS

This is very round-about.  Why don't you simply write 384 per GB in
there directly?

Thinking of it these "magic" whatever-per-GB value definitions
should be next to each other in param.h or some other suitable
place.

-- 
Andre
Received on Wed Oct 24 2012 - 13:51:41 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:31 UTC