web-dev-qa-db-fra.com

Pourquoi y a-t-il une dégradation des performances après ~ 6 heures de travail Java 9 G1 sans augmentation réelle de la charge?

J'ai basculé 1 instance (2 vCPU, 2 Go de RAM, charge ~ 4k req/sec) vers Java 9 (de la dernière Java 8). Pendant un certain temps, tout allait bien et l'utilisation du processeur était la même qu'auparavant. Cependant, après environ 6 heures, la consommation du processeur a augmenté de 4% (de 21% à 25%) sans raison. Je n'ai pas eu de pics de trafic, pas de consommation de mémoire, pas de changement de métrique J'ai des compteurs pour chaque méthode dans le code. Rien.

J'ai laissé cette instance intacte pendant environ 12 heures en m'attendant à ce qu'elle revienne. Mais rien n'a changé. Il a juste commencé à consommer plus de CPU.

La commande top a montré que l'instance avait plus de pics CPU que d'habitude pour le processus serveur Java. J'ai lu récemment que G1 ne convient pas pour le haut débit. J'ai donc fait une conclusion cette raison pourrait être dans G1.

J'ai redémarré l'instance avec:

Java -XX:+UseParallelGC -jar server-0.28.0.jar

Et après ~ 20 heures de surveillance, tout va bien comme avant. La consommation du processeur est au niveau de 21% comme c'était le cas plusieurs jours auparavant.

Utilisation du processeur juste après Java 9 (échelle 6h):

enter image description here

Augmentation du CPU après 7 heures + 12 heures "intact" (échelle 7d):

enter image description here

CPU après -XX:+UseParallelGC (Échelle 24h):

enter image description here

Ma question est donc - est-ce le comportement attendu pour le G1? Quelqu'un d'autre voit quelque chose de similaire?

Ubuntu 16.04 x64

Java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)

EDIT 03.01.2019

J'ai essayé d'exécuter un même serveur avec G1 sur le Java 10.0.2:

Java version "10.0.2" 2018-07-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)

G1 consomme 40% plus de CPU que UseParallelGC juste après le redémarrage du serveur.

javaperformancegarbage-collectionjava-9g1gc
48
Dmitriy Dumanskiy

(Notez que le réglage GC dépend extrêmement de l'environnement, il n'y a donc pas de recette magique.)

Eu un problème très similaire avec G1. Par défaut, il semble être assez mal adapté aux points de terminaison REST (encore une fois, ce n'est que ce que j'ai vécu dans mon voisinage direct). Ce qui m'a aidé à expérimenter avec les drapeaux GC, comme décrit - ici .

Pour nous, les plus grandes améliorations sont venues de -XX: G1NewSizePercent = 25 et -XX: MaxGCPauseMillis = 50. G1 se règle également automatiquement au fil du temps, de sorte que la valeur max. La limite de pause du GC a un effet significatif sur tous les autres paramètres.

2
Agoston Horvath