-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(Possibly) Incorrect initial max memory size when building a direct memory buffer pool #2201
Comments
kofemann
added a commit
to dCache/dcache
that referenced
this issue
Mar 7, 2024
Motivation: Grizzly memory management uses heap memory size fraction even if direct memory is used. eclipse-ee4j/grizzly#2201 Moreover, for each memory slice (a memory segment per thread) allocates at least x16 chunks, which ends up at 16MB per slice (with 1MB chunk) Modification: as dCache needs `2 * #Cores * maxIObuf` memory, pre-calculate the required amount of direct memory and the corresponding fraction in relation to heap. Initialise the memory pool with 1/16 of the desired slice size to compensate memory allocator internal x16 increase. Result: dCache starts with 256m of direct memory (we still have xroot mover) Fixes: #7522 Acked-by: Svenja Meyer Acked-by: Lea Morschel Target: master, 9.2 Require-book: no Require-notes: yes
kofemann
added a commit
to kofemann/dcache
that referenced
this issue
Mar 7, 2024
Motivation: Grizzly memory management uses heap memory size fraction even if direct memory is used. eclipse-ee4j/grizzly#2201 Moreover, for each memory slice (a memory segment per thread) allocates at least x16 chunks, which ends up at 16MB per slice (with 1MB chunk) Modification: as dCache needs `2 * #Cores * maxIObuf` memory, pre-calculate the required amount of direct memory and the corresponding fraction in relation to heap. Initialise the memory pool with 1/16 of the desired slice size to compensate memory allocator internal x16 increase. Result: dCache starts with 256m of direct memory (we still have xroot mover) Fixes: dCache#7522 Acked-by: Svenja Meyer Acked-by: Lea Morschel Target: master, 9.2 Require-book: no Require-notes: yes (cherry picked from commit 8f3b984) Signed-off-by: Tigran Mkrtchyan <[email protected]>
mksahakyan
pushed a commit
to dCache/dcache
that referenced
this issue
Mar 11, 2024
Motivation: Grizzly memory management uses heap memory size fraction even if direct memory is used. eclipse-ee4j/grizzly#2201 Moreover, for each memory slice (a memory segment per thread) allocates at least x16 chunks, which ends up at 16MB per slice (with 1MB chunk) Modification: as dCache needs `2 * #Cores * maxIObuf` memory, pre-calculate the required amount of direct memory and the corresponding fraction in relation to heap. Initialise the memory pool with 1/16 of the desired slice size to compensate memory allocator internal x16 increase. Result: dCache starts with 256m of direct memory (we still have xroot mover) Fixes: #7522 Acked-by: Svenja Meyer Acked-by: Lea Morschel Target: master, 9.2 Require-book: no Require-notes: yes (cherry picked from commit 8f3b984) Signed-off-by: Tigran Mkrtchyan <[email protected]>
kofemann
added a commit
to kofemann/dcache
that referenced
this issue
Apr 4, 2024
Motivation: Grizzly memory management uses heap memory size fraction even if direct memory is used. eclipse-ee4j/grizzly#2201 Moreover, for each memory slice (a memory segment per thread) allocates at least x16 chunks, which ends up at 16MB per slice (with 1MB chunk) Modification: as dCache needs `2 * #Cores * maxIObuf` memory, pre-calculate the required amount of direct memory and the corresponding fraction in relation to heap. Initialise the memory pool with 1/16 of the desired slice size to compensate memory allocator internal x16 increase. Result: dCache starts with 256m of direct memory (we still have xroot mover) Fixes: dCache#7522 Acked-by: Svenja Meyer Acked-by: Lea Morschel Target: master, 9.2 Require-book: no Require-notes: yes
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When creating a buffer pool using
PooledMemoryManager
, then DEFAULT_HEAP_USAGE_PERCENTAGE (3%) of the heap is used to calculate the max pool size per slice:https://github.com/eclipse-ee4j/grizzly/blob/master/modules/grizzly/src/main/java/org/glassfish/grizzly/memory/PooledMemoryManager.java#L170C1-L171C89
However, this calculation is not correct when direct buffers are created, as the amount of direct memory is not reported by
Runtime.getRuntime().maxMemory()
. Thus, on machines with large heap, but a small direct memory, the initialization fails with OOM. This simple code:fails with:
I assume that with max direct memory 128MB, creating a single slice with 4x 512KB chunks should be possible.
I think, for direct buffers instead of
heapSize
max direct memory size should be used, something like:The text was updated successfully, but these errors were encountered: