If I'm not mistaken, the omnibus installation performs sizing based
upon apparent available memory.  If the max_swap for you zone equals
the max_physical_memory, then the expectation of Linux overcommit
semantics is likely to cause problems.  I would recommend cranking the
max_swap up for the instance.

I have a Gitlab instance running fine under LX with a ratio of 2GB
max_physical_mem and 8GB max_swap.

On 17 September 2016 at 18:30, Joshua M. Clulow <j...@sysmgr.org> wrote:
> 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
>     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
> improves.
> 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.
> Cheers.
> --
> Joshua M. Clulow
> UNIX Admin/Developer
> http://blog.sysmgr.org

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