Lineage 2 Server Requirements: How Much Machine You Actually Need

Pinning down your lineage 2 server requirements comes down to one question: how many players you expect at once, and how heavy your world is. A private server is two Java processes and a database, and each one has its own appetite for CPU, RAM and disk. This article is a spec sheet, not a hosting guide. It covers the cores, memory, storage, bandwidth and software versions a Lineage 2 server typically needs at small, medium and large populations, so you can size a machine before you rent or build one.

What Actually Drives the Load

Four resources decide whether a server feels smooth: CPU, RAM, disk I/O and upload bandwidth. Population sets the scale, but a world with thousands of NPCs, pathfinding, quests and events is heavier per player than a stripped PvP build with a cleared spawnlist. Treat the numbers below as starting points, and watch your own metrics before you buy more hardware.

CPU: Cores First, Clock Second

Modern L2J-based cores (L2JMobius, aCis and L2J Server) are multi-threaded and will use extra cores. Four cores is a practical floor for a live server, and six to eight cores gives pathfinding, AI and packet handling room to breathe at medium populations. Clock speed still matters because heavy single actions, such as class changes or large spawn events, lean on one thread.

• Thread pools scale with cores. A common baseline in Mobius configs sets the scheduled pool to cores times four and the instant pool to cores times two.
• The old advice that an L2J server is not CPU-intensive dates from small Interlude builds. Once you have hundreds of players, mobs and skills on the map, CPU use climbs.
• Do not buy more cores than you can feed with RAM. A fast four-core box with enough memory beats a slow many-core box that is starved.

RAM: Sizing the Java Heap by Player Count

RAM is the resource owners underestimate most. The game server holds the world in memory, and the login server is comparatively tiny. Because the stack is Java, you size memory as a heap cap, not as a raw install figure. A widely used Mobius reference gives these game-server heaps: about 4 GB for under 100 players, 16 GB for 100 to 500, and 32 GB for 500 to 2000. The login server stays in the low hundreds of megabytes in every case.

Add headroom on top of the heap for the operating system, the database and the JVM itself. A 32 GB heap aimed at 500 players implies a 40 GB or larger machine once MySQL and the OS have their share.

One caveat from the L2JMobius installation wiki: do not allocate an enormous single heap even if you have the RAM. Past roughly 28 GB, larger heaps make garbage-collection pauses worse rather than better. Beyond that point, scale by splitting services, not by inflating one heap cap.

Geodata changes the maths. Loading geodata into memory adds roughly 2 to 3 GB, and enabling pathnode on top can push toward 5 GB. If RAM is tight, you can disable geodata or read it from disk, at the cost of pathfinding accuracy.

Disk: SSD, Geodata and a Separate Database Disk

Budget at least 10 GB of free space for source, build output and the database on a bare install. The bigger consumers are the data pack, geodata files (hundreds of megabytes to a couple of GB depending on chronicle and conversion) and the database as characters, items, clans and logs accumulate.

Use an SSD. Mechanical drives were the bottleneck on 2000s-era servers and remain the slowest part of a modern one. The classic performance rule still holds: keep the database on its own disk or its own volume, so MySQL and the game server do not fight for the same I/O. On a VPS that means a plan with a separate data disk, or a dedicated database host once you grow.

Bandwidth: Upload Is What Matters

Players connect inbound and receive the world outbound, so upload is your constraint. Community measurements put a typical active player at roughly 20 to 30 KB per second, and the server-to-client stream is far heavier than the client-to-server stream, because the server sends every nearby movement, skill and effect.

A 5 Mbps upload link can serve a few hundred players in ordinary play, but sieges, mass PvP and event zones spike traffic by roughly ten times. For a 500-player target, 10 Mbps or more of upload is the safer floor, and you want it stable and low-latency rather than bursty. Shared home connections rarely deliver either.

The Software Stack: JDK, Database and Two Processes

You need a JDK, a MySQL-compatible database and Apache Ant to build most packs. The exact JDK version depends on the emulator and its revision, so always check the readme that ships with your build.

• L2JMobius: recent releases target a modern JDK, and the current line uses JDK 25. Earlier chronicle folders may specify JDK 17. Java 8 is no longer supported.
• aCis: revision-dependent. Builds below revision 381 use JDK 8, revisions 381 to 406 use JDK 11, and later revisions use JDK 21.
• L2J Server: current builds run on Java 11 or newer, with Java 21 a safe choice.

Use a maintained LTS distribution such as the Eclipse Temurin build rather than a random JDK from a file host.

For the database, MySQL 5.7 or newer, or a recent MariaDB release, both work. Many aCis owners run MariaDB 10.9 or later. Set the InnoDB buffer pool to a sensible share of RAM (up to about half on a shared box, more on a dedicated database host) and keep the schema on fast storage.

Finally, run the login server, the game server and the database as separate processes even on one machine. That isolation is what lets you restart one without killing the others, and it is the same reason large servers eventually move the database to its own host.

Reference Spec Sheet by Server Size

The table below is a starting point, not a hard rule. Round up when your world is heavily scripted or your population is spiky.

These figures assume a reasonably optimized pack. A build with heavy custom scripts, dense spawns or a database on the same slow disk will need more of everything.

Where Owners Overspend and Underspend

The two common mistakes are opposite. Some owners buy a huge CPU and then run a 4 GB heap, so the world stutters while the processor idles. Others try to run 300 players on a 2-core VPS with 4 GB, then blame the pack when pathfinding and login queues choke.

Match RAM to population first, then give CPU enough headroom, then make sure the database is not fighting the game server for disk. Bandwidth is the piece most home setups get wrong, because upload is slow and shared. If you cannot control the link quality, no amount of CPU fixes siege lag.

Once your machine holds the population you target, the next step is getting players onto it. Add your world through the free server submission form, or take a VIP placement if you want more visibility from day one. You can also compare how other owners describe their rates and setup in the server directory.