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 <[email protected]> wrote: > On 17 September 2016 at 15:39, Daniel Carosone > <[email protected]> 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 > ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
