Requisitos de Servidor Lineage 2: Quanta Máquina Você Realmente Precisa

Definir os requisitos de um servidor Lineage 2 se resume a uma pergunta: quantos jogadores você espera ao mesmo tempo, e quão pesado é o seu mundo. Um servidor privado são dois processos Java e um banco de dados, e cada um tem o seu próprio apetite por CPU, RAM e disco. Este artigo é uma ficha técnica, não um guia de hospedagem. Ele cobre os núcleos, a memória, o armazenamento, a banda e as versões de software que um servidor Lineage 2 geralmente precisa em populações pequenas, médias e grandes, para você dimensionar uma máquina antes de alugá-la ou montá-la.

O Que Realmente Determina a Carga

Quatro recursos decidem se um servidor parece fluido: CPU, RAM, I/O de disco e banda de upload. A população define a escala, mas um mundo com milhares de NPCs, pathfinding, quests e eventos é mais pesado por jogador que uma build de PvP enxuta com uma spawnlist limpa. Trate os números abaixo como pontos de partida, e observe as suas próprias métricas antes de comprar mais hardware.

CPU: Núcleos Primeiro, Clock Depois

Os cores modernos baseados em L2J (L2JMobius, aCis e L2J Server) são multi-thread e vão usar núcleos extras. Quatro núcleos é um piso prático para um servidor ao vivo, e seis a oito núcleos dão espaço para pathfinding, IA e tratamento de pacotes respirarem em populações médias. A velocidade de clock ainda importa porque ações pesadas e isoladas, como trocas de classe ou grandes eventos de spawn, dependem de uma única thread.

• Os pools de thread escalam com os núcleos. Uma base comum nas configs do Mobius define o pool agendado como núcleos vezes quatro e o pool instantâneo como núcleos vezes dois.
• O conselho antigo de que um servidor L2J não é intensivo em CPU data de builds pequenas do Interlude. Assim que você tem centenas de jogadores, mobs e skills no mapa, o uso de CPU sobe.
• Não compre mais núcleos do que você consegue alimentar com RAM. Uma máquina rápida de quatro núcleos com memória suficiente supera uma máquina lenta de muitos núcleos que passa fome.

RAM: Dimensionando o Heap Java pela Quantidade de Jogadores

A RAM é o recurso que os donos mais subestimam. O game server mantém o mundo na memória, e o login server é comparativamente minúsculo. Como a stack é Java, você dimensiona a memória como um teto de heap, não como um número bruto de instalação. Uma referência do Mobius amplamente usada dá estes heaps de game server: cerca de 4 GB para menos de 100 jogadores, 16 GB para 100 a 500, e 32 GB para 500 a 2000. O login server fica na casa das centenas baixas de megabytes em todos os casos.

Adicione folga em cima do heap para o sistema operacional, o banco de dados e a própria JVM. Um heap de 32 GB voltado a 500 jogadores implica uma máquina de 40 GB ou maior quando o MySQL e o SO ficam com a sua parte.

Uma ressalva da L2JMobius installation wiki: não aloque um único heap enorme mesmo que você tenha a RAM. Passando de cerca de 28 GB, heaps maiores pioram as pausas de garbage collection em vez de melhorá-las. Além desse ponto, escale dividindo serviços, não inflando um único teto de heap.

O geodata muda as contas. Carregar geodata na memória adiciona cerca de 2 a 3 GB, e habilitar pathnode em cima pode chegar perto de 5 GB. Se a RAM estiver apertada, você pode desabilitar o geodata ou lê-lo do disco, ao custo da precisão de pathfinding.

Disco: SSD, Geodata e um Disco Separado para o Banco

Reserve pelo menos 10 GB de espaço livre para o código-fonte, a saída de build e o banco de dados em uma instalação limpa. Os maiores consumidores são o data pack, os arquivos de geodata (de centenas de megabytes a alguns GB dependendo da crônica e da conversão) e o banco de dados conforme personagens, itens, clãs e logs se acumulam.

Use um SSD. Discos mecânicos eram o gargalo nos servidores dos anos 2000 e continuam sendo a parte mais lenta de um servidor moderno. A regra clássica de desempenho ainda vale: mantenha o banco de dados no seu próprio disco ou volume, para que o MySQL e o game server não briguem pelo mesmo I/O. Em um VPS isso significa um plano com um disco de dados separado, ou um host de banco de dados dedicado conforme você cresce.

Banda: O Upload É o Que Importa

Os jogadores se conectam de entrada e recebem o mundo de saída, então o upload é a sua limitação. Medições da comunidade colocam um jogador ativo típico em cerca de 20 a 30 KB por segundo, e o fluxo do servidor para o cliente é muito mais pesado que o do cliente para o servidor, porque o servidor envia cada movimento, skill e efeito próximos.

Um link de upload de 5 Mbps consegue servir algumas centenas de jogadores em jogo comum, mas cercos, PvP em massa e zonas de evento disparam o tráfego em cerca de dez vezes. Para uma meta de 500 jogadores, 10 Mbps ou mais de upload é o piso mais seguro, e você quer isso estável e com baixa latência, não em rajadas. Conexões residenciais compartilhadas raramente entregam qualquer um dos dois.

A Stack de Software: JDK, Banco de Dados e Dois Processos

Você precisa de um JDK, um banco de dados compatível com MySQL e o Apache Ant para construir a maioria dos packs. A versão exata do JDK depende do emulador e da sua revisão, então sempre confira o readme que acompanha a sua build.

• L2JMobius: lançamentos recentes visam um JDK moderno, e a linha atual usa JDK 25. Pastas de crônicas anteriores podem especificar JDK 17. Java 8 não é mais suportado.
• aCis: depende da revisão. Builds abaixo da revisão 381 usam JDK 8, revisões 381 a 406 usam JDK 11, e revisões posteriores usam JDK 21.
• L2J Server: builds atuais rodam em Java 11 ou mais novo, com Java 21 sendo uma escolha segura.

Use uma distribuição LTS mantida como a Eclipse Temurin build em vez de um JDK aleatório de um file host.

Para o banco de dados, MySQL 5.7 ou mais novo, ou um MariaDB release recente, ambos funcionam. Muitos donos de aCis rodam MariaDB 10.9 ou posterior. Defina o buffer pool do InnoDB como uma fração sensata da RAM (até cerca de metade em uma máquina compartilhada, mais em um host de banco dedicado) e mantenha o schema em armazenamento rápido.

Por fim, rode o login server, o game server e o banco de dados como processos separados mesmo em uma única máquina. Esse isolamento é o que permite reiniciar um sem matar os outros, e é o mesmo motivo pelo qual servidores grandes eventualmente movem o banco de dados para o seu próprio host.

Ficha de Referência por Tamanho de Servidor

A tabela abaixo é um ponto de partida, não uma regra rígida. Arredonde para cima quando o seu mundo for muito scriptado ou a sua população for irregular.

Esses números pressupõem um pack razoavelmente otimizado. Uma build com muitos scripts customizados, spawns densos ou um banco de dados no mesmo disco lento vai precisar de mais de tudo.

Onde os Donos Gastam Demais e de Menos

Os dois erros comuns são opostos. Alguns donos compram uma CPU enorme e depois rodam um heap de 4 GB, então o mundo engasga enquanto o processador fica ocioso. Outros tentam rodar 300 jogadores em um VPS de 2 núcleos com 4 GB, e depois culpam o pack quando o pathfinding e as filas de login sufocam.

Combine a RAM com a população primeiro, depois dê à CPU folga suficiente, e então garanta que o banco de dados não esteja brigando com o game server pelo disco. A banda é a peça que a maioria das configurações domésticas erra, porque o upload é lento e compartilhado. Se você não consegue controlar a qualidade do link, nenhuma quantidade de CPU resolve o lag de cerco.

Depois que a sua máquina aguenta a população que você almeja, o próximo passo é trazer jogadores para ela. Adicione o seu mundo pelo formulário de envio gratuito de servidor, ou escolha um destaque VIP se quiser mais visibilidade desde o primeiro dia. Você também pode comparar como outros donos descrevem os seus rates e a sua configuração no diretório de servidores.