Les flags d'Aikar changent à 12 Go — cinq d'entre eux, et l'un diminue
Copier un ensemble de flags de 4 Go sur un serveur de 16 Go laisse cinq valeurs incorrectes. Voici exactement lesquelles, plus le nombre de Joueurs où un serveur moddé franchit la ligne et un serveur vanilla ne le fait pas.
Les flags d'Aikar sont les arguments JVM standard de la communauté pour un serveur Paper, et ils sont généralement copiés en un seul bloc. Ils ne sont pas un seul bloc : sur les vingt arguments, cinq changent selon que votre heap est inférieure ou supérieure à 12 Go. Coller un ensemble de flags pour petite heap sur un serveur à grande heap est le moyen le plus courant d'utiliser "les flags recommandés" sans les obtenir.
Les cinq qui changent
| flag | moins de 12 Go | 12 Go et plus |
|---|---|---|
-XX:G1NewSizePercent | 30 | 40 |
-XX:G1MaxNewSizePercent | 40 | 50 |
-XX:G1HeapRegionSize | 8M | 16M |
-XX:G1ReservePercent | 20 | 15 |
-XX:InitiatingHeapOccupancyPercent | 15 | 20 |
G1ReservePercent est celui qui diminue. Quatre des cinq augmentent avec la taille de la heap et celui-ci diminue, c'est pourquoi un "augmenter les nombres pour un gros serveur" mal mémorisé produit un ensemble incorrect plutôt qu'un ensemble simplement sous-optimal. Il réserve une fraction de la heap contre les échecs d'évacuation, et une heap plus grande a besoin d'une fraction plus petite pour maintenir la même marge absolue.
Les treize autres arguments -XX: sont identiques quelle que soit la taille de la heap — -XX:+UseG1GC, -XX:MaxGCPauseMillis=200, -XX:+AlwaysPreTouch, -XX:SurvivorRatio=32, -XX:MaxTenuringThreshold=1 et les autres ne bougent pas. Seuls -Xms et -Xmx suivent la taille de la heap elle-même.
Où se situe réellement la ligne des 12 Go
Le générateur sur cette page dimensionne la heap en fonction du nombre de Joueurs :
GB = clamp( ceil( (modded ? 2.5 : 1) × (2 + players / 12) ), 2, 32 )Les serveurs moddés sont budgétisés à 2,5× la version vanilla, et ce facteur décide qui voit la branche de grande heap :
| Joueurs | vanilla | moddé |
|---|---|---|
| 10 | 3 Go | 8 Go |
| 20 | 4 Go | 10 Go |
| 29 | 5 Go | 12 Go ← moddé franchit ici |
| 50 | 7 Go | 16 Go |
| 100 | 11 Go | 26 Go |
| 109 | 12 Go ← vanilla franchit ici | 28 Go |
Un serveur moddé atteint les flags de grande heap à 29 Joueurs. Un serveur vanilla ne le fait qu'à 109. Ainsi, pour la plupart des gens qui utilisent Paper vanilla, l'ensemble de petite heap est le bon en permanence — et pour la plupart des gens qui utilisent un serveur moddé, il cesse d'être correct beaucoup plus tôt qu'ils ne s'y attendent.
Deux limites de cette formule à connaître
Il ne recommande jamais plus de 32 Go. Vanilla atteint le plafond à 349 Joueurs et y reste. Ce n'est pas un artefact d'arrondi — au-delà d'environ 32 Go, la JVM perd les pointeurs d'objets compressés et chaque référence dans la heap devient plus grande, donc plus de RAM peut signifier moins de heap utilisable. Dépasser ce point est le travail d'un deuxième serveur, pas d'un plus grand.
Il ne recommande jamais moins de 2 Go, même pour un seul Joueur, car le plancher est le logiciel du serveur plutôt que la population.
Et quoi que dise la formule : ne donnez pas à la JVM tout ce que la machine possède. -Xms et -Xmx sont définis à la même valeur ici exprès — une heap fixe évite que la JVM ne se redimensionne sous la charge — ce qui signifie que le nombre que vous choisissez est réclamé immédiatement et en permanence. Laissez au système d'exploitation 1 à 2 Go pour lesquels il n'aura pas à se battre avec vous.