Closed ttmx closed 12 months ago
4GB is like a 'worst case scenario', 1GB might be too little as I've (somehow) had OOM issues in the past when applying a certain combination of audio filters. A more suitable value might be 2GB, however there was probably a reason why 4GB was specified so I'll wait for someone else to chime in first.
Instead of removing the 4gb from the dockerfile entirely, why not make it configurable with an env var?
It already is configurable with an env var - _JAVA_OPTIONS
. This is done so the dockerfile doesn't override that.
Ideally we would set the environment variable to a default like 4G Then the user can easily override it without needing to overwrite the command like it is the case atm
After some further exploring, its possible that _JAVA_OPTIONS already overrides the command line arguments according to this stackoverflow https://stackoverflow.com/a/30305597
But it gives me no reference to documentation, so I am not certain.
people running Lavalink on a raspberry pi with less than 4GB ram have the issue, that they can't start the container unless they overwrite the -Xmx4G
.
I think it would be better to let java figure out what default heap size to use & whoever needs more than that can just overwrite the _JAVA_OPTIONS
environment variable
While testing, setting my Xmx to 512M instead of the default 4G, sent my ram usage from 800~M to 220~M. Feels like dividing the default ram usage by 4~ would be a thing worth pursuing.
Woohoo?
4Gb seems too high, and leads to the jvm under garbage collecting, meaning higher memory usage than necessary.
This is fixable by simply asking it to use less memory. This patch would make it so less people complain about memory usage. Maybe.