DS916+ runs out of memory

[tb123]

I have a DS916+ with 8GB of RAM in it. I’ve had it for 3-4 years and upgraded it to DSM7 a few months ago.

I run 1 x Docker container on it with UniFi Controller (the latest version 6.4.54).

I don’t know exactly when this issue started happening (upgrade to DSM7 or upgrade to UniFi Controller, something else) but recently got a notification that some processes failed to run as the system was out of memory. When I looked at the resource monitor the RAM was around 75% in use (It’s normally around 25ish %). I restarted the NAS and the memory usage went back to normal, checked it a week later and it’s back up to 75%. i restarted the Docker Container and it immediately dropped back to 23% again.

The memory usage graph looks like a saw tooth, builds over a week or so, then drops when I restart the container, then builds again over time.

anyone seen anything like this recently?

 

[fredbert]

Sounds like a memory leak or something taking unused RAM like Synology Drive can to 'optimise performance'.

 

[Rusty]

The memory usage graph looks like a saw tooth, builds over a week or so, then drops when I restart the container, then builds again over time.

Once way to solve this and see if that container is really the problem is to limit RAM for that container. I have that for multiple containers just to prevent these memory leaks.

 

[one-eyed-king]

What Rusty said

Some applications (regardless whether they run in a container or native on the host) use unused ram for caching. Without resource constraints, all containized and native process on the host fight for ressources...

 

[tb123]

Once way to solve this and see if that container is really the problem is to limit RAM for that container. I have that for multiple containers just to prevent these memory leaks.

Yes, I limited the container to 2GB of RAM and now the system is sitting at around 47% RAM usage overall, so it definitely seems to be this container.

I’m not overly familiar with Docker, does the application run within the container, or is the application the actual container? Still trying to figure out if it’s the UniFi app that’s the problem or the container (I guess Im thinking like the container is the OS and the app runs inside that?) Or in other words, is this a UniFi issue that needs to be fixed, or something on the Docker side of things.

 

[one-eyed-king]

A container basicly is a fenced process. The fence part is composed of cgroups (=what cpu/ram/io ressources is the process allowed to see and use), namespaces (=logical partitions of kernel components) and capabilites (=permissions on low level kernel level functions).

The isolation (=the fence) itself is not responsible for what you experience. The process run inside the container is! The behavior you experience, is not releated to the process beeing run nativly or in a container. The behavior is caused by whatever the application does.

-- post merged: 21. Oct 2021 --

(I guess Im thinking like the container is the OS and the app runs inside that?)

A container does not boot and is not an OS in sense of an OS - the "OS" is merely a loose set of binaries, librares and config files that make up an OS, used to encapsulate the application and the dependencies it requires.

A container specificly ony runs whatever the author of the image designed it to start - which is whoever made the UniFi image. Typicaly the entrypoint script of a container, does some preparation task and then starts the process of the main application.

 

[tb123]

Thanks for the explanation - that actually made sense!