util: Work around (virtual) memory exhaustion on 32-bit w/ glibc #10120

1. 
   laanwj commented at 8:16 AM on March 30, 2017: member

   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:

   bitcoin-cli getmemoryinfo mallocinfo | grep "<heap"
   

   This will show an entry per heap.

   Tested on 32-bit ARM, 4-core:

   <heap nr="0">
   

   Tested on 64-bit x86, 6-core:

   <heap nr="0">
   <heap nr="1">
   <heap nr="2">
   <heap nr="3">
   <heap nr="4">
   <heap nr="5">
   <heap nr="6">
   <heap nr="7">
   <heap nr="8">
   <heap nr="9">
   <heap nr="10">
   <heap nr="11">
   <heap nr="12">
   

2. util: Work around (virtual) memory exhaustion on 32-bit w/ glibc

   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.

   625488ace5
3. laanwj added the label Needs backport on Mar 30, 2017
4. laanwj added the label Utils and libraries on Mar 30, 2017
5. laanwj added this to the milestone 0.14.1 on Mar 30, 2017
6. gmaxwell approved
7. 
   gmaxwell commented at 4:29 PM on March 30, 2017: contributor

   utACK.

8. 
   JeremyRubin commented at 5:29 PM on March 30, 2017: contributor

   utACK.

9. laanwj added this to the "For backport" column in a project

---

10. 
    theuni commented at 5:06 AM on March 31, 2017: member

    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?

11. 
    laanwj commented at 5:43 AM on March 31, 2017: member

    I'm not familiar with the intricacies here, so I'll defer judgement on the root issue.

    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.

    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?

    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).

12. 
    theuni commented at 6:46 AM on March 31, 2017: member

    I didn't mean to imply that anything was incorrect, just wanted to clarify the assumptions. Thanks for explaining. Code looks good. utACK 625488ace5c41ccba1b68323a72588000782f820

13. laanwj merged this on Mar 31, 2017
14. laanwj closed this on Mar 31, 2017

    ---

15. laanwj referenced this in commit ba12b3a844 on Mar 31, 2017
16. laanwj referenced this in commit e4c9a90fe9 on Mar 31, 2017
17. laanwj removed the label Needs backport on Mar 31, 2017
18. laanwj removed this from the "For backport" column in a project

---

19. codablock referenced this in commit 42d3060568 on Jan 26, 2018
20. lateminer referenced this in commit bab0df1b09 on Jan 5, 2019
21. andvgal referenced this in commit ce84e85fa6 on Jan 6, 2019
22. CryptoCentric referenced this in commit 4533c1a9f0 on Feb 27, 2019
23. PastaPastaPasta referenced this in commit 1e2de487dc on Mar 15, 2019
24. PastaPastaPasta referenced this in commit d86bb023fc on May 20, 2019
25. PastaPastaPasta referenced this in commit de066ac3db on May 20, 2019
26. PastaPastaPasta referenced this in commit 5dc3f503ec on May 21, 2019
27. PastaPastaPasta referenced this in commit 8e9c2eb2f3 on May 22, 2019
28. PastaPastaPasta referenced this in commit c9f0568483 on May 22, 2019
29. PastaPastaPasta referenced this in commit 2752cbde53 on May 22, 2019
30. PastaPastaPasta referenced this in commit 2f256f5080 on May 22, 2019
31. PastaPastaPasta referenced this in commit c81d1d2aa2 on May 23, 2019
32. MarcoFalke locked this on Sep 8, 2021

Contributors

laanwjgmaxwellJeremyRubintheuni

Milestone
0.14.1