LeanCore

Ativo

Hytale • Version 1.8.0

servidormemóriaramgovernadorretençãoperformanceadminaprendizadosoloco-op

O LeanCore é um governador de memória server-side para Hytale. Ele lê quanta heap está realmente em uso depois de cada garbage collection e age em cima disso: corta view e raio de simulação quando a memória aperta de verdade, usa a heap que sobra para manter carregados os chunks visitados há pouco (voltar pelo mesmo caminho não relê tudo do disco) e desacelera o streaming de chunks sob pressão real.

No mundo local / solo, roda profile LITE. Com amigos, sobe para STANDARD. Em servidor dedicado, profile FULL.

Não mexe em FPS, GPU ou TPS do cliente.

Requer servidor Hytale >=0.7.0. Depois de instalar, rode /leancore status com o servidor rodando cerca de um minuto.

Por que existe

O engine já descarrega qualquer chunk que nenhum jogador vê, uns 7,5 segundos depois de sair da visão. Duas coisas ele não faz:

Julga a memória pela heap bruta, que inclui o lixo esperando a próxima coleta. A heap bruta oscila entre 40% e 90% num servidor saudável, então qualquer coisa que reaja a ela corta à toa.
Joga chunks fora mesmo com heap de sobra. Volte pelo caminho que veio e cada chunk é lido do disco de novo.

O LeanCore cobre essas duas lacunas.

Medido

Release 0.7.0 do Hytale, perfil dedicado (FULL), heap de 6 GB. Quatro exploradores virtuais saem do spawn em direções diferentes a 20 blocos/s e geram terreno novo o tempo todo, enquanto um jogador roteirizado voa 600 blocos, fica 90s parado e volta. Servidor sem mods contra o LeanCore 1.8.0, mesmo mundo e mesma rota.

	sem mod	LeanCore 1.8.0
Tick do mundo, média	19,6 ms	13,4 ms (-32%)
Tick do mundo, p95	44,8 ms	35,1 ms (-22%)
Pior tick	1440 ms	299 ms (-79%)
Tempo total em pausas de GC	7,3 s	5,0 s (-31%)
Maior pausa de GC	1194 ms	201 ms (-83%)
Heap pós-GC, p95	6071 MB	4906 MB (-19%)
Pico da heap pós-GC	99,99% do máximo	83% do máximo

Sem o LeanCore a heap pós-GC chegou a 99,99% do máximo, acima dos 85% em que o engine começa o próprio unload de emergência. Com ele, o pico ficou em 83%.

O custo: o view radius ficou em 16 chunks em média em vez de 24 (mínimo 12). Quando a visão volta no voo de retorno, a área que tinha sido largada carrega de novo, então a volta leu 24% mais chunks do disco e o tick dela foi 17% mais lento. O próprio LeanCore usou 0,42% da CPU do servidor. Uma corrida por variante; seu mundo vai ser diferente.

Solo, retenção de chunks

Pre-release do Hytale 0.7: solo, heap de 3 GB, o mesmo voo roteirizado, build anterior à retenção de chunks contra a 1.8.0.

	antes	1.8.0
Chunks recarregados do disco na volta	1203	653 (-46%)
Tick do mundo na volta	12,5 ms	10,9 ms (-13%)
View radius ao entrar	cortado para 8 por alarme falso da heap bruta	mantido em 10
Mudanças de policy na corrida	13	5

O custo: mais heap em uso durante a corrida (limitado a 50% depois do GC) e cerca de 0,16% a mais do tempo em pausas de GC. Uma corrida por build; seu mundo vai ser diferente.

Como o LeanCore decide

          a cada 5s no solo, a cada tick do governador em servidores
                                   │
       heap pós-GC  +  old gen pós-GC  +  tendência de crescimento
                                   │
        ┌──────────────┬───────────┴───────────┬──────────────┐
        ▼              ▼                       ▼              ▼
     COMFORT         WATCH                   TIGHT         CRITICAL
   view cheia     corte leve             corte maior      corte máximo
  segura chunks   solta chunks           solta chunks     solta chunks
   de sobra        retidos             + freia loading   + freia mais

Retenção de chunks

   um chunk sai da visão de todos os jogadores
                 │
                 ▼
   o engine descarregaria em ~7,5s
                 │
   COMFORT e heap pós-GC abaixo de 45%?  ── não ──►  engine descarrega
                 │ sim
                 ▼
   LeanCore segura (referência keep-loaded do engine; para de tickar)
                 │
   jogador volta                 ──►  já carregado, sem ler o disco
   heap pós-GC acima de 50%      ──►  os mais longe saem primeiro, 64 a cada 2s
   pressão, ou passaram 10 min   ──►  solto, engine descarrega normal

Como o LeanCore pensa

1. Lê a heap que realmente fica

Logo depois de cada garbage collection a JVM informa o que sobreviveu. Esse número, mais o old gen pós-GC e a tendência de crescimento, é o que o LeanCore chama de pressão. Tiers padrão:

Tier	Heap pós-GC	O que o LeanCore faz
COMFORT	abaixo de 70%	view cheia, segura chunks de sobra
WATCH	70% ou mais	cortes leves de view, solta chunks retidos
TIGHT	82% ou mais	cortes maiores, raio de simulação menor, freia o carregamento de chunks
CRITICAL	90% ou mais	cortes máximos, freio mais forte, webhook opcional

A heap bruta sozinha só conta como CRITICAL em 97%, o ponto em que a memória acaba de verdade. Uma heap que não para de subir pode subir de tier antes de cruzar a linha.

2. Reage rápido e confirma antes de agir

No solo a checagem de pressão roda a cada 5 segundos e acorda o governador na hora quando o tier sobe. Uma mudança precisa de duas leituras para confirmar, as mudanças de policy são espaçadas, e se a heap sobe logo depois de devolver a view, o corte volta.

3. Usa a heap de sobra em vez de desperdiçar

Quando um chunk sai da visão de todos os jogadores, o engine joga ele fora alguns segundos depois, não importa como está a heap. Enquanto o tier é COMFORT e a heap pós-GC está abaixo de 45%, o LeanCore mantém um orçamento desses chunks carregados pela própria referência keep-loaded do engine. O engine para de tickar eles, então custam memória, não CPU. Volte e eles já estão lá. Se a heap pós-GC passa de 50%, os mais longe saem primeiro, 64 a cada 2 segundos, para uma subida curta não jogar fora o caminho todo. Qualquer tier de pressão solta tudo na próxima checagem, e o LeanCore nunca remove um chunk por conta própria.

4. Desacelera o carregamento só quando a memória precisa

Em TIGHT e CRITICAL a taxa de envio de chunks de cada jogador fica limitada (512 e 192 seções por segundo por padrão), o que ainda acompanha andar e voar, mas evita que rajadas de entrada e teleporte caiam em cima de uma heap cheia. COMFORT e WATCH devolvem a taxa do próprio engine.

5. Leva em conta quem é o jogador

Um classificador online (Activity Sense) rotula cada jogador pela atividade recente: MINER LUMBERJACK FARMER BUILDER FIGHTER EXPLORER. Isso alimenta um modelo de demanda que decide o quanto a view de cada jogador é cortada dentro de um orçamento global.

6. Age na thread certa

Toda leitura ou escrita de chunk store, chunk tracker ou view radius roda na thread do mundo dono. O scheduler de fundo só orquestra.

Com o QuantumHy

O LeanCore e o QuantumHy funcionam sozinhos ou juntos. Com os dois instalados, o QuantumHy assume o view radius do cliente e a taxa de envio de chunks (a suavização anti-stutter dele), e o LeanCore fica com a memória: tiers, raio de simulação e retenção de chunks. O QuantumHy lê o tier do LeanCore e aperta o render radius em TIGHT ou CRITICAL. O freio de chunks do LeanCore fica desligado enquanto o QuantumHy está carregado.

Profiles de runtime

O LeanCore se ajusta ao host sozinho, pela quantidade de jogadores, sem chave manual:

Profile	Quando	Tick	O que roda
LITE	mundo solo embutido	30s (60s parado), pressão a cada 5s	governador leve, view adaptativa, retenção, learning de demanda
STANDARD	alguns amigos	15s	adiciona Activity Sense, governador e learning opcionais
FULL	servidor dedicado	5s	conjunto completo

O que ele deliberadamente não faz

Mexer em FPS, GPU ou performance de renderização do cliente. É só heap do servidor.
Mudar TPS ou comportamento da simulação.
Remover chunks. Descarregar é trabalho do engine; o LeanCore só decide quanto tempo a heap de sobra segura eles.
Cortar por causa de lixo. Picos da heap bruta entre coletas são ignorados até a heap estar de fato perto do limite.

Funcionalidades

Profiles de runtime: LITE solo, STANDARD amigos, FULL dedicado (localHostMode: AUTO)
Tiers pela heap real: COMFORT, WATCH, TIGHT, CRITICAL a partir da heap pós-GC, old gen pós-GC e tendência de crescimento; rollback quando devolver a view piora
Retenção de chunks (1.8, chunkRetentionEnabled): a heap de sobra mantém chunks recém-saídos carregados, e voltar não lê o disco
Freio de chunks (1.8, chunkRateBrakeEnabled): desacelera o streaming em TIGHT/CRITICAL; desligado enquanto o QuantumHy está carregado
Cortes de view radius (LITE) e de raio de simulação sob pressão real, nunca abaixo de liteMinClientViewRadius
Activity Sense: classificador softmax online (MINER, LUMBERJACK, FARMER, BUILDER, FIGHTER, EXPLORER) alimentando a demanda por jogador
Dados de learning: janelas de heap, modelo de demanda, estatísticas de reuso de zona; salvos entre reinícios (schema v9)
Session savings: /leancore savings mostra pico/base/delta da heap JVM e atividade do governador
Diagnóstico sempre ligado (diagnosticLogEnabled): resumos de início/fim e logs [diag] de decisão direto no log do servidor
Aviso de atualização para ops/admins quando sai um JAR novo (desligar: checkForUpdates)
HUD de admin (/leancore hud on): overlay pequeno de heap/tier. Desligado por padrão.
Heatmap, zone pin, webhook opcional em CRITICAL

Instalação

Baixe LeanCore-1.8.0.jar na aba Files do CurseForge
Coloque o JAR na pasta mods/ do servidor (ou %AppData%\Hytale\UserData\Mods\ no Windows)
Inicie o servidor. A config é criada em mods/durkz_LeanCore/LeanCore.json
Rode /leancore status depois de cerca de um minuto

Comandos

Comando principal: /leancore

/leancore status
/leancore memory
/leancore savings
/leancore zones
/leancore learn
/leancore learn player
/leancore probe
/leancore hud on|off|status
/leancore heatmap [limit]
/leancore zone pin|unpin|pins

Comandos admin, permissões e config completa: documentação

Config

Arquivo: mods/durkz_LeanCore/LeanCore.json

Chaves principais: localHostMode, liteMemoryGovernorEnabled, liteViewRadiusEnabled, liteLearningEnabled, chunkRetentionEnabled, chunkRateBrakeEnabled, watchHeapRatio, tightHeapRatio, criticalHeapRatio, diagnosticLogEnabled, governEnabled, learningEnabled, embeddedStandardProfile, dedicatedServerMode.

Snapshot de learning: mods/durkz_LeanCore/learning.state.gz (schema v9, gzip).

Permissões

Quem vê o HUD: grupos em hudViewerGroups e/ou durkz.leancore.hud
Heatmap, zone pin e diagnóstico de webhook (admin): hudAdminGroups e/ou durkz.leancore.admin

Licença

MIT License

Para donos de servidor

Precisa de permissões, comandos e config?

O guia completo cobre cada permissão, comando de admin, exemplos LuckPerms e todas as opções de configuração.

Ler documentação do servidor