Linux – memory cache is too high and going to use swap

cachecentosjavalinuxmemory

i have a centos server with 32 g RAM
and the state of it, is (free -m):

              total       used       free     shared    buffers     cached
 Mem:         32071      31488        583          0        244      19329
 -/+ buffers/cache:      11914      20157
 Swap:        17399        287      17112

the cached size is growth
(between every restart app and clear cache)

after 5 hours that i post my question the memory status is :

             total       used       free     shared    buffers     cached
Mem:         32071      31850        221          0        194      20124
-/+ buffers/cache:      11530      20541
Swap:        17399        299      17100

my java options is :

-Xms12g -Xmx12g -XX:MaxNewSize=6g -XX:NewSize=6g -XX:+UseParallelOldGC -XX:+UseParallelGC -XX:+UseTLAB -XX:MaxTenuringThreshold=15 -XX:+DisableExplicitGC

as you see, cache size is too high and in the high load time on my server, the swap is used and the server is too slow (Unlike https://www.linuxatemyram.com/ , the memory is full and swap is used and my app is too slow)

i used java for service.

what can i do?

Best Answer

Reasons by which a Java application in a server can be slowed are only limited by our imagination (and sometimes by Providence). Memory greedy processes are part of them, the memory exhaustion they cause implies swapping and the interaction with disk kills the performance.

However, in this case, the memory usage does not show symptoms of swapping (see comment of @Sven). It is more plaussible an explication based on the behaviour of the application.

Java applications are very sensitive (among other things) to memory configuration. Programmers are very happy in Java (and in almost all of modern languages) because they do not have to call free functions to avoid memory leaks, as that is done by the Garbage Collector. However, the Garbage Collector can freeze the application when it enters. There are various types of garbage collections. The ones acting on the new zone are less invasive, those in the old zone are worse and full gc are the worst.

In general (and of course in this case) it would be necessary to study the memory evolution in order to optimize its configuration. Anyway, we can see some points upon which to reflect:

  • The memory assigned to the application is 12 GB out of 32 GB of the total space of the server.
  • The space assigned to new objects is 4 GB out of 12 GB. As you can see in Heap Tuning Parameters, It means a NewRatio of 2, conform to best practices. Anyway, inncreasing this value should be considered.

The NewSize and MaxNewSize parameters control the new generation’s minimum and maximum size. Regulate the new generation size by setting these parameters equal. The bigger the younger generation, the less often minor collections occur. The size of the young generation relative to the old generation is controlled by NewRatio. For example, setting -XX:NewRatio=3 means that the ratio between the old and young generation is 1:3, the combined size of eden and the survivor spaces will be fourth of the heap.

By default, the Application Server is invoked with the Java HotSpot Server JVM. The default NewRatio for the Server JVM is 2: the old generation occupies 2/3 of the heap while the new generation occupies 1/3. The larger new generation can accommodate many more short-lived objects, decreasing the need for slow major collections. The old generation is still sufficiently large enough to hold many long-lived objects

Anyway, the use of other resources (threads, pools, connections, etc.) should not be dismissed.

Related Topic