As flags do Aikar mudam aos 12 GB — cinco delas, e uma diminui
Copiar um conjunto de flags de 4 GB para um servidor de 16 GB deixa cinco valores errados. Aqui estão exatamente quais são essas cinco, além da contagem de jogadores onde um servidor modificado cruza a linha e um vanilla não.
As flags do Aikar são os argumentos JVM padrão da comunidade para um servidor Paper, e geralmente são copiadas como um bloco único. Elas não são um bloco único: dos vinte argumentos, cinco mudam dependendo se o seu heap está abaixo ou acima de 12 GB. Colar um conjunto de heap pequeno em um servidor de heap grande é a maneira mais comum de usar "as flags recomendadas" e não obtê-las.
As cinco que mudam
| flag | abaixo de 12 GB | 12 GB ou mais |
|---|---|---|
-XX:G1NewSizePercent | 30 | 40 |
-XX:G1MaxNewSizePercent | 40 | 50 |
-XX:G1HeapRegionSize | 8M | 16M |
-XX:G1ReservePercent | 20 | 15 |
-XX:InitiatingHeapOccupancyPercent | 15 | 20 |
G1ReservePercent é a que diminui. Quatro das cinco aumentam com o tamanho do heap e essa diminui, razão pela qual um "aumentar os números para um servidor grande" meio lembrado produz um conjunto errado em vez de apenas subótimo. Ela reserva uma fração do heap contra falha de evacuação, e um heap maior precisa de uma fração menor para manter a mesma folga absoluta.
Os treze argumentos -XX: restantes são idênticos em todos os tamanhos de heap — -XX:+UseG1GC, -XX:MaxGCPauseMillis=200, -XX:+AlwaysPreTouch, -XX:SurvivorRatio=32, -XX:MaxTenuringThreshold=1 e o resto não se movem. Apenas -Xms e -Xmx acompanham o tamanho do heap em si.
Onde a linha de 12 GB realmente cai
O gerador nesta página dimensiona o heap a partir da sua contagem de Jogadores:
GB = clamp( ceil( (modded ? 2.5 : 1) × (2 + players / 12) ), 2, 32 )Servidores modificados são orçados em 2.5× vanilla, e esse fator decide quem realmente vê o ramo de heap grande:
| Jogadores | vanilla | modificado |
|---|---|---|
| 10 | 3 GB | 8 GB |
| 20 | 4 GB | 10 GB |
| 29 | 5 GB | 12 GB ← modificado cruza aqui |
| 50 | 7 GB | 16 GB |
| 100 | 11 GB | 26 GB |
| 109 | 12 GB ← vanilla cruza aqui | 28 GB |
Um servidor modificado atinge as flags de heap grande com 29 Jogadores. Um servidor vanilla não o faz até 109. Então, para a maioria das pessoas que executam Paper vanilla, o conjunto de heap pequeno é o correto permanentemente — e para a maioria das pessoas que executam modificado, ele deixa de ser correto muito antes do que esperam.
Dois limites nessa fórmula que valem a pena conhecer
Nunca recomenda mais de 32 GB. O vanilla atinge o limite em 349 Jogadores e permanece lá. Isso não é um artefato de arredondamento — acima de aproximadamente 32 GB, a JVM perde os ponteiros de objeto compactados e cada referência no heap fica maior, então mais RAM pode significar menos heap utilizável. Escalar além desse ponto é trabalho para um segundo servidor, não um maior.
Nunca recomenda menos de 2 GB, mesmo para um único Jogador, porque o limite mínimo é o software do servidor e não a população.
E seja o que for que a fórmula diga: não dê à JVM tudo o que a máquina tem. -Xms e -Xmx são definidos com o mesmo valor aqui de propósito — um heap fixo evita que a JVM redimensione sob carga — o que significa que o número que você escolhe é reivindicado imediatamente e permanentemente. Deixe 1–2 GB para o sistema operacional para que ele não precise lutar com você.