Hello everyone,
I'm encountering a persistent issue trying to run MongoDB in a Docker container on my FriendlyELEC CM3588 board, which is running the official Ubuntu 24.04 (Noble Numbat) image with kernel 6.1.y.
The Problem:
When I try to bring up the MongoDB container using docker compose up, it repeatedly crashes shortly after starting. The logs consistently show out-of-memory errors related to tcmalloc and MmapAligned() failing to allocate large memory blocks. Here are the key error messages:
mongodb | MmapAligned() failed - unable to allocate with tag (hint=..., size=1073741824, alignment=1073741824) - is something limiting address placement?
mongodb | CHECK in Alloc: FATAL ERROR: Out of memory trying to allocate internal tcmalloc data (bytes=131072, object-size=640); is something preventing mmap from succeeding (sandbox, VSS limitations)?
mongodb exited with code 134
What I've Tried So Far (Unsuccessful):
1. Disabling Transparent Huge Pages (THP): I've added --no-transparent-huge-pages to the mongod command in my docker-compose.yml.
2. Increasing vm.max_map_count: I've set vm.max_map_count to 262144 (the recommended value for MongoDB) persistently via /etc/sysctl.d/99-mongodb.conf.
3. Clean Docker Volume: Each attempt involves removing the Docker volume (pi_mongodb_data) to ensure a fresh start.
4. Different MongoDB Versions: I've tried both mongo:latest and mongo:6.0 images.
Context:
Interestingly, when I was previously running Armbian on this same CM3588, MongoDB in Docker worked without these memory allocation issues, although the overall system performance was slower. This suggests that the problem might be specific to the memory management or kernel configuration of the FriendlyELEC Ubuntu 24.04 image.
I'm looking for insights or suggestions from anyone who might have encountered similar issues with MongoDB or other memory-intensive applications on this specific Ubuntu image or RK3588-based devices. Could there be other kernel parameters or specific optimizations needed for this board/OS combination?
Regards,
Alex
I'm encountering a persistent issue trying to run MongoDB in a Docker container on my FriendlyELEC CM3588 board, which is running the official Ubuntu 24.04 (Noble Numbat) image with kernel 6.1.y.
The Problem:
When I try to bring up the MongoDB container using docker compose up, it repeatedly crashes shortly after starting. The logs consistently show out-of-memory errors related to tcmalloc and MmapAligned() failing to allocate large memory blocks. Here are the key error messages:
mongodb | MmapAligned() failed - unable to allocate with tag (hint=..., size=1073741824, alignment=1073741824) - is something limiting address placement?
mongodb | CHECK in Alloc: FATAL ERROR: Out of memory trying to allocate internal tcmalloc data (bytes=131072, object-size=640); is something preventing mmap from succeeding (sandbox, VSS limitations)?
mongodb exited with code 134
What I've Tried So Far (Unsuccessful):
1. Disabling Transparent Huge Pages (THP): I've added --no-transparent-huge-pages to the mongod command in my docker-compose.yml.
2. Increasing vm.max_map_count: I've set vm.max_map_count to 262144 (the recommended value for MongoDB) persistently via /etc/sysctl.d/99-mongodb.conf.
3. Clean Docker Volume: Each attempt involves removing the Docker volume (pi_mongodb_data) to ensure a fresh start.
4. Different MongoDB Versions: I've tried both mongo:latest and mongo:6.0 images.
Context:
Interestingly, when I was previously running Armbian on this same CM3588, MongoDB in Docker worked without these memory allocation issues, although the overall system performance was slower. This suggests that the problem might be specific to the memory management or kernel configuration of the FriendlyELEC Ubuntu 24.04 image.
I'm looking for insights or suggestions from anyone who might have encountered similar issues with MongoDB or other memory-intensive applications on this specific Ubuntu image or RK3588-based devices. Could there be other kernel parameters or specific optimizations needed for this board/OS combination?
Regards,
Alex