A reliable Metin2 lag fix starts with a truth most server owners learn the hard way: "lag" is not one problem. When players complain, they may actually be describing three different issues — high ping (network delay), low FPS (client side), or the server processing commands too slowly (server tick delay). Any change made without separating these either does nothing or creates a new problem. In this guide I show how to diagnose the delay correctly first, then resolve it step by step on the server and network side.
Diagnose first: where does the lag come from?
Before touching anything, measure the source numerically. "Feeling it" is not enough; ping, packet loss and server load are three separate metrics.
- Network delay: the round-trip time from player to server. If in-game ping is high for everyone, it is likely server location or routing; if it is high only for individual players, it is their connection.
- Packet loss: disconnects, teleporting and that "rubber-banding" feeling usually come from packet loss, not from raw ping.
- Server load: if one CPU core is pinned at 100%, the game logic (core/db) processes commands late; the game feels "heavy" even when ping is low.
On a Linux-based VPS, your first stop is live resource usage:
htop # CPU/RAM breakdown, which process is loaded
mpstat -P ALL 2 # per-core CPU (is a single core maxed out?)
ss -s # open socket/connection summary
Metin2 emulators tend to run the game logic heavily on a single core. Even if total CPU shows 25%, if one core sits at 100% that core is your bottleneck.
Measuring network delay
Instead of trusting the in-game number, measure ping at the network layer. mtr is more useful than ping and traceroute because it shows both the average delay and the hop where packet loss begins:
mtr -rwzbc 100 PLAYER_IP
# -c 100: send 100 packets, the average becomes more reliable
# look at the Loss% and Avg columns on the last line
If packet loss starts not at the first hops but at some provider in the middle of the route, the problem is not your server but the transit network; in that case you open a ticket with your hosting provider to fix the route. Consistently high ping is usually a geographic distance problem: if most of your players are in one region, moving the server to a nearby data center delivers a cleaner gain than any software tweak ever could.
Server side: core and database bottlenecks
The two most common causes of load-driven lag are quest/AI loops and slow database queries.
- Heavy quests:
when ... beginblocks that run many times per second per player — especially those using loops and frequenttimercalls — choke the CPU. Make constantly triggered quests event-driven instead. - Unindexed queries: if large tables like
playeroritemlack indexes, every query does a full table scan. In MySQL, see the slow queries explicitly:
-- under my.cnf: slow query log
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1 # catch queries longer than 1 second
If you see a repeating query in the log, inspect its plan with EXPLAIN; if you see type: ALL, add an index on that column. If you use InnoDB, setting innodb_buffer_pool_size to 50-70% of server RAM noticeably reduces disk-I/O stalls.
Network stack and connection settings
The game sends small real-time packets, so kernel network parameters and the firewall matter. On Linux, a full connection-tracking table (conntrack) can cause new connections to be rejected and trigger sudden lag waves:
sysctl net.netfilter.nf_conntrack_count # current record count
sysctl net.netfilter.nf_conntrack_max # upper limit
# if you are near the limit, raise it permanently (/etc/sysctl.conf):
# net.netfilter.nf_conntrack_max = 262144
A DDoS protection layer or a misconfigured iptables rule may also be delaying legitimate game packets. Review rules that rate-limit the game port; filtering the UDP/TCP mix incorrectly leads to silent packet drops.
Client side: lag or low FPS?
Some "lag" reports have nothing to do with the server. If the player's screen stutters but ping is low, the issue is FPS. You can have the player check this quickly:
- Try borderless windowed mode instead of full screen.
- Update the graphics driver and run the game as administrator.
- Dropping FPS in crowded areas (market, boss) is normal; the fix is a client setting, not the server.
The diagnostic rule is simple: low ping + stuttering screen = client/FPS, high or jumping ping = network, everyone freezing at once = server.
Set up permanent monitoring
Fixing lag once is not enough; you need to see it instantly when it returns. Even a simple log tracking CPU, RAM and player count over time pays off. As a lightweight option you can install Netdata, or take a per-minute sample with a cron job:
* * * * * uptime >> /var/log/load.log
# when does load average peak? does it line up with player density?
This data turns vague complaints like "everyone lags at 9 PM" into a measurable pattern and lets you find the real bottleneck.
Frequently Asked Questions
My ping is low but the game still stutters, why?
Low ping shows the network path is fast, but it does not guarantee the server processes commands on time. 100% CPU on a single core or slow database queries make the game feel "heavy" even with low ping. Check the server side with htop and the slow query log.
Do I have to move my server to a closer location?
If the vast majority of your players are geographically far from the server, yes — no software tweak can fully remove latency caused by physical distance. First measure real ping with mtr; if it is consistently high, a closer data center is the most definitive fix.
What causes sudden lag spikes?
The most common causes are a full conntrack table, a periodic heavy cron/backup job, or crowded events triggered at certain hours. Match the lag time to the peak in your load log to find the trigger.
Can't pin down the source of lag on your server? I can help diagnose the network, kernel and database side together and produce a lasting performance setup — get in touch with me.