I have a developer who wrote several applications in Java spring boot and I have a VM configured with dynamic memory. His application stops working intermittently and he's pointing the finger at the fact that the VM is using dynamic memory even though there are no system or application logs indicating any shortage of memory within the VM guest. When I change the VM to hard provisioned memory his applications seem to behave differently where the amount of ram they are consuming is different than when the system is configured with dynamic memory. What I do not know yet is if after he starts his applications he is doing anything different from one configuration to another. They claim they are not but soon I should be able to verify this by running everything myself under the two different configurations. I suspect they're me be something with memory pressure and the balloon driver that his applications is not interacting correctly with but do not know how to determine this since there are no logs indicating an issue anywhere and the problem is intermittent when is programs just stop responding to web service calls from other applications. is there a simple way to determine if hyper-v dynamic memory is the culprit? Or if there is a different configuration that should be considered when specifying dynamic memory? The VM is configured to boot with 4GB and has a maximum of 12 GB. When all the applications are running it seems to never exceed 5.5GB in use with 6.3GB/11.3GB committed. The host is 2012 R2 and the guest VM is 2016.

  • Which JVM implementation and version? What are the JVM heap option used? About how much memory is it using at max, from something like wmic process where name="javaw.exe" get WorkingSetSize – John Mahowald Oct 13 at 14:03

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.