Requisitos de un servidor Lineage 2: cuánta máquina necesitas de verdad

Precisar los requisitos de tu servidor Lineage 2 se reduce a una pregunta: cuántos jugadores esperas a la vez y cuán pesado es tu mundo. Un servidor privado son dos procesos Java y una base de datos, y cada uno tiene su propio apetito de CPU, RAM y disco. Este artículo es una ficha técnica, no una guía de hosting. Cubre los núcleos, la memoria, el almacenamiento, el ancho de banda y las versiones de software que un servidor Lineage 2 suele necesitar en poblaciones pequeñas, medianas y grandes, para que puedas dimensionar una máquina antes de alquilarla o montarla.

Qué impulsa realmente la carga

Cuatro recursos deciden si un servidor se siente fluido: CPU, RAM, I/O de disco y ancho de banda de subida. La población marca la escala, pero un mundo con miles de NPCs, pathfinding, quests y eventos pesa más por jugador que una build PvP despojada con la spawnlist limpiada. Trata los números de abajo como puntos de partida, y observa tus propias métricas antes de comprar más hardware.

CPU: primero los núcleos, después la frecuencia

Los cores modernos basados en L2J (L2JMobius, aCis y L2J Server) son multi-hilo y usarán núcleos extra. Cuatro núcleos es un mínimo práctico para un servidor en vivo, y de seis a ocho núcleos dan margen para respirar al pathfinding, la IA y el manejo de paquetes en poblaciones medianas. La frecuencia sigue importando, porque acciones puntuales pesadas, como cambios de clase o eventos con muchos spawns, se apoyan en un solo hilo.

• Los pools de hilos escalan con los núcleos. Una base común en las configs de Mobius fija el pool programado en núcleos por cuatro y el pool instantáneo en núcleos por dos.
• El viejo consejo de que un servidor L2J no consume mucha CPU viene de builds pequeñas de Interlude. Cuando tienes cientos de jugadores, mobs y skills en el mapa, el uso de CPU sube.
• No compres más núcleos de los que puedas alimentar con RAM. Una máquina rápida de cuatro núcleos con memoria suficiente gana a una lenta de muchos núcleos muerta de hambre.

RAM: dimensionar el heap de Java según los jugadores

La RAM es el recurso que más subestiman los dueños. El game server mantiene el mundo en memoria, y el login server es comparativamente diminuto. Como el stack es Java, dimensionas la memoria como un tope de heap, no como una cifra de instalación en bruto. Una referencia de Mobius muy usada da estos heaps de game server: unos 4 GB para menos de 100 jugadores, 16 GB para 100 a 500, y 32 GB para 500 a 2000. El login server se queda en los cientos bajos de megabytes en todos los casos.

Añade margen por encima del heap para el sistema operativo, la base de datos y la propia JVM. Un heap de 32 GB pensado para 500 jugadores implica una máquina de 40 GB o más una vez que MySQL y el sistema operativo se llevan su parte.

Una advertencia de la wiki de instalación de L2JMobius: no asignes un único heap enorme aunque tengas la RAM. Pasados unos 28 GB, los heaps más grandes empeoran las pausas de recolección de basura en lugar de mejorarlas. Más allá de ese punto, escala dividiendo servicios, no inflando un solo tope de heap.

La geodata cambia las cuentas. Cargar la geodata en memoria añade unos 2 a 3 GB, y activar pathnode encima puede empujar hacia los 5 GB. Si la RAM es escasa, puedes desactivar la geodata o leerla desde disco, a costa de la precisión del pathfinding.

Disco: SSD, geodata y un disco aparte para la base de datos

Presupuesta al menos 10 GB de espacio libre para el código fuente, la salida de build y la base de datos en una instalación pelada. Los que más consumen son el data pack, los archivos de geodata (de cientos de megabytes a un par de GB según la crónica y la conversión) y la base de datos a medida que se acumulan personajes, objetos, clanes y logs.

Usa un SSD. Los discos mecánicos eran el cuello de botella en los servidores de los 2000 y siguen siendo la parte más lenta de uno moderno. La regla clásica de rendimiento sigue en pie: mantén la base de datos en su propio disco o su propio volumen, para que MySQL y el game server no luchen por el mismo I/O. En un VPS eso significa un plan con un disco de datos aparte, o un host dedicado para la base de datos cuando crezcas.

Ancho de banda: la subida es lo que importa

Los jugadores se conectan de forma entrante y reciben el mundo de forma saliente, así que la subida es tu limitación. Las mediciones de la comunidad sitúan a un jugador activo típico en unos 20 a 30 KB por segundo, y el flujo de servidor a cliente es mucho más pesado que el de cliente a servidor, porque el servidor envía cada movimiento, skill y efecto cercano.

Un enlace de subida de 5 Mbps puede servir a unos cientos de jugadores en juego normal, pero los asedios, el PvP masivo y las zonas de eventos disparan el tráfico unas diez veces. Para un objetivo de 500 jugadores, 10 Mbps o más de subida es el mínimo más seguro, y lo quieres estable y de baja latencia en lugar de a ráfagas. Las conexiones domésticas compartidas rara vez ofrecen ninguna de las dos cosas.

El stack de software: JDK, base de datos y dos procesos

Necesitas un JDK, una base de datos compatible con MySQL y Apache Ant para compilar la mayoría de los packs. La versión exacta de JDK depende del emulador y de su revisión, así que revisa siempre el readme que viene con tu build.

• L2JMobius: las versiones recientes apuntan a un JDK moderno, y la línea actual usa JDK 25. Las carpetas de crónicas anteriores pueden indicar JDK 17. Java 8 ya no es compatible.
• aCis: depende de la revisión. Las builds por debajo de la revisión 381 usan JDK 8, las revisiones 381 a 406 usan JDK 11, y las revisiones posteriores usan JDK 21.
• L2J Server: las builds actuales corren en Java 11 o superior, con Java 21 como opción segura.

Usa una distribución LTS mantenida como la build de Eclipse Temurin en lugar de un JDK cualquiera de un servidor de archivos.

Para la base de datos, MySQL 5.7 o superior, o una versión reciente de MariaDB, ambas funcionan. Muchos dueños de aCis corren MariaDB 10.9 o posterior. Ajusta el buffer pool de InnoDB a una porción sensata de la RAM (hasta aproximadamente la mitad en una máquina compartida, más en un host dedicado para la base de datos) y mantén el esquema en almacenamiento rápido.

Por último, corre el login server, el game server y la base de datos como procesos separados incluso en una sola máquina. Ese aislamiento es lo que te permite reiniciar uno sin matar a los demás, y es la misma razón por la que los servidores grandes acaban moviendo la base de datos a su propio host.

Ficha de referencia según el tamaño del servidor

La tabla de abajo es un punto de partida, no una regla estricta. Redondea hacia arriba cuando tu mundo esté muy scripteado o tu población sea irregular.

Estas cifras asumen un pack razonablemente optimizado. Una build con scripts personalizados pesados, spawns densos o una base de datos en el mismo disco lento necesitará más de todo.

Dónde los dueños se pasan y se quedan cortos

Los dos errores comunes son opuestos. Algunos dueños compran una CPU enorme y luego corren un heap de 4 GB, así que el mundo da tirones mientras el procesador está ocioso. Otros intentan correr 300 jugadores en un VPS de 2 núcleos con 4 GB, y luego culpan al pack cuando el pathfinding y las colas de login se atascan.

Empareja la RAM con la población primero, luego dale a la CPU suficiente margen, y después asegúrate de que la base de datos no esté luchando con el game server por el disco. El ancho de banda es la pieza que la mayoría de las configs domésticas hacen mal, porque la subida es lenta y compartida. Si no puedes controlar la calidad del enlace, ninguna cantidad de CPU arregla el lag en los asedios.

Cuando tu máquina aguante la población que buscas, el siguiente paso es llevar jugadores a ella. Añade tu mundo a través del formulario de envío gratis de servidores, o toma una colocación VIP si quieres más visibilidad desde el primer día. También puedes comparar cómo describen otros dueños sus rates y su setup en el directorio de servidores.