fragen stichworte

Speichercache ist zu hoch und Swap wird verwendet

Ich habe einen Centos-Server mit 32 g RAM und der Zustand davon ist (free -m):

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

die zwischengespeicherte Größe ist Wachstum (zwischen jeder Neustart-App und dem leeren Cache)

Nach 5 Stunden, in denen ich meine Frage poste, lautet der Speicherstatus:

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

meine Java-Optionen sind:

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

Wie Sie sehen, ist die Cachegröße zu hoch und in der hohen Ladezeit meines Servers wird der Swap verwendet und der Server ist zu langsam (im Gegensatz zu https://www.linuxatemyram.com/) , der Speicher ist voll und der Swap wird verwendet und meine App ist zu langsam)

Ich habe Java für den Service verwendet.

was kann ich tun?

antworten

Gründe, aus denen eine Java-Anwendung auf einem Server verlangsamt werden kann, sind nur durch unsere Vorstellungskraft (und manchmal auch durch Providence) begrenzt. Speichergierige Prozesse sind Teil von ihnen, die Ermüdung des Speichers impliziert das Auslagern und die Interaktion mit der Festplatte beeinträchtigt die Leistung.

In diesem Fall zeigt die Speichernutzung jedoch keine Anzeichen von Auslagerungen (siehe Kommentar von @Sven). Es ist plausibler eine Erklärung, die auf dem Verhalten der Anwendung basiert.

Java-Anwendungen sind (unter anderem) sehr empfindlich für die Speicherkonfiguration. Programmierer sind in Java (und in fast allen modernen Sprachen) sehr glücklich, da sie keine freien Funktionen aufrufen müssen, um Speicherverluste zu vermeiden, wie dies beim Garbage Collector der Fall ist. Der Garbage Collector kann jedoch die Anwendung einfrieren, wenn sie eintritt. Es gibt verschiedene Arten von Müllsammlungen. Diejenigen, die auf die neue Zone einwirken, sind weniger invasiv, die in der alten Zone sind schlechter und die volle GK sind die schlechtesten.

Im Allgemeinen (und natürlich in diesem Fall) wäre es notwendig, die Speicherentwicklung zu studieren, um seine Konfiguration zu optimieren. Wie auch immer, wir können einige Punkte sehen, auf die wir eingehen können:

  • Der der Anwendung zugewiesene Speicher beträgt 12 GB von 32 GB des gesamten Speicherplatzes des Servers.
  • Der für neue Objekte zugewiesene Speicherplatz beträgt 4 GB aus 12 GB. Wie Sie in den Heap-Tuning-Parametern sehen können, bedeutet dies ein NewRatio von 2, das den Best Practices entspricht. Eine Erhöhung dieses Wertes sollte jedoch in Betracht gezogen werden.

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

Die Verwendung anderer Ressourcen (Threads, Pools, Verbindungen usw.) sollte jedoch nicht abgelehnt werden.

Sie haben nicht erklärt, um wie viel Ihr System zu langsam ist und wo (interaktive Benutzer? Stapelverarbeitung?) und nur einen Leistungsindikator, Speicher identifiziert. Das wird dein Problem nicht finden. Seien Sie methodisch bei der Erfassung von Antwortzeiten und der Überwachung von Daten und untersuchen Sie, wie die Anwendung und das Betriebssystem funktionieren.

Ein guter Ausgangspunkt auf einer Linux-Box ist Linux Performance Analysis in 60.000 Millisekunden. CPU, Speicher, Netzwerk, Fehler und natürlich Speicher.

uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top

Sie können einen tiefen Einblick in eine Anwendung erhalten, indem Sie sie profilieren. Gib Java in Flames eine Lektüre (ist auch ein Netflix-Tech-Blog). Mit der Option -XX:+PreserveFramePointer können Java-Stacks mit dem OS-Profiling verknüpft werden.