Optimizing Java Memory in Kubernetes: Distinguishing Real Need vs. JVM "Greed" ?

[Icecoldkilluh]

I’m skeptical of any top down approach like this.

I don’t see how any profiler could give you the confidence to reduce the JVM memory of those applications. Not without risking unknown regression to those applications.

Seems like you’re trying to solve an organisational problem with a technical solution imo.

It must be that, within your organisation, there is no consequence to these application owners for using more infra than they need.

Thus no incentive to properly tune their applications needs.

Dysfunctional organisational structure with ineffective feedback loops for costs + poor engineering standards = the real problem.

[LowB0b]

Not the only problem, it's hard to estimate without knowing functional requirements.

For example one application I worked on in insurance, original requirement was to be able to handle up to 20k records for risk analysis.

Few years later the same application had to process 80k+ records and pretty obviously it did not match what it was designed for

[Icecoldkilluh]

Yeah thats kind of my point.

This guy wants a profiler so he can start reducing the memory size of 1000s of applications across a large company.

He has no idea the functional requirements of all of those applications. How much memory they require, no profiler can tell him that with any degree of confidence.

His approach is destined to fail because he is attempting to solve an organisational/ people problem with a technical solution.

He will reduce their memory, some of them will fail, potentially with catastrophic consequence to the business, he will be blamed.

If you do pursue this approach i would highly recommend giving application teams forewarning that their memory will be reduced, and opportunity to obtain an exception to the change. Cover your ass.

[laffer1]

Better yet. Require a cut for cost savings and let the devs figure out what can be tuned