Linux memory arenas - Revision history

Plebeian9000: Plebeian9000 moved page Linux Memory Arenas to Linux memory arenas: wikify page title

2020-06-18T21:39:44Z

Plebeian9000 moved page Linux Memory Arenas to Linux memory arenas: wikify page title

Plebeian9000 at 20:19, 12 June 2020

2020-06-12T20:19:39Z

Bayer at 15:48, 30 April 2020

2020-04-30T15:48:57Z

Ghubstan at 20:28, 5 April 2020

2020-04-05T20:28:21Z

Ghubstan at 19:41, 5 April 2020

2020-04-05T19:41:46Z

Ghubstan at 15:19, 5 April 2020

2020-04-05T15:19:08Z

Ghubstan: Created page with "TODO"

2020-04-04T17:05:18Z

Created page with "TODO"

New page

TODO

@@ Line 1: / Line 1: @@
-== Java Threads and Linux Memory Arenas ==
+With the intention of improving efficiency of memory access in multi-threaded applications, [https://www.gnu.org/software/libc/manual/html_mono/libc.html glibc] may create more memory regions (known as [https://sourceware.org/glibc/wiki/MallocInternals#Arenas_and_Heaps arenas]) than necessary. In some cases, multi-threaded java applications allocating few and small objects can trigger creation of one arena for each of those threads, resulting in large growth of the Java process' resident memory, no matter how well on-heap memory is managed by the application.
-With the intention of improving efficiency of memory access in multi-threaded applications, [https://www.gnu.org/software/libc/manual/html_mono/libc.html glibc] may create more memory regions (known as [https://sourceware.org/glibc/wiki/MallocInternals#Arenas_and_Heaps arenas]) than necessary. &nbsp;&nbsp; In some cases, multi-threaded java applications allocating few and small objects can trigger creation of one arena for each of those threads, resulting in large growth of the java process' resident memory, no matter how well on-heap memory is managed by the application.
+One way to limit arena creation in Bisq is to define the environment variable <code>MALLOC_ARENA_MAX</code>.
-One way to limit arena creation in Bisq is to define the environment variable MALLOC_ARENA_MAX=4.
+ export MALLOC_ARENA_MAX=4
-    export MALLOC_ARENA_MAX=4
+If not set (default=0), a combination of applications may create as many arenas as the number of CPU cores * 8.
-If not set (default=0), a combination of applications may create as many arenas as the number of cpu cores * 8.
+This setting reduced resident memory use by ~300 MB, and reduced virtual memory use by ~3.7 GB on an 8-core machine with 16GB RAM running Ubuntu 18. The trade-off for reducing resident memory use in this way is the added cost of the contention between threads for memory access among fewer arenas, but this was not perceptible during testing and profiling (the major bottlenecks in Bisq performance are related to Tor/P2P network I/O).
+There are many sources of information on this and other tunable memory allocation parameters, such as the Linux [http://man7.org/linux/man-pages/man3/mallopt.3.html mallopt] man page. Additional research and troubleshooting tips are welcome.
 [[Category:Troubleshooting]]

← Older revision		Revision as of 15:48, 30 April 2020
Line 14:		Line 14:

	There are many sources of information on this and other tunable memory allocation parameters, starting with the Linux [http://man7.org/linux/man-pages/man3/mallopt.3.html mallopt] man page; additional research and troubleshooting tips are welcome.		There are many sources of information on this and other tunable memory allocation parameters, starting with the Linux [http://man7.org/linux/man-pages/man3/mallopt.3.html mallopt] man page; additional research and troubleshooting tips are welcome.
		+
		+	[[Category:Troubleshooting]]

← Older revision		Revision as of 20:28, 5 April 2020
Line 10:		Line 10:


−	This setting reduced resident memory use by ~300 MB, and reduced virtual memory use by ~3.7 GB on an 8 core, 16 GB RAM machine running Ubuntu 18. The trade off for reducing resident memory use in this manner is the added cost of the contention ~~among~~ threads for memory access among fewer arenas, but this was not perceptible during testing and profiling.   (The major bottlenecks in Bisq performance are related to Tor/P2P network I/O.)	+	This setting reduced resident memory use by ~300 MB, and reduced virtual memory use by ~3.7 GB on an 8 core, 16 GB RAM machine running Ubuntu 18. The trade off for reducing resident memory use in this manner is the added cost of the contention between threads for memory access among fewer arenas, but this was not perceptible during testing and profiling.   (The major bottlenecks in Bisq performance are related to Tor/P2P network I/O.)


	There are many sources of information on this and other tunable memory allocation parameters, starting with the Linux [http://man7.org/linux/man-pages/man3/mallopt.3.html mallopt] man page; additional research and troubleshooting tips are welcome.		There are many sources of information on this and other tunable memory allocation parameters, starting with the Linux [http://man7.org/linux/man-pages/man3/mallopt.3.html mallopt] man page; additional research and troubleshooting tips are welcome.

@@ Line 1: / Line 1: @@
 == Java Threads and Linux Memory Arenas ==
-With the intention of improving efficiency of memory access in multi-threaded applications, [https://www.gnu.org/software/libc/manual/html_mono/libc.html glibc] may create more memory regions (known as [https://sourceware.org/glibc/wiki/MallocInternals#Arenas_and_Heaps arenas]) than necessary. &nbsp;&nbsp; In some cases, multi-threaded java applications allocating few and small objects in some threads can trigger creation of one arena for each of those threads, resulting in large growth of the java process' resident memory, no matter how well on-heap memory is managed by the application.
+With the intention of improving efficiency of memory access in multi-threaded applications, [https://www.gnu.org/software/libc/manual/html_mono/libc.html glibc] may create more memory regions (known as [https://sourceware.org/glibc/wiki/MallocInternals#Arenas_and_Heaps arenas]) than necessary. &nbsp;&nbsp; In some cases, multi-threaded java applications allocating few and small objects can trigger creation of one arena for each of those threads, resulting in large growth of the java process' resident memory, no matter how well on-heap memory is managed by the application.
 One way to limit arena creation in Bisq is to define the environment variable MALLOC_ARENA_MAX=4.

← Older revision		Revision as of 15:19, 5 April 2020
Line 1:		Line 1:
−	~~TODO~~	+	== Java Threads and Linux Memory Arenas ==
		+
		+	With the intention of improving efficiency of memory access in multi-threaded applications, [https://www.gnu.org/software/libc/manual/html_mono/libc.html glibc] may create more memory regions (known as [https://sourceware.org/glibc/wiki/MallocInternals#Arenas_and_Heaps arenas]) than necessary.    In some cases, multi-threaded java applications allocating few and small objects in some threads can trigger creation of one arena for each of those threads, resulting in large growth of the java process' resident memory, no matter how well on-heap memory is managed by the application.
		+
		+	One way to limit arena creation in Bisq is to define the environment variable MALLOC_ARENA_MAX=4.
		+
		+	export MALLOC_ARENA_MAX=4
		+
		+	If not set (default=0), a combination of applications may create as many arenas as the number of cpu cores * 8.
		+
		+
		+	This setting reduced resident memory use by ~300 MB, and reduced virtual memory use by ~3.7 GB on an 8 core, 16 GB RAM machine running Ubuntu 18. The trade off for reducing resident memory use in this manner is the added cost of the contention among threads for memory access among fewer arenas, but this was not perceptible during testing and profiling.   (The major bottlenecks in Bisq performance are related to Tor/P2P network I/O.)
		+
		+
		+	There are many sources of information on this and other tunable memory allocation parameters, starting with the Linux [http://man7.org/linux/man-pages/man3/mallopt.3.html mallopt] man page; additional research and troubleshooting tips are welcome.

← Older revision	Revision as of 21:39, 18 June 2020
(No difference)