How to deal with pauses of java applications without touching GC
How many times have I had to set up a GC to cure an application that has a seizure from time to time, and it stops temporarily performing its functions. Work, I will say, is not the most entertaining and requires a good knowledge of the hardware. In this topic, I will describe what else there are ways to solve this problem.
If your java Heap is more than a few gigs (depending on the requirements of the application), then no GC settings will help you. Whether it is a CMS, JRocket, or even a developed G1 for a hundred years, nothing will save you in this case. Although no, there is one product on the horizon: a virtual java machine from Azul. But this solution is again paid, requires proprietary hardware or virtualization, which again gives its overhead. Who cares, you can read a little more in the comments to my post GC tuning . What can a regular java developer do to cure an application that requires a significant amount of memory?
The first thing, of course, is to find out if there are memory leaks. Maybe they are so large or the memory is used so ineffectively that removing a leak will automatically solve your problems.
If you have the opportunity to restart your application periodically or there is a time interval when you can call Full GC. With a certain memory management pattern, when you can maintain the small size of the young generation and have a reasonable flow of objects falling into the old generation, you can increase the size of your Heap to such a value that the assemblies in the Old Gen will only happen during those moments it can afford. But this option is more like a hack than the mainstream.
')
Another very popular way to reduce GC pauses is to split your application into several parts that will run in different JVMs. Most of the time and go on this road. It really is a good decision if your system is loosely connected and logically well divided. But any distribution somehow complicates your architecture and slows down the interaction, so that it is not suitable for any application.
Also, as an option, you can consider a remote cache written on something bezhipipovom. For example, memcached. But here again, as in the previous solution, we get a distributed system and slow down the application, since now the objects will need to be serialized and transmitted through sockets. In the appendage we get a component written not on java, whose support for an ordinary java programmer can become difficult.
For a long time, the list of possible solutions practically came to an end, leaving java programmers in charge. But lately, a solution based on the so-called direct bufffer is beginning to emerge more often, when additional memory is allocated right inside the java process, but outside the heap, which allows you to have an application written entirely in java, it is easy to use memory in tens of gigabytes and avoid problems at distribution. Read more about this approach in the Java Off-Heap Cache article.
Also participate in the survey on this topic .
If your java Heap is more than a few gigs (depending on the requirements of the application), then no GC settings will help you. Whether it is a CMS, JRocket, or even a developed G1 for a hundred years, nothing will save you in this case. Although no, there is one product on the horizon: a virtual java machine from Azul. But this solution is again paid, requires proprietary hardware or virtualization, which again gives its overhead. Who cares, you can read a little more in the comments to my post GC tuning . What can a regular java developer do to cure an application that requires a significant amount of memory?
The first thing, of course, is to find out if there are memory leaks. Maybe they are so large or the memory is used so ineffectively that removing a leak will automatically solve your problems.
If you have the opportunity to restart your application periodically or there is a time interval when you can call Full GC. With a certain memory management pattern, when you can maintain the small size of the young generation and have a reasonable flow of objects falling into the old generation, you can increase the size of your Heap to such a value that the assemblies in the Old Gen will only happen during those moments it can afford. But this option is more like a hack than the mainstream.
')
Another very popular way to reduce GC pauses is to split your application into several parts that will run in different JVMs. Most of the time and go on this road. It really is a good decision if your system is loosely connected and logically well divided. But any distribution somehow complicates your architecture and slows down the interaction, so that it is not suitable for any application.
Also, as an option, you can consider a remote cache written on something bezhipipovom. For example, memcached. But here again, as in the previous solution, we get a distributed system and slow down the application, since now the objects will need to be serialized and transmitted through sockets. In the appendage we get a component written not on java, whose support for an ordinary java programmer can become difficult.
For a long time, the list of possible solutions practically came to an end, leaving java programmers in charge. But lately, a solution based on the so-called direct bufffer is beginning to emerge more often, when additional memory is allocated right inside the java process, but outside the heap, which allows you to have an application written entirely in java, it is easy to use memory in tens of gigabytes and avoid problems at distribution. Read more about this approach in the Java Off-Heap Cache article.
Also participate in the survey on this topic .
Source: https://habr.com/ru/post/131017/
All Articles