Scapă de lag pe serverul tău de Minecraft

„Lag” înseamnă trei lucruri diferite în Minecraft și doar unul dintre ele e vina serverului. Află pe care îl ai înainte să schimbi ceva, apoi ia remediile de mai jos cam în ordine: primele nu costă nimic și ajută aproape orice server.

Lag de server, ping sau FPS?

Serverul rulează jocul în tick-uri, de 20 de ori pe secundă când totul e în regulă. Asta e TPS-ul, adică tick-uri pe secundă. Fiecare tick are 50 de milisecunde; când durează mai mult, TPS-ul scade sub 20 și toată lumea din joc încetinește.

Serverele noastre sunt în București, așa că jucătorii departe de România vor avea mereu ping mai mare, iar nicio setare de server nu schimbă asta. FPS-ul se calculează în întregime pe calculatorul jucătorului; acolo ajută propriul render distance sau un mod de client ca Sodium, nu ceva de pe server.

Ca să verifici TPS-ul, scrie asta în pagina Console din panel:

tps
mspt

tps merge pe Paper, Purpur și Spigot și arată media pe ultimele 1, 5 și 15 minute. mspt e o comandă Paper care arată câte milisecunde durează un tick; constant sub 50 înseamnă că serverul ține pasul. Dacă TPS-ul stă fix pe 20 și jucătorii tot se plâng, problema e pingul sau FPS-ul. Altfel, notează-ți valorile înainte să schimbi ceva, ca să știi dacă fiecare remediu de mai jos chiar a ajutat.

Folosește Paper sau Purpur

Software-ul serverului contează mai mult decât orice setare. Paper e un fork de Spigot care repară multe părți lente din Minecraft vanilla și rulează aceleași plugin-uri Bukkit și Spigot, așa că pentru un server cu plugin-uri rareori ai motiv să rămâi pe Spigot. Purpur e construit peste Paper și adaugă opțiuni de gameplay în plus în purpur.yml. Oricare dintre ele e alegerea potrivită pentru majoritatea serverelor de survival.

Vanilla nu are plugin-uri și nici îmbunătățirile astea. Folia împarte lumea pe mai multe nuclee de procesor, ceea ce ajută puțin pe un plan cu unul sau două nuclee, iar majoritatea plugin-urilor nu o suportă. Pe Fabric, moduri de server ca Lithium și FerriteCore fac o treabă asemănătoare cu modificările din Paper.

Schimbi software-ul din pagina Versions a panelului. Fă întâi un backup și citește ghidul de schimbare a versiunii, pentru că schimbarea software-ului atinge tot serverul.

Scade view-distance și simulation-distance

Aceste două setări din server.properties decid cât din lume ține serverul încărcat în jurul fiecărui jucător. simulation-distance e cea scumpă: în interiorul ei mobii se mișcă, plantele cresc și redstone-ul merge. view-distance controlează doar cât de departe văd jucătorii. Ambele sunt implicit 10, iar munca crește cu pătratul distanței, așa că și o scădere mică economisește mult.

Un punct de plecare rezonabil pe un plan mic e un simulation-distance în jur de 6 și un view-distance în jur de 8. Schimbă-le din pagina Configs, dă restart și compară TPS-ul cu valorile notate. Coboară mai mult doar dacă tot e nevoie. Ghidul despre server.properties arată unde sunt ambele setări.

Pregenerează lumea cu Chunky

Generarea de teren nou e unul dintre cele mai grele lucruri pe care le face un server. De fiecare dată când cineva explorează, mai ales zburând cu elytra, serverul construiește chunk-uri noi în timp ce rulează și jocul. Pregenerarea lumii elimină costul ăsta: generezi o zonă o singură dată, cât nu se joacă nimeni, iar explorarea de mai târziu doar încarcă chunk-uri care există deja.

Instalează plugin-ul Chunky, de exemplu din Plugin Manager, și dă restart. Apoi pune o graniță a lumii, spune-i lui Chunky s-o umple și pornește treaba din consolă:

worldborder set 6000
chunky worldborder
chunky start

worldborder set 6000 face un pătrat lat de 6.000 de blocuri, cu centrul în coordonatele 0, 0. chunky pause și chunky continue opresc și reiau generarea. Începe cu o dimensiune modestă: o graniță mai mare durează mult mai mult și ocupă mai mult spațiu pe disc. Generarea merge doar cât serverul e pornit, așa că ține panelul deschis și reînnoiește la timp, cum explică ghidul despre reînnoire. Granița lumii îi ține pe jucători în zona deja generată.

Profilează cu spark

Când TPS-ul e mic și nu știi de ce, spark îți spune. Versiunile recente de Paper îl includ, așa că poți folosi direct comanda spark; pe alte servere, instalează spark ca plugin sau mod. Pornește un profil cât timp e lag, lasă-l să meargă câteva minute, apoi oprește-l:

spark profiler start
spark profiler stop

spark îți răspunde cu un link spre un raport. Deschide-l și uită-te la ce ia cel mai mult timp în tick-ul serverului: numele unui plugin, un tip de entitate, hoppere sau alt block entity. Așa știi ce să repari, în loc să ghicești. spark health îți dă un rezumat rapid cu TPS, durata tick-urilor, memorie și procesor.

Ferme de entități și redstone

Cel mai greu lag de pe serverele de survival vine din lucruri construite de jucători. Suspecții obișnuiți:

• Fermele de mobi care strâng sute de mobi fără să-i omoare.
• Grămezile de iteme de la ferme pe care nu le golește nimeni. Mii de iteme aruncate pe jos costă timp real la fiecare tick.
• Halele de villageri. Villagerii au un pathfinding scump, iar o hală de trade cu zeci de villageri se adună.
• Lanțurile de hoppere și ceasurile de redstone care merg tot timpul, și când nu e nevoie.

Vorbește întâi cu cei care le-au construit: o cameră de omorât mobii, un buton de oprire sau un capac pe fermă ajung de obicei. Paper și Spigot au și setări pentru asta, cum ar fi entity-activation-range în spigot.yml și spawn-limits în bukkit.yml, amândouă editabile din pagina Configs. Schimbă o singură valoare o dată și măsoară din nou după aceea.

Citește graficele de resurse din panel

Pagina Console arată trei grafice: CPU Usage, Memory Usage și Inbound / Outbound, adică traficul de rețea. Limita de procesor apare în procente, unde 100% înseamnă un nucleu: 125% pe Lite, 150% pe Turbo și 180% pe Max.

• Procesorul stă la limită și TPS-ul e mic înseamnă că serverul are nevoie de mai mult timp de procesor decât îi dă planul. Profilează întâi cu spark; de multe ori de vină e o singură fermă sau un singur plugin.
• Memoria aproape de maxim e normală pentru Java. Torchlite îi dă lui Java un heap egal cu RAM-ul planului minus o rezervă fixă pentru ce ține Java în afara heap-ului (1088 MB pe Lite la Paper), iar Java îl umple înainte să facă curat. Când nu e nimeni online, dă înapoi memoria nefolosită după câteva minute. Devine o problemă doar când consola arată OutOfMemoryError sau serverul crapă.
• Traficul de rețea explică rar lag-ul pe un server mic.

După ce serverul merge de mai mult de cinci minute, panelul arată și un banner Low on resources când procesorul, memoria sau discul trec de 95% din limită.

Când merită un plan mai mare

Treci pe un plan mai mare doar după remediile gratuite: Paper sau Purpur, distanțe mai mici, o lume pregenerată și un profil spark în care nu mai e nimic evident de reparat. Dacă procesorul tot stă la limită cu doar câțiva jucători online sau consola raportează mereu OutOfMemoryError, serverul are nevoie de mai mult loc.

Pentru Paper, Purpur, Spigot, Fabric și Folia, planurile sunt Lite și Turbo. Turbo are de două ori mai mult RAM decât Lite și 1,5 nuclee în loc de 1,25, dar cere reînnoire la 40 de minute în loc de 50. Forge și NeoForge rulează doar pe Max. Planul se alege când creezi serverul, așa că trecerea pe unul mai mare înseamnă un server nou pe planul mai mare, în care îți copiezi lumea și plugin-urile prin SFTP.

Probleme frecvente

TPS-ul e 20, dar jucătorii tot sunt trași înapoi

Serverul ține pasul, deci problema e rețeaua. Roagă jucătorul afectat să încerce cu cablu sau din altă rețea. Jucătorii departe de București vor avea mereu ping mai mare decât cei apropiați.

Lag-ul începe de fiecare dată când explorează cineva

Asta e teren nou care se generează. Pregenerează lumea cu Chunky și pune o graniță a lumii, ca explorarea să rămână în zona deja generată.

Vârfuri de lag la fiecare câteva minute

Vârfurile regulate coincid des cu salvarea lumii sau cu o sarcină programată a unui plugin. Fă un profil spark care prinde mai multe vârfuri; raportul arată ce rulează în timpul lor.