util: Work around (virtual) memory exhaustion on 32-bit w/ glibc #10120
Conversation
glibc-specific: On 32-bit systems set the number of arenas to 1. By default, since glibc 2.10, the C library will create up to two heap arenas per core. This is known to cause excessive virtual address space usage in our usage. Work around it by setting the maximum number of arenas to 1.
|
utACK. |
|
I'm not familiar with the intricacies here, so I'll defer judgement on the root issue. The implementation suggests that it's meant to apply to glibc only, but there's no obvious check for that. Is M_ARENA_MAX itself glibc specific, or do we need some macro to check for it? |
The root issue is that freed object stay around for a while for reuse, so having 8 heaps means that they can potentially stick around 8 times. This is extremely bad considering e.g. how large the consecutive objects are that leveldb allocates.
As always, feel free to suggest a better way to do the autoconf stuff. Yes, M_ARENA_MAX is specific to glibc (or anything deriving from it). |
|
I didn't mean to imply that anything was incorrect, just wanted to clarify the assumptions. Thanks for explaining. Code looks good. utACK 625488a |
… w/ glibc 625488a util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (Wladimir J. van der Laan) Tree-SHA512: 99b610a8cf9561998af90e16fc19320fddd30c987e8f33325d63df0f56d70235b94d9482e80f28154d4b33a3ecf4961686380c444ec18d1da5e8804a8b6f4de1
glibc-specific: On 32-bit systems set the number of arenas to 1. By default, since glibc 2.10, the C library will create up to two heap arenas per core. This is known to cause excessive virtual address space usage in our usage. Work around it by setting the maximum number of arenas to 1. Github-Pull: #10120 Rebased-From: 625488a
… 32-bit w/ glibc 625488a util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (Wladimir J. van der Laan) Tree-SHA512: 99b610a8cf9561998af90e16fc19320fddd30c987e8f33325d63df0f56d70235b94d9482e80f28154d4b33a3ecf4961686380c444ec18d1da5e8804a8b6f4de1
glibc-specific: On 32-bit systems set the number of arenas to 1. By default, since glibc 2.10, the C library will create up to two heap arenas per core. This is known to cause excessive virtual address space usage in our usage. Work around it by setting the maximum number of arenas to 1. Github-Pull: bitcoin#10120 Rebased-From: 625488a
… 32-bit w/ glibc 625488a util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (Wladimir J. van der Laan) Tree-SHA512: 99b610a8cf9561998af90e16fc19320fddd30c987e8f33325d63df0f56d70235b94d9482e80f28154d4b33a3ecf4961686380c444ec18d1da5e8804a8b6f4de1
… 32-bit w/ glibc 625488a util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (Wladimir J. van der Laan) Tree-SHA512: 99b610a8cf9561998af90e16fc19320fddd30c987e8f33325d63df0f56d70235b94d9482e80f28154d4b33a3ecf4961686380c444ec18d1da5e8804a8b6f4de1
glibc-specific: On 32-bit systems set the number of arenas to 1. By default, since glibc 2.10, the C library will create up to two heap arenas per core. This is known to cause excessive virtual address space usage in our usage. Work around it by setting the maximum number of arenas to 1.
I documented this before in Reducing bitcoind memory usage but with the reported OOM issues in 0.14 it seems more pressing to do it by default when there is low virtual memory space (e.g. on 32 bit).
To test:
This will show an entry per heap.
Tested on 32-bit ARM, 4-core:
Tested on 64-bit x86, 6-core: