Adrian Chadd 32766cd281 Also make kern.maxfilesperproc a boot time tunable.
Auto-tuning threshold discussions aside, it turns out that if you want
to lower this on say, rather memory-packed machines, you either set maxusers
or kern.maxfiles, or you set it in sysctl.  The former is a non-exact
way to tune this; the latter doesn't actually affect anything in the
startup scripts.

This first occured because I wondered why the hell screen would take upwards
of 10 seconds to spawn a new screen.  I then found python doing the same
thing during fork/exec of child processes - it calls close() on each FD
up to the current openfiles limit.  On a 1TB machine this is like, 26 million
FDs per process.  Ugh.

So:

* This allows it to be set early in /boot/loader.conf;
* It can be used to work around the ridiculous situation of
  screen, python, etc doing a close() on potentially millions of FDs
  even though you only have four open.

Tested:

* 4GB, 32GB, 64GB, 128GB, 384GB, 1TB systems with autotune, ensuring
  screen and python forking doesn't result in some pretty hilariously
  bad behaviour.

TODO:

* Note that the default login.conf sets openfiles-cur to unlimited,
  effectively obeying kern.maxfilesperproc.  Perhaps we should fix
  this.

* .. and even if we do, we need to also ensure that daemons get
  a soft limit of something reasonable and capped - they can request
  more FDs themselves.

MFC after:	1 week
Sponsored by:	Norse Corp, Inc.
2015-09-10 04:05:58 +00:00
..
2015-08-28 20:06:58 +00:00
2015-07-20 09:37:42 +00:00
2015-04-22 14:38:58 +00:00
2015-06-30 17:00:45 +00:00
2015-01-22 11:12:42 +00:00
2014-03-14 06:29:43 +00:00
2015-06-30 17:00:45 +00:00
2014-06-26 13:57:44 +00:00
2014-08-11 15:06:07 +00:00
2015-01-22 11:12:42 +00:00
2015-06-10 10:48:12 +00:00
2015-07-29 17:18:27 +00:00
2015-07-11 15:22:11 +00:00
2015-07-11 15:22:11 +00:00
2015-07-11 15:22:11 +00:00
2015-06-10 10:48:12 +00:00
2015-03-17 14:16:50 +00:00
2015-08-01 07:21:14 +00:00
2015-07-30 15:43:26 +00:00