On 17 September 2016 at 15:39, Daniel Carosone
<daniel.caros...@gmail.com> wrote:
> I tried this a couple of weeks ago, with no luck either. I was getting some 
> (apparently random) SIGBUS backtraces from ruby in amongst the logs.

Linux allows for pretty flagrant memory over-commit; that is, programs
may allocate a lot more memory than what is available in the system.
Historically, our operating system (illumos, as with Solaris before
it) has _not_ allowed for over commit.  Instead, we account for all
memory allocated, such that we can't get into a situation where there
is a "run on the bank": where programs try to use some of the
allocation we granted them, but we've dropped the ball and run out of
actual RAM to give them.

When Linux systems hit real memory pressure, a deeply questionable
facility steps in: the OOM (out of memory) killer.  This facility
takes no prisoners, terminating processes until the situation

The SIGBUS you're seeing is potentially the result of our attempt to
get _some_ of the way toward overcommit, so that Linux software can
work even when it mistakenly assumes memory is an infinite resource.
We force the MAP_NORESERVE flag for some mmap() allocations made by LX
branded processes[1].  If there is a subsequent run on the bank, we
kill the process that would have overrun the swap cap in the zone with
SIGBUS, rather than random other processes.

If you're routinely seeing SIGBUS, it's possible that your swap cap
(and probably your RSS cap) should be higher for your workload.  With
the same software instead running in a native (non-LX) zone, you would
probably have seen ENOMEM errors, or a failure to fork(2) new
processes.  Native zones do strict accounting at the time of
allocation, so that we can report explicit errors about the memory
pressure situation.


Joshua M. Clulow
UNIX Admin/Developer

Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
Powered by Listbox: http://www.listbox.com

Reply via email to