„E lag!” e probabil mesajul pe care îl vei citi cel mai des pe Discord. Problema e că lagul are multe cauze: procesorul e sufocat, memoria s-a umplut, discul nu mai face față, baza de date e blocată sau rețeaua e atacată. Fiecare cauză are alt remediu. Dacă ghicești, pierzi timp și bani (de exemplu cumperi un server mai mare când problema era un singur quest). În această lecție înveți să **măsori** înainte să repari.
uptime, top, vmstat și iostat și notează rezultatele. Cifrele îți arată vinovatul: procesor, memorie, disc sau bază de date.Cuvinte pe care le vei întâlni
| Cuvânt | Ce înseamnă |
|---|---|
| CPU (procesor) | „Creierul” serverului. Fiecare proces game consumă din el. |
| RAM (memorie) | Memoria rapidă. Când se umple, serverul începe să folosească discul în loc de RAM. |
| Swap | O parte din disc folosită ca memorie de rezervă. E de zeci de ori mai lentă decât RAM-ul. |
| I/O (disc) | Citirile și scrierile pe disc. MySQL și jurnalele scriu mult. |
| Load average | Câte procese „stau la coadă” la procesor, în medie. |
Pasul 1: Ce fel de lag e?
Înainte de orice comandă, pune două întrebări:
| Ce spun jucătorii | Unde cauți |
|---|---|
| Doar eu am lag, ceilalți nu | Calculatorul sau internetul jucătorului |
| Lag doar pe o hartă sau la un eveniment | Core-ul care ține harta (vezi monitorizarea proceselor) |
| Toată lumea, pe toate canalele | Serverul: procesor, memorie, disc, bază de date sau rețea |
| FPS mic, jocul se mișcă sacadat | De obicei clientul (placa video), nu serverul |
| Lag la ore fixe | Ceva programat: backup, cron, eveniment |
Notează ora exactă la care apare lagul. Fără oră, nu poți compara cu nimic.
Pasul 2: O privire rapidă cu uptime
uptime
sysctl hw.ncpuuptime afișează la final trei numere, de exemplu load averages: 3.10, 2.80, 2.50. Sunt media cozii la procesor în ultimul minut, ultimele 5 și ultimele 15 minute. sysctl hw.ncpu arată câte nuclee de procesor ai.
Regula simplă: dacă load average e mult peste numărul de nuclee (de exemplu 12 la 4 nuclee), procesorul nu mai face față sau procesele așteaptă după disc.
Pasul 3: Cine consumă procesorul și memoria, cu top
top -aS -o cpuPe FreeBSD, -a arată comanda completă, -S include și procesele sistemului, iar -o cpu sortează după consumul de procesor. Ieși cu tasta q.
Ce citești:
- în listă, coloana
WCPU: cât procesor folosește fiecare proces. Un./gamela 100% e un core blocat sau supraîncărcat; - coloana
RES: câtă memorie folosește procesul. Dacă ungamecrește continuu de la o zi la alta, poate fi o scurgere de memorie (memory leak); - sus, rândul
Mem:arată memoria (Free= liberă), iar rândulSwap:arată cât swap e folosit.
Dacă Swap are valori folosite care cresc, RAM-ul nu mai ajunge. Poți verifica și separat:
swapinfo -hPasul 4: Memoria și procesorul în timp, cu vmstat
vmstat 1 5Afișează 5 rânduri, câte unul pe secundă. Coloanele de urmărit:
| Coloană | Ce înseamnă | Când e îngrijorător |
|---|---|---|
r | Procese care așteaptă procesorul | Constant peste numărul de nuclee |
fre | Memorie liberă | Foarte mică și scade |
pi / po | Pagini citite și scrise în swap | Diferite de 0, constant |
us / sy | Procent procesor folosit de programe / sistem | us aproape de 100 |
id | Procent procesor liber | Aproape de 0 |
Pasul 5: Discul, cu iostat și df
iostat -x 1 5
df -hiostat -x arată fiecare disc. Pe FreeBSD, coloana %b e cât la sută din timp discul a fost ocupat, iar ms/w cât durează în medie o scriere. Un disc ocupat aproape 100% din timp, minute în șir, încetinește MySQL și deci salvările jocului.
df -h arată spațiul liber. Un disc plin nu dă lag, dă blocaj: MySQL nu mai poate scrie. Cauze frecvente: syslog uriaș, fișiere core, backupuri vechi uitate pe server.
Pasul 6: Baza de date
Dacă procesorul și discul arată normal, dar salvările merg greu, uită-te în MySQL:
SHOW FULL PROCESSLIST;Comanda arată ce face MySQL chiar acum. În pachetul verificat, tabelele folosesc motorul MyISAM, care blochează tot tabelul la scriere. Dacă vezi multe rânduri cu Waiting for table level lock, cineva ține un tabel ocupat. De multe ori e o interogare grea pornită de site-ul serverului (clasamente) sau un backup rulat la ora de vârf.
Pasul 7: Rețeaua
Dacă totul pare liniștit pe server, dar toată lumea are lag sau deconectări, poate fi rețeaua sau un atac. Vezi traficul în timp real:
netstat -w 1Afișează pachetele intrate și ieșite în fiecare secundă (oprești cu Ctrl+C). Un salt uriaș față de o zi normală e suspect. Citește protecția DDoS pentru Metin2 și vorbește cu firma de hosting.
Pasul 8: Înregistrează, nu ghici
Lagul trece adesea până apuci să te loghezi. Fă-ți un mic obicei: când apare, rulează comenzile și salvează rezultatul cu ora:
date >> ~/lag.txt
uptime >> ~/lag.txt
top -b -o cpu 15 >> ~/lag.txt
vmstat 1 5 >> ~/lag.txt
iostat -x 1 3 >> ~/lag.txttop -b scrie o singură „fotografie” în fișier în loc să rămână deschis, iar 15 înseamnă primele 15 procese. După câteva episoade, compari fișierele și vezi tiparul.
Tabel rapid: ce vezi → ce înseamnă
| Ce vezi | Probabil | Ce faci |
|---|---|---|
Un game la 100% WCPU | Core supraîncărcat sau blocat | Vezi ce hărți ține, ce eveniment rulează, citește syserr |
| Swap folosit care crește | RAM insuficient sau leak | Compară RES în timp; restart planificat, apoi investigație |
%b aproape 100% la disc | Disc lent sau prea multe scrieri | Mută backupurile în afara orelor de vârf, micșorează jurnalele |
Waiting for table level lock | Tabel blocat | Găsește interogarea grea (site, backup) |
| Totul normal, dar lag general | Rețea sau atac | Verifică traficul, contactează hostingul |
Greșeli des întâlnite
- Cumperi server mai mare fără măsurători. Dacă vina e un quest sau un tabel blocat, lagul rămâne.
- Măsori după ce lagul a trecut. Cifrele vor arăta normal. Măsoară în timpul problemei.
- Rulezi backupul la ora de vârf. Discul și MySQL se ocupă exact când joacă cei mai mulți.
- Uiți de
syslog. Jurnalele care cresc cu GB pe zi ocupă discul și îl țin ocupat.
Întrebări frecvente
Comenzile sunt aceleași ca pe Linux?
Nu toate. Pe FreeBSD, top, vmstat și iostat au alte opțiuni și alte coloane decât pe Linux, iar free nu există. Folosește variantele din această lecție.
Un restart rezolvă lagul?
Uneori, temporar. Dacă e o scurgere de memorie, lagul revine după câteva zile. Restartul cumpără timp, nu rezolvă cauza.
Câtă memorie îi trebuie unui server Metin2?
Depinde de numărul de canale, core-uri și jucători. Vezi cerințele unui server Metin2.
Ce urmează
Când știi ce trebuie reparat, îl repari într-o fereastră planificată. Lecția următoare: cum pregătești o mentenanță fără pierderi. Toate lecțiile sunt în lista tutorialelor Metin2.
Server Metin2 gata de joc
Găzduire Metin2 în România, cu instalare de serverfiles, bază de date MySQL și protecție Anti-DDoS inclusă.