Reputation: 21
I have a server that only runs some processes that have no access to the user. Therefore, the throughput does not matter. Most of the time, the server only runs some small jobs so the it mainly does the minor gc for most of the time. Once in a while, a big job comes in so it will require a major gc to make room for the process. I have seen the the case like never done a major gc for few days.
My problem is when the major gc runs, it will pause, and it triggers the health check alert. we tried to lower the heap size and the problem went away because the major happened more. However, it runs out of memory when a big job comes. We do not want to increase the timeout of the health check so that we want to tune the gc to have the major gc happens more often even with the larger heap size instead of waiting when it is needed. I am planning to change to use -XX:+UseConcMarkSweepGC
to make it pause lower impact. Any other JVM options I should try too?
Upvotes: 2
Views: 2588
Reputation: 1856
Your setup is wrong. You said: Throughput doesnt matter, because no users connect to it. This is wrong. When users connect, responsiveness matters. When they don't, throughput matters. Also you assumption regarding "no access to user" is wrong. You have a user, the healthchecker, and that one wants access.
What i would recommend for batch jobs is to keep the Throughput-optimized GC settings and live with longer major GCs. Perhaps the Healthchecker has better means to check your service, and can be made robust so that it will not fall over a GC?
Upvotes: 0
Reputation: 22656
We had issues like this when using the -XX:+UseParallelGC
option but found that this was because the ratio was far too much in favour of old. This meant that we had a large old generation and a too small new generation. Objects wouldn't stay in new for long enough to be removed and so the old would slowly fill up causing a large collect.
Setting the new ratio to be higher helped us out ( -XX:NewRatio=2
). I can't remember the value we used but think it was 2 or 3 - play around with this.
This sets a larger young generation so short lived objects get a chance to be removed before being forced into the old generation.
Upvotes: 1
Reputation: 14549
When the "big job" comes right in place with some other jobs then even more aggressive gc will trigger your health check, too. What I want to say is that regardless how you free up memory this is a timing problem and you can run into it even when cleaning everything up immediately after the last reference is released. So I would say your health check is configured too sensitive.
Nevertheless you can try to call System.gc()
when you're idle and your job-queue is empty. But do not treat that as a recommendation. This is most likely to hurt performance rather than improving it.
Upvotes: 0