Help Server garbage collection frequency

[Horse]

Hi.

 

I 'd like to know if there's an optimal garbage collection frequency for l2 servers?

 

What I mean is the following: While there are only 2-3 players on the server (being in testing phase ofc) it takes about 1,5-2 hours for the used memory to increase by 500mb. Once GC cleans up, it seems to reclaim all previously used memory, which I assume it means there's little to no memory leak. (Correct me if im wrong, ty).

 

Testing many aspects of the game, instances, events, or other custom features I've added/created, I found no serious spikes in memory usage.

 

Except for one thing: I made a custom stats command which pops-up a html window with various stats including str,dex, etc, p.atk, cast, and other stats that are not displayed on the character tab, such as pvp defense, etc. Technically it calls a lot of the character information at once.

 

When I keep spamming this command the memory usage rises very fast, since it refreshes these infos again and again. Naturally GC triggers and reclaims the memory all the same.

 

So my question is: Does it actually matters how often GC runs, or it doesn't really matter as long as it reclaims all the used memory?

[Kara]

Garbage collector does not have a specific moment that runs. Don't see GC like threadpool that runs every 1 hour. 

If you see many ram drops and spikes maybe the codes badly coded or there is a problem with your PC. If there is a code leak for an instance let's take  a while or a for(;;) that runs forever and create objects the ram might increase forever.

[Tryskell]

It matters, depending which sort of GC you are using (and JDK version) ; classic GC generates a "STW" effect, which basically translates to a freeze impacting your whole server. That freeze is a real burden, since it stops all actions, everytime the GC is running.

 

It can be beaten using another type of GC (for Java8, the most successful - for me - is CMS, G1GC being experimental). Since Java9, G1GC is now the actual GC, and has been improved. So if you're on a Java9 project, you won't know the STW effect.

 

How to minimize frequency of GC calls ? The easiest is to avoid to generate new objects - either by reusing existing ones (via a pool, which recycles old objects to give them a new life) or to avoid to regenerate ones when the output can/should found over and over (via a cache). Also, the accumulation of good practices (use int and avoid Integer, correctly handle for/loop content, lazy initialization, String manipulation) avoid to use expensive operations/variables, which save you objects in the end.

 

Ofc, it has to reclaim all the "dynamic" memory at a point (a lot of variables/classes are static and are never unloaded - for example all cached data basically, like cached xml/sql - and it's perfectly normal). If not, it means it will simply store more and more... Which means you got a memory leak, because you are physically limited with memory (and JVM size). Such scenario generally happens when at least one link to the object to delete is kept - meaning the object isn't collectable.

 

It is always "ok" to minimize the GC calls, since it uses ressources of your hardware to complete it.

 

All in one, you have to go through GC, a time or another. It's normal. The point is to avoid to get abusive amount of GC calls.

Edited October 9, 2018 by Tryskell

[Horse]

13 hours ago, Kara` said:

Garbage collector does not have a specific moment that runs. Don't see GC like threadpool that runs every 1 hour. 

If you see many ram drops and spikes maybe the codes badly coded or there is a problem with your PC. If there is a code leak for an instance let's take  a while or a for(;;) that runs forever and create objects the ram might increase forever.

 

Yes, I do understand that it doesn't have a "specific" moment when it runs. What I was curious about was if there is a optimal running period. Like every hour or so, or every 30 minutes, and so on.

 

As for the huge ram usage of my stats window, it was due the tons of replacements in the html window. It generated way too many html objects I assume. So I moved the html code to the handler and it seems to be fine now, no more crazy ram spikes.

 

12 hours ago, Tryskell said:

It matters, depending which sort of GC you are using (and JDK version) ; classic GC generates a "STW" effect, which basically translates to a freeze impacting your whole server. That freeze is a real burden, since it stops all actions, everytime the GC is running.

 

It can be beaten using another type of GC (for Java8, the most successful - for me - is CMS, G1GC being experimental). Since Java9, G1GC is now the actual GC, and has been improved. So if you're on a Java9 project, you won't know the STW effect.

 

How to minimize frequency of GC calls ? The easiest is to avoid to generate new objects - either by reusing existing ones (via a pool, which recycles old objects to give them a new life) or to avoid to regenerate ones when the output can/should found over and over (via a cache). Also, the accumulation of good practices (use int and avoid Integer, correctly handle for/loop content, lazy initialization, String manipulation) avoid to use expensive operations/variables, which save you objects in the end.

 

Ofc, it has to reclaim all the "dynamic" memory at a point (a lot of variables/classes are static and are never unloaded - for example all cached data basically, like cached xml/sql - and it's perfectly normal). If not, it means it will simply store more and more... Which means you got a memory leak, because you are physically limited with memory (and JVM size). Such scenario generally happens when at least one link to the object to delete is kept - meaning the object isn't collectable.

 

It is always "ok" to minimize the GC calls, since it uses ressources of your hardware to complete it.

 

All in one, you have to go through GC, a time or another. It's normal. The point is to avoid to get abusive amount of GC calls.

Thanks a lot for the quick explanation. Too many objects generated was the problem indeed.

 

 

Thank you both, topic can be locked.