Les options de démarrage Java Spigot (Bukkit) n'ont pas besoin d'être réglées autant

Comme le dit le titre. C'est une histoire quand j'ai fait diverses options de démarrage Java lors de l'exécution de Spigot avec VPS.

Les options de démarrage sont généralement OK selon le Wiki officiel

Le script de démarrage se trouve dans Spigot Installation. La version Linux est citée ci-dessous à titre d'exemple.

start.sh


#!/bin/sh
java -Xms1G -Xmx1G -XX:+UseConcMarkSweepGC -jar spigot.jar

La taille d'allocation initiale de 1 Go de pool de mémoire correspond à -Xms1G et la taille d'allocation maximale de 1 Go correspond à -Xmx1G. Cependant, ce n'est que ** dans un environnement avec suffisamment de mémoire **.

Exécution dans un environnement avec une mémoire limitée

Si vous déployez une boîte de classe de 1 Go avec VPS, etc., la mémoire sera aspirée dans le système de plusieurs centaines de Mo. Dans l'état actuel des choses, Spigot peut ne pas fonctionner avec le script de démarrage ci-dessus, donc allouez naturellement de la mémoire virtuelle et permutez la mémoire dans Windows. (* Cette section suppose un système d'exploitation basé sur Linux.) Au début, ** 4 Go suffisent, et si nécessaire, vous pouvez l'ajouter plus tard **. Avec VPS, la capacité du disque est limitée, donc je pense que cette zone est sûre. ~~ Cependant, Build Tools peut ne pas fonctionner avec ʻOutOfMemoryError`. Puisque mon environnement l'était, je l'ai construit localement avec obéissance. ~~

Je l'ai résolu en allouant de la mémoire à Maven + α.

build.sh


#!/bin/sh
export MAVEN_OPTS="-Xmx2G -XX:+UseG1GC"
java -Xmx2G -XX:+UseG1GC -jar BuildTools.jar

Juste moins efficace

Si la taille d'allocation initiale du pool de mémoire est de 1 Go, la mémoire d'échange sera utilisée. Comme je l'ai écrit ci-dessus, je pense que le système utilisera environ plusieurs centaines de Mo et le reste sera d'environ 700 Mo environ. Si la taille d'allocation initiale est de 1 Go avec les 700 Mo restants, environ 300 Mo de mémoire d'échange seront utilisés.

Utiliser la mémoire d'échange signifie lire et écrire sur le disque. S'il y a un retard dans l'écriture, cela peut entraîner un retard ou un retour en arrière.

Si possible, supprimez l'option d'allocation initiale -Xms *, ou jetez un œil à la moitié du -Xms512M et à l'allocation initiale à environ 512 Mo.

À propos, la lecture et l'écriture du disque ont été supprimées dans mon environnement. vps_4_1.png

Est-il possible de désactiver (effacer) ou de réduire -Xms *, mais ce n'est pas un problème. ** Si vous allouez d'abord de la mémoire, elle sera plus rapide lorsque vous l'utiliserez (lorsque vous créez une instance, etc. dans le programme) ** Ce n'est pas une option obligatoire. Si vous avez suffisamment de mémoire, il n'y a aucune raison de l'éteindre.

Le garbage collection peut-il rester CMS?

Une explication rapide du garbage collection est de libérer la mémoire qui n'est plus nécessaire. C'est un endroit pour nettoyer la mémoire.

référence:

Ainsi, ** CMS ** est une abréviation de ** Concurrent Mark Sweep ** et est l'un des algorithmes de garbage collection. C'est aussi une méthode de nettoyage. Nous libérerons la mémoire par une méthode de nettoyage appelée CMS.

Au fait, le script de démarrage écrit ci-dessus a -XX: + UseConcMarkSweepGC comme option pour utiliser ce CMS.

Il semblait qu'il n'y avait pas de problème avec CMS en particulier, mais j'étais inquiet que Full GC se produise un peu dans mon environnement. ʻOutOfMemoryError` ne s'est pas produit, mais il est possible s'il gonfle.

En fait, ** CMS pourrait devenir inutilisable à l'avenir **. Veuillez lire la suite pour plus de détails.

N'ajoutez pas d'assaisonnement supplémentaire au CMS

N'utilisez pas le mode incrémentiel (-XX: + CMSIncrementalMode).

Le collecteur CMS peut être utilisé dans un mode dans lequel la phase simultanée est incrémentielle. Comme mentionné précédemment, le thread du ramasse-miettes utilise un ou plusieurs processeurs pendant la phase simultanée. Le mode incrémentiel est destiné à atténuer les effets de la phase simultanée à long terme en ** arrêtant périodiquement la phase simultanée ** et en renvoyant le processeur vers l'application.

Il y avait une possibilité qu'un décalage se produise en raison de cet "arrêt régulier". Ou plutôt

Le mode incrémentiel est obsolète dans Java SE 8 et pourrait être supprimé dans les futures versions majeures.

Parce qu'il y en a, je n'utilise pas le mode incrémentiel.

Source: https://docs.oracle.com/javase/jp/8/docs/technotes/guides/vm/gctuning/cms.html

Kurofune visite G1GC

Garbage First Garbage Collector, G1GC en abrégé. C'est également l'un des algorithmes de garbage collection. Cependant, c'est un nouveau gars!

Il a été officiellement implémenté à partir de Java7 (java7u4), et il est utilisé en standard à partir de Java9. Et ** CMS est obsolète **.

Le Garbage First (G1) Garbage Collector est destiné à remplacer la plupart des utilisations de CMS.

Est-il possible que le CMS soit supprimé à l'avenir en le remplaçant?

La source:

C'est un peu difficile à définir, donc la valeur par défaut est bonne

référence:

Le G1 GC est un garbage collector adaptatif qui peut être utilisé et travaillé efficacement sans changer les valeurs par défaut.

Tout d'abord, jetez un œil à l'état sans rien ajouter, car il dit "fonctionne efficacement".

Résumé: n'utilisez pas de scripts de démarrage qui prétendent être "optimisés" ou "accélérés"

Tant que le pool de mémoire est suffisamment alloué, Java VM fera le reste automatiquement. Génial!

La machine virtuelle Java propose différents choix par défaut spécifiques à la plate-forme pour le ramasse-miettes, la taille du tas et le compilateur d'exécution. Ces choix répondent aux besoins de différentes applications avec moins de réglages sur la ligne de commande. En outre, le réglage basé sur le comportement ajuste dynamiquement la taille du tas en fonction de comportements spécifiques de l'application.

Source: Ergonomie

La vitesse de traitement n'augmente pas au-delà des spécifications de la machine. C'est plutôt un article qui vous dit que l'ajout d'options de démarrage Java étranges sans comprendre cela entraînera une inefficacité et entraînera un retard et un retour en arrière.

En outre, celui à utiliser, CMS ou G1GC, dépend de l'environnement. Comme je l'ai écrit ci-dessus, CMS est obsolète dans Java 9, il peut donc être judicieux de passer à G1GC. Cependant, dans un environnement à faibles spécifications, G1GC se sent un peu dur (car G1GC a une utilisation du processeur légèrement plus élevée que CMS). Lisez l'article de référence suivant pour la raison!

référence:

Lorsque vous utilisez G1GC, utilisez les options suivantes. Avec Java 9 et supérieur, ce n'est qu'un sortilège.

start.sh


#!/bin/sh
java -Xms1G -Xmx1G -XX:+UseG1GC -jar spigot.jar

L'une des fonctionnalités de G1GC est "Objectif de temps de pause". La valeur par défaut est de 200 millisecondes, ce qui est assez faible, mais dans mon environnement, je pensais qu'il serait possible de minimiser le décalage en le changeant à 50 millisecondes et en définissant le décalage petit.

start.sh


#!/bin/sh
java -Xms1G -Xmx1G -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -jar spigot.jar

Si vous voulez régler, il vaut peut-être mieux le garder à ce niveau. Je pense que le placebo est un peu efficace. Cependant, ce n'est pas bon s'il est trop petit, donc s'il y a un problème, essayez de l'augmenter. Actuellement, Full GC ne se produit pas dans notre environnement.

Puisqu'il y a plusieurs choses, je souhaite la bienvenue à Tsukkomi s'il y a quelque chose qui ne va pas. Ignorez tout autre "que dois-je faire?" veuillez noter que.

Recommended Posts

Les options de démarrage Java Spigot (Bukkit) n'ont pas besoin d'être réglées autant
Résumé des éléments à installer pour exécuter tf-pose-estimation
Installer les packages qui doivent être compilés avec Python 3 avec pip [Windows]