Alright. Thanks a lot for that information!
2017-02-06 14:35 GMT+01:00 Avi Kivity :
> It is a bug. In some contexts, the kernel needs to be able to reclaim
> memory instantly, but this is not one of them. Here, the java process is
> creating a new thread, and the kernel is allocating 16kB for i
It is a bug. In some contexts, the kernel needs to be able to reclaim
memory instantly, but this is not one of them. Here, the java process
is creating a new thread, and the kernel is allocating 16kB for its
kernel stack; that is a regular allocation, not atomic. If you decide
the gfp_mask va
Some people compact memory in cron jobs with: echo 1 > /proc/sys/vm/
compact_memory
to defragment the ram. Try this on a sacrified server first :)
On Thu, Jan 26, 2017 at 6:36 AM, Benjamin Roth
wrote:
> Hi there,
>
> We installed 2 new nodes these days. They run on ubuntu (Ubuntu 16.04.1
> LTS)
Thanks for the reply. We got rid of the OOMs by increasing
vm.min_free_kbytes, it's default of approx 90mb is maybe a bit low for
systems with 128GB.
I guess the OOM happens because the kernel could not reclaim enough paged
memory instantly.
I can't tell if this is really a kernel bug or not. It al
On 01/26/2017 07:36 AM, Benjamin Roth wrote:
Hi there,
We installed 2 new nodes these days. They run on ubuntu (Ubuntu
16.04.1 LTS) with kernel 4.4.0-59-generic. On these nodes (and only on
these) CS gets killed by the kernel due to OOM. It seems very strange
to me because, CS only takes rou
Hi there,
We installed 2 new nodes these days. They run on ubuntu (Ubuntu 16.04.1
LTS) with kernel 4.4.0-59-generic. On these nodes (and only on these) CS
gets killed by the kernel due to OOM. It seems very strange to me because,
CS only takes roughly 20GB (out of 128GB), most of RAM is allocated
