How to properly estimate arguments for java-buildpack-memory-calculator? about java-buildpack-memory-calculator HOT 1 CLOSED

This should probably be improved in the docs a bit, but the answer is you start up your application and look 😄.

For loadedClasses you’re trying to document the number of classes that your application will load into memory at runtime. We’ve done some analysis of existing applications out in the world and worked out that applications generally load fewer than 35% of the classes they have access to. We do an analysis of all of the JARs that will be on an application’s classpath and calculate a value for that, so I don’t think that most people will need to ever change this. If you find that your application is loading vastly more or less than that amount I’d make a change, but given how little effect changing that number has on the metaspace (70M + (5K * loaded classes)) it’s probably a non-issue. In fact, our analysis shows that for a given application, the metaspace is fixed, regardless of the rest of the memory regions, so if you think you don’t have enough (or have too much) metaspace, you should just set it directly via -XX:MaxMetaspaceSize; you don’t have to worry that changing a container size will lead to unused memory the way you would if you set heap size directly.

stackThreads is documentation of the maximum number of threads that your application will use at any time. Our 300 value is based on the fact that most applications on Cloud Foundry run Tomcat which is configured to max out at 200 threads by default. Add to that another ~25 for system threads and GC, we then leave 75 threads for things like connection pools, application thread pools, etc. If you’ve configured your container to use fewer threads (or more threads), if you know that you don’t have any connection pools or other application thread pools, then you can safely change this value. I view this, in combination with -Xss to be the least risky way to make your container memory needs smaller. Given that with default configuration, each thread has 1M of memory space, shrinking the number of threads your application uses by 100 reduces your requirements 100M. Changing your stack size (if you can safely do so) by half you reduce your usage 150M. Given that almost all of the other memory configurations are essentially tinkering around the edges or are very dangerous to change (e.g. -XX:ReservedCodeCache), this is the best bang for your buck.

Please note that for both of these values, you must run your application to max load to accurately document the values. It’s no good for you to start your application, see Tomcat using 5 threads and update your configuration based on that. The memory calculator must calculate the maximum amount of memory your application could ever use in order to ensure that the container won’t exceed its memory limit and be recycled.

from java-buildpack-memory-calculator.