FreeBSD 10 & default_vsz_limit causing reboots?

[Rick Romero]

  Quoting Timo Sirainen <tss at iki.fi>:

> On 24 Sep 2015, at 16:26, Rick Romero <rick at havokmon.com> wrote:
>> Update.  Only a single reboot has occurred since changing
>> defalt_vsz_limit from 384M to 512M.  It would seem that something the
>> users are doing is causing that virtual memory size to be exceeded
>> (possibly a mailbox search?), and when that occurs Dovecot/FreeBSD is
not
>> handling the event as smoothly as expected.
>
> I could maybe understand that a system might reboot in some conditions
> when it runs out of memory, but you're doing the exact opposite of
> avoiding that by increasing the vsz limit. It just means that the system
> is potentially going to use even more memory. And wouldn't FreeBSD have
> something similar to Linux's out-of-memory killer?
> I think either your hardware is broken or FreeBSD has some serious bug,
> and a hardware problem seems more likely to me.

I was thinking along the lines of the process kill handling (? I don't know
what actually occurs when the limit is reached - I'm assuming a thread is
terminated) was triggering something odd in FreeBSD.

Activity/Usage has increased with the frequency of reboots, at least until
I changed that parameter. User acitivty is the same, reboots have decreased
dramatically (Just 1 since the change 9/14).  While I wouldn't rule it
out, it seems to me that it's less likely to be a hardware problem if I've
simply provided MORE memory to a process (or set of processes) to avoid the
issue...

This is my current 'top' output.  It's not that the system is actually
running low on memory, so I had no heisitation increasing the vsz limit.
last pid: 59072;  load averages:  0.30,  0.29, 
0.32                                                          
up 7+03:02:34  14:27:59
1265 processes:1 running, 1264 sleeping
CPU:  2.6% user,  0.0% nice,  1.4% system,  0.2% interrupt, 95.9% idle
Mem: 3326M Active, 2210M Inact, 25G Wired, 8828K Cache, 1655M Buf, 1000M
Free
ARC: 20G Total, 14G MFU, 4646M MRU, 3845K Anon, 621M Header, 1216M Other
Swap: 4096M Total, 4096M Free

Now, it's entirely possible that the user(s) who were eating all my server
resources stopped using the system at the same time I increased the vsz
limit, but that seems unlikely.

I'm leaning towards a FreeBSD issue of some sort - but I thought this might
be a more approprate place as I have no hard data, I'm not sure what other
software might use a similar vsz limit process/check that could trigger the
oddity, and I just wanted it documented somewhere. :)
  
Rick