On 17 September 2016 at 16:39, Joe Landman
<land...@scalableinformatics.com> wrote:
> On 09/17/2016 07:30 PM, Joshua M. Clulow wrote:
>> 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.
> This said, SIGBUS is not usually memory allocation related ... this is more
> typically a memory alignment issue. Google is your friend here.
> http://www.linuxprogrammingblog.com/all-about-linux-signals?page=4
I should probably have been more explicit. My suggestion was in the
context of this discussion about LX branded zone environments, which
are Linux _compatible_, but not otherwise related to the Linux kernel.
Alignment issues are generally less common on x86 systems than on
other platforms, unless you're doing something unusual. It's much
_more_ likely that a SIGBUS will arise _in an LX branded zone_ because
of swap cap exhaustion, because of the lack of memory over commit and
the implicit use of MAP_NORESERVE for mappings in LX processes. It's
possible to confirm this by examining the fatal signal information
from a core file, if one was generated.
As Patrick notes, increasing the swap cap ("max_swap") for the zone is
likely to improve the situation for this workload.
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
