Updated KNOWN_ISSUES with example of using _JAVA_OPTIONS

Signed-off-by: Matt Bentley <mbentley@mbentley.net>

Author: mbentley

KNOWN_ISSUES.md

@@ -48,7 +48,12 @@ The `armv7l` architecture is 32 bit and MongoDB is no longer available as a pre-
 
 ### Low Resource Systems
 
-Systems such as Raspberry Pis may not have sufficient memory to run with the default memory settings of this image. If you system only has 1 GB of RAM, I would highly recommend adjusting the Xmx arguments by overriding the `CMD` [as seen in this issue here](https://github.com/mbentley/docker-omada-controller/issues/198#issuecomment-1100485810) to prevent the container from being OOM killed by the OS.
+Systems such as Raspberry Pis may not have sufficient memory to run with the default memory settings of this image. If you system only has 1 GB of RAM, I would highly recommend adjusting the Xmx arguments. This can be done by one of two ways:
+
+1. Setting the `_JAVA_OPTIONS` environment variable; for example, `_JAVA_OPTIONS="-Xms512m -Xmx2048m"`.  This will not modify the parameter so tools like `ps` will still show the original value but this variable takes priority over the CLI args.
+1. Overriding the `CMD` [as seen in this issue here](https://github.com/mbentley/docker-omada-controller/issues/198#issuecomment-1100485810).
+
+Changing these values would be necessary on these low resource systems to prevent the operating system from killing the container due to it thinking it can allocate more memory than it should. The controller process may still actually functionally require more memory so your mileage may vary in terms of the impact of running on such a low resource system.
 
 ### Mismatched Userland and Kernel
 
@@ -109,4 +114,4 @@ For a clean install where you do not have proper CPU support, you can run MongoD
 
 When upgrading the controller to v6, you need to upgrade MongoDB from v3 to v8. Details about the migration process can be found in [mongodb_upgrade](./mongodb_upgrade#about-the-upgrade-process) but if you're here, it's probably because one of these two checks for AVX (amd64) or armv8.2-a (arm64) have failed when you attempted to upgrade, meaning that your CPU is not supported. The quick way to get your controller back up and running is to move back to the v5 image as a failed upgrade will not have modified any of your data and you can start your v5 controller container back up and be running just fine.
 
-Longer term, you may want to upgrade to v6 but you still can't just upgrade because you're stuck with a CPU that doesn't have the required capabilities to support a modern MongoDB. This can be achieved by running MongoDB external to the Omada Controller application. If you're ready to try to migrate from the all in one deployment to separate MongoDB and Omada Controller containers, check out the [Migration from All in One](./external_mongodb#migration-from-all-in-one) instructions. As always, make sure that you take a backup before you do anything like this as I am sure you do before all upgrades, right?
+Longer term, you may want to upgrade to v6 but you still can't just upgrade because you're stuck with a CPU that doesn't have the required capabilities to support a modern MongoDB. This can be achieved by running MongoDB external to the Omada Controller application. If you're ready to try to migrate from the all in one deployment to separate MongoDB and Omada Controller containers, check out the [Migration from All in One](./external_mongodb#migration-from-all-in-one) instructions. As always, make sure that you take a backup before you do anything like this as I am sure you do before all upgrades, right?