Solution Lag Metin2 : réglage serveur et réseau

Une vraie solution lag Metin2 commence par une vérité que beaucoup d'administrateurs apprennent à leurs dépens : le « lag » n'est pas un seul problème. Quand les joueurs se plaignent, ils décrivent en réalité trois soucis différents — un ping élevé (latence réseau), un FPS bas (côté client) ou un serveur qui traite les commandes trop lentement (retard de tick serveur). Toute intervention faite sans distinguer ces trois cas reste inutile ou crée un nouveau problème. Dans ce guide, je montre comment diagnostiquer correctement le délai d'abord, puis le résoudre étape par étape côté serveur et côté réseau.

Diagnostiquer d'abord : d'où vient le lag ?

Avant de toucher à quoi que ce soit, mesure la source de façon chiffrée. « Le ressentir » ne suffit pas ; le ping, la perte de paquets et la charge serveur sont trois métriques distinctes.

• Latence réseau : le temps d'aller-retour du joueur au serveur. Si le ping en jeu est élevé pour tout le monde, c'est probablement la localisation du serveur ou le routage ; s'il est élevé seulement pour certains joueurs, c'est leur connexion.
• Perte de paquets : déconnexions, téléportations et sensation de « rubber-banding » viennent généralement de la perte de paquets, pas du ping brut.
• Charge serveur : si un cœur CPU est bloqué à 100 %, la logique de jeu (core/db) traite les commandes en retard ; le jeu paraît « lourd » même avec un ping bas.

Sur un VPS Linux, ton premier arrêt est l'utilisation des ressources en direct :

htop                 # répartition CPU/RAM, quel processus est chargé
mpstat -P ALL 2      # CPU par cœur (un seul cœur est-il saturé ?)
ss -s                # résumé des sockets/connexions ouvertes

Les émulateurs Metin2 ont tendance à faire tourner la logique de jeu surtout sur un seul cœur. Même si le CPU total affiche 25 %, si un cœur reste à 100 %, c'est lui ton goulot d'étranglement.

Mesurer la latence réseau

Au lieu de te fier au chiffre en jeu, mesure le ping au niveau réseau. mtr est plus utile que ping et traceroute car il montre à la fois le délai moyen et le saut (hop) où la perte de paquets commence :

mtr -rwzbc 100 IP_JOUEUR
# -c 100 : envoie 100 paquets, la moyenne devient plus fiable
# regarde les colonnes Loss% et Avg sur la dernière ligne

Si la perte de paquets commence non pas aux premiers sauts mais chez un fournisseur au milieu de la route, le problème n'est pas ton serveur mais le réseau de transit ; dans ce cas, ouvre un ticket chez ton hébergeur pour corriger la route. Un ping constamment élevé est souvent un problème de distance géographique : si la plupart de tes joueurs sont dans une même région, déplacer le serveur vers un centre de données proche apporte un gain plus net que n'importe quel réglage logiciel.

Côté serveur : goulots du core et de la base de données

Les deux causes les plus fréquentes de lag dû à la charge sont les boucles de quêtes/IA et les requêtes de base de données lentes.

• Quêtes lourdes : les blocs when ... begin qui s'exécutent plusieurs fois par seconde et par joueur — surtout ceux avec des boucles et des appels timer fréquents — étouffent le CPU. Rends les quêtes déclenchées en continu pilotées par événements (event-driven).
• Requêtes sans index : si de grandes tables comme player ou item n'ont pas d'index, chaque requête fait un scan complet de la table. En MySQL, vois les requêtes lentes explicitement :

-- dans my.cnf : journal des requêtes lentes
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1        # capture les requêtes de plus d'1 seconde

Si tu vois une requête récurrente dans le journal, inspecte son plan avec EXPLAIN ; si tu vois type: ALL, ajoute un index sur cette colonne. Si tu utilises InnoDB, régler innodb_buffer_pool_size à 50-70 % de la RAM du serveur réduit nettement les blocages dus aux E/S disque.

Pile réseau et réglages de connexion

Le jeu envoie de petits paquets en temps réel ; les paramètres réseau du noyau et le pare-feu comptent donc. Sous Linux, une table de suivi de connexions (conntrack) pleine peut faire rejeter les nouvelles connexions et provoquer des vagues de lag soudaines :

sysctl net.netfilter.nf_conntrack_count   # nombre d'enregistrements actuels
sysctl net.netfilter.nf_conntrack_max     # limite supérieure
# si tu approches la limite, augmente-la durablement (/etc/sysctl.conf) :
# net.netfilter.nf_conntrack_max = 262144

Une couche de protection DDoS ou une règle iptables mal configurée peut aussi retarder des paquets de jeu légitimes. Vérifie les règles qui limitent le débit du port de jeu ; filtrer incorrectement le mélange UDP/TCP entraîne des pertes de paquets silencieuses.

Côté client : lag ou FPS bas ?

Certains rapports de « lag » n'ont rien à voir avec le serveur. Si l'écran du joueur saccade mais que le ping est bas, le problème est le FPS. Tu peux le faire vérifier vite au joueur :

• Essayer le mode fenêtré sans bordure plutôt que le plein écran.
• Mettre à jour le pilote graphique et lancer le jeu en administrateur.
• Une chute de FPS dans les zones bondées (marché, boss) est normale ; le remède est un réglage client, pas le serveur.

La règle de diagnostic est simple : ping bas + écran saccadé = client/FPS, ping élevé ou instable = réseau, tout le monde gèle en même temps = serveur.

Mettre en place une surveillance permanente

Corriger le lag une fois ne suffit pas ; il faut le voir instantanément quand il revient. Même un simple journal suivant le CPU, la RAM et le nombre de joueurs dans le temps est rentable. Comme option légère, tu peux installer Netdata, ou prendre un échantillon par minute via une tâche cron :

* * * * * uptime >> /var/log/load.log
# quand la charge moyenne atteint-elle son pic ? correspond-elle à l'affluence ?

Ces données transforment des plaintes vagues comme « tout le monde lague à 21 h » en un schéma mesurable et te permettent de trouver le vrai goulot d'étranglement.

Questions fréquentes

Mon ping est bas mais le jeu saccade quand même, pourquoi ?

Un ping bas montre que le chemin réseau est rapide, mais ne garantit pas que le serveur traite les commandes à temps. Un CPU à 100 % sur un seul cœur ou des requêtes lentes rendent le jeu « lourd » même avec un ping bas. Vérifie le côté serveur avec htop et le journal des requêtes lentes.

Dois-je déplacer mon serveur vers un emplacement plus proche ?

Si la grande majorité de tes joueurs sont géographiquement loin du serveur, oui — aucun réglage logiciel ne peut supprimer entièrement la latence due à la distance physique. Mesure d'abord le ping réel avec mtr ; s'il est constamment élevé, un centre de données plus proche est la solution la plus définitive.

Qu'est-ce qui cause les pics de lag soudains ?

Les causes les plus fréquentes : une table conntrack pleine, une tâche cron/sauvegarde lourde périodique, ou des événements bondés déclenchés à certaines heures. Fais correspondre l'heure du lag au pic du journal de charge pour trouver le déclencheur.

Tu n'arrives pas à cerner la source du lag sur ton serveur ? Je peux t'aider à diagnostiquer ensemble le réseau, le noyau et la base de données et à produire un réglage de performance durable — contacte-moi.