FiveM Sunucusunda Lag ve Düşük FPS Sorunları Nasıl Çözülür?

FiveM sunucu lag sorunu çoğu zaman üç nedenden birinden gelir: sunucunun ana iş parçacığını meşgul eden bir script, oyuncunun bilgisayarında FPS’i düşüren ağır bir script ya da model dosyası, ya da ağ tarafında yüksek ping, paket kaybı veya saldırı. Çözümün ilk adımı bu üçünü birbirinden ayırmaktır: sunucu konsolundaki hitch warning satırları sunucuyu, istemcideki resmon aracı oyuncunun bilgisayarını, ping ve paket kaybı değerleri ağı gösterir. Donanım ancak scriptler temizlendikten sonra hâlâ tek bir çekirdek dolu kalıyorsa suçludur.

Oyuncular “sunucu kasıyor” dediğinde bunun arkasında birbirinden çok farklı sorunlar olabilir: araçların ışınlanması, kapıların geç açılması, oyuncunun kendi ekranında FPS’in düşmesi. Aşağıdaki adımlar, belirtiyi ölçülebilir bir veriye çevirip kaynağını bulmanızı sağlar. Araçların ve mesajların adları, Ekim 2026’da FiveM’in resmi belgeleri, txAdmin’in kaynak kodu ve sunucu yazılımının (artifact 35245) kendisi incelenerek doğrulandı.

FiveM sunucu lag sorunu: önce teşhis

Ölçüme geçmeden önce sorunun ne zaman başladığını not edin: yeni bir script eklendikten, bir güncellemeden ya da oyuncu sayısı arttıktan sonra mı? Bu bilgi aramayı çoğu zaman tek bir kaynağa indirir. Altyapı kaynaklı nedenleri baştan elemek isterseniz FiveM server kiralama paketleri AMD Ryzen 9 işlemci, NVMe disk ve DDoS korumasıyla gelir. Her belirti için izlenecek yol şöyledir:

Sunucu tarafını ölçmek

Konsoldaki hitch warning satırları

FXServer’ın içinde üç ayrı döngü çalışır: oyun mantığının ve scriptlerin çalıştığı svMain, ağ trafiğini işleyen svNetwork ve varlık senkronizasyonunu yürüten svSync. Bunlardan biri zamanında dönemezse sunucu konsola bir uyarı yazar. Sunucu yazılımının içindeki mesaj metinleri şunlardır: server thread hitch warning, network thread hitch warning ve sync thread hitch warning; her birinin sonunda döngünün kaç milisaniye geciktiği yazar. Linux’ta tmux oturumundaki konsola bağlanarak bu satırları görebilirsiniz. Aşağıdaki satırlar, FiveM’in GitHub sayfasındaki bir hata kaydında yayımlanan gerçek bir sunucu günlüğünden alındı:

tmux attach -t fivem

fivem@oyun-sunucu:~$ tmux attach -t fivem
...
[ citizen-server-impl] Server list query returned an error: context deadline exceeded
...
[ citizen-server-impl] network thread hitch warning: timer interval of 382 milliseconds
[ citizen-server-impl] sync thread hitch warning: timer interval of 386 milliseconds
[ citizen-server-impl] server thread hitch warning: timer interval of 388 milliseconds

Nasıl okunur: server thread hitch warning satırı, svMain döngüsünün belirtilen süre boyunca takıldığını, yani bütün scriptlerin ve oyun mantığının o süre beklediğini gösterir. Tek tük satırlar, örneğin bir kaynak yeniden başlatılırken, olağandır. Aynı günlükte birkaç dakikada bir tekrar eden ya da yüzlerce milisaniyelik değerler ise oyuncuların hissettiği takılmadır. Uyarıların hemen öncesindeki satırlara bakın: ox_inventory’nin GitHub sayfasındaki bir kayıtta, kaynak yeniden başlatıldığı anda uyarı görülüyor:

03:07:05 PM [           resources] Started resource ox_inventory
03:07:05 PM [ citizen-server-impl] server thread hitch warning: timer interval of 203 milliseconds

Ana döngü çok uzun süre takılırsa sunucu Loop svMain seems hung! mesajını yazar; txAdmin sağlık kontrolleri başarısız olduğunda sunucuyu yeniden başlatır. Bu noktada sorun artık takılma değil, çökme döngüsüdür.

txAdmin performans grafiği

txAdmin’in ana sayfasındaki performans grafiği, sunucunun döngülerinin her turu ne kadar sürede tamamladığını zaman içinde gösterir. txAdmin’in kaynak koduna göre grafik svMain, svNetwork ve svSync için ayrı ayrı seçilebilir, varsayılan olarak svMain açılır ve ilk 12 saatte veriler 5 dakikalık aralıklarla tutulur. Takılmaların belirli saatlerde mi (örneğin akşam yoğunluğunda), yoksa bir yeniden başlatmadan sonra mı başladığını buradan görürsünüz. Grafikte kötüleşme oyuncu sayısıyla birlikte geliyorsa yük, belirli bir saatte ani geliyorsa zamanlanmış bir iş ya da script şüphelidir.

Profiler ile kaynak bazında ayrıntı

Hangi kaynağın, hangi dosyanın hangi satırının süre harcadığını FiveM’in yerleşik profil aracı gösterir. Resmi belgedeki kullanım şöyledir: sunucu konsoluna (ya da istemcide F8 konsoluna) kayıt komutunu yazın; belge iyi bir başlangıç noktası olarak 500 kareyi öneriyor. Kayıt sürerken durumu görebilir, bittiğinde profili kaydedebilirsiniz:

profiler record 500
profiler status
profiler saveJSON profil.json

Kaydedilen dosya, sunucunun başlatma dosyasının bulunduğu klasöre yazılır. Dosyayı kendi bilgisayarınıza alın, Google Chrome’da geliştirici araçlarını (Ctrl+Shift+I) açıp Performance sekmesinde sağ tıklayarak Load profile ile yükleyin. Sarı CPU zamanı grafiğindeki ani tepeler takılma anlarıdır; o kareye yakınlaşınca süreyi harcayan kaynağın adı, dosyası ve satır numaraları görünür. profiler view komutu profili doğrudan açmak için bir bağlantı verir; sunucu tarafında bağlantıyı Chrome’a kendiniz kopyalamanız gerekir.

İstemci tarafını ölçmek: FiveM resmon kullanımı ve cl_drawperf

Oyuncunun bilgisayarında FPS düşüyorsa sebep çoğu zaman istemci tarafında çalışan bir script ya da büyük bir model dosyasıdır. FiveM’in resmi belgelerine göre F8 konsolundaki resmon true komutu kaynak izleyicisini açar ve her kaynağın işlemci ve bellek kullanımını gösterir. resmon bir geliştirici komutudur: normal bir istemcide Access denied for command resmon hatası verir. Belgeye göre geliştirici modunu açmanın bir yolu, FiveM’i +set moo 31337 parametresiyle başlatmaktır; bu yüzden resmon’u genellikle sunucu sahibi ya da geliştirici kullanır.

resmon true
cl_drawperf true

resmon penceresindeki sütunlar FiveM’in kaynak kodunda şöyle tanımlıdır:

Kesin bir “şu değerin üstü kötüdür” kuralı yoktur, ama araç kendi renklendirmesini yapar: kaynak koduna göre CPU süresi 1 milisaniyenin altındaysa yeşil, 8 milisaniye ve üzerindeyse kırmızı gösterilir, aradaki değerler sarıdan turuncuya geçer. En verimli yöntem göreli karşılaştırmadır: tabloyu CPU msec sütununa göre sıralayın ve en çok süre harcayan ilk beş kaynağa odaklanın. cl_drawperf true ise ekranın köşesinde FPS, ping, paket kaybı (PL), işlemci ve ekran kartı kullanımını gösterir; normal komuttur ve her oyuncu kullanabilir.

Sunucunun işlemcisini çekirdek bazında okumak

FXServer’ın oyun mantığı ve scriptleri tek bir döngüde (svMain) çalıştığı için, sunucunun toplam işlemci kullanımı düşük görünürken bir çekirdek tamamen dolu olabilir. Bu yüzden işlemciyi çekirdek bazında okuyun. Windows’ta her dilde çalışan yol, işlemci sayaçlarını CIM üzerinden okumaktır. Testimizde bir çekirdeğe yapay yük verdiğimizde tablo şöyle göründü:

Get-CimInstance Win32_PerfFormattedData_PerfOS_Processor |
  Format-Table Name, PercentProcessorTime

PS C:\> Get-CimInstance Win32_PerfFormattedData_PerfOS_Processor |
>>   Format-Table Name, PercentProcessorTime

Name   PercentProcessorTime
----   --------------------
0                         3
1                       100
10                        3
11                        0
...
_Total                   10

PS C:\> 

Nasıl okunur: _Total satırı bütün çekirdeklerin ortalamasıdır ve burada yalnızca yüzde 10’dur; oysa 1 numaralı çekirdek tamamen doludur. Sunucunuzda FXServer yoğunken bir çekirdek sürekli 100’e yakın kalıyorsa ana döngü o çekirdeğin hızıyla sınırlıdır. İngilizce Windows Server’da aynı bilgiyi Get-Counter ile de alabilirsiniz; Türkçe Windows’ta sayaç adları çevrildiği için bu komut testimizde c0000bb8 hatasıyla çalışmadı:

Get-Counter '\Processor(*)\% Processor Time'

Linux’ta top komutunun iş parçacığı görünümü, FXServer’ın her iş parçacığını ayrı satırda gösterir. Linux’ta sunucu run.sh içindeki yükleyiciyle başladığı için süreci pgrep ile tam komut satırında (-f) aramanız gerekir. 1 tuşu çekirdekleri ayrı ayrı listeler; bir iş parçacığının %CPU değeri sürekli 100’e yakınsa aynı tek çekirdek darboğazından söz ediyoruz:

top -H -p "$(pgrep -of FXServer)"

Nedenler ve çözümler

FiveM server optimizasyon işinde nedenler, en sık görülenden en nadire doğru şöyle sıralanır.

Her karede çalışan döngüler (Wait(0))

FiveM scriptlerinde while true do ... Wait(0) end biçimindeki bir döngü her karede (sunucuda her turda) çalışır. Bir tuşa basılıp basılmadığını kontrol etmek gibi gerçekten her kare gereken işler dışında bu döngüler gereksiz yük oluşturur. Çözüm, bekleme süresini işin gerektirdiği kadar uzatmak (örneğin oyuncu bir bölgeye uzaksa 1000 ms) ya da döngü yerine olay (event) kullanmaktır. resmon’da sürekli yüksek CPU msec değeri gösteren kaynaklarda ilk bakılacak yer budur.

Yavaş veritabanı sorguları

oxmysql, kaynak koduna göre varsayılan olarak 200 milisaniye ve üzerinde süren sorguları konsola yazar. sd-phone kaynağının GitHub sayfasındaki bir kayıtta bu uyarı şöyle görünüyor:

11:46:23 AM [      script:oxmysql] [12.3.2-MariaDB-ubu2404] sd-phone took 595.8000ms to execute a query!

Uyarıda adı geçen kaynak sorgunun sahibidir. Sık görülen nedenler eksik indeks, büyüyen tablolar ve gereksiz yere sık çalışan sorgulardır. Sorgunun WHERE koşulunda kullanılan sütunlara indeks ekleyin, eski kayıtları temizleyin ve aynı veriyi her seferinde veritabanından okumak yerine bellekte tutun. Eşiği server.cfg içinde set mysql_slow_query_warning 100 gibi bir satırla düşürerek daha fazla sorguyu görünür yapabilirsiniz. Veritabanını sunucuyla aynı makinede ve NVMe diskte tutmak da gecikmeyi azaltır.

Ağır araç, harita ve kıyafet dosyaları

Yüksek çözünürlüklü dokulara sahip araçlar, büyük harita eklemeleri ve çok sayıda kıyafet paketi, oyuncuların bilgisayarında FPS’i ve yüklenme süresini düşürür; FiveM FPS düşüklüğü çözümü çoğu zaman bu dosyalardan geçer. resmon’daki Streaming sütunu hangi kaynağın ne kadar veri yüklediğini gösterir. Gerçekten kullanılmayan araç paketlerini kaldırın, dokuları küçültülmüş sürümlerini tercih edin ve büyük harita paketlerinin oyuncu sayısınıza uygun olup olmadığını test edin.

Açık kalan ve kullanılmayan kaynaklar

server.cfg içindeki her ensure satırı bir kaynağı başlatır; kullanılmayan bir scriptin döngüleri de çalışmaya devam eder. Kullanmadığınız kaynakların ensure satırlarını kaldırın ve yeni bir script ekledikten sonra performansın değişip değişmediğini txAdmin grafiğinden kontrol edin.

Eski artifact ve OneSync ayarları

Eski bir sunucu yapısı, sonraki sürümlerde giderilen performans sorunlarını taşıyabilir; resmi indirme sayfasındaki önerilen yapıyı kullanın. OneSync’in legacy modu, resmi belgelere göre performans sorunları ve görsel hatalar nedeniyle önerilmez; set onesync on kullanın. Belgeler bazı OneSync ayarlarının performansı artırabileceğini de belirtiyor; örneğin onesync_distanceCullVehicles araçlara mesafe ve görüş alanı ayıklaması uygular. Bu ayarları değiştirmeden önce bir test sunucusunda deneyin; senkronizasyon doğruluğunu da etkileyebilirler.

Ağ, ping ve saldırılar

Sorun yalnızca bazı oyuncularda yüksek ping ve paket kaybıysa sunucudan çok onların bağlantısıdır; cl_drawperf ile ping ve PL değerlerini kontrol edin. Herkes aynı anda kopuyorsa ya da sunucu konsolunda ağ döngüsüyle ilgili (network thread) uyarılar yoğunlaşıyorsa saldırı ihtimalini düşünün. Ağ kartını dolduran bir saldırı sunucunun içinden engellenemez; korumanın sağlayıcı tarafında, ağ seviyesinde olması gerekir.

Yazılımla çözülmeyen durum: donanım sınırı

Scriptleri temizlediniz, yavaş sorgular kalmadı, kullanılmayan kaynakları kapattınız ama oyuncu sayısı arttıkça server thread hitch warning satırları geri geliyor ve sunucunun bir çekirdeği sürekli %100’e yakın çalışıyorsa sınır donanımdır. FXServer’ın ana döngüsü tek bir iş parçacığında çalıştığı için çekirdek sayısını artırmak bu sınırı kaldırmaz; daha hızlı tek çekirdek performansı gerekir. Tek çekirdek performansının neden önemli olduğunu Ryzen VDS yazımızda ayrıntılı anlattık. Önem Bilişim’in FiveM paketleri bu yüzden AMD Ryzen 9 5950X, 5900X ve 3900X işlemcilerle ve NVMe diskle çalışır.

Paket önericisindeki tahmine göre ESX, QBCore ya da vRP tabanlı roleplay sunucuları için 16 oyuncuya kadar 6 GB, 32 oyuncuya kadar 8 GB, 64 oyuncuya kadar 16 GB ve 128 oyuncuya kadar 24 GB önerilir; hafif ve freeroam sunucularda aynı paketler daha fazla oyuncu taşır. Bu değerler tahminidir ve kaynak sayısına, araç ve harita paketlerine göre değişir. Daha kalabalık topluluklar için AMD Ryzen fiziksel sunucu seçeneği vardır.

Kontrol listesi

1. Sorunun herkeste mi, bazı oyuncularda mı olduğunu belirleyin.
2. Sunucu konsolunda hitch warning satırlarını ve hemen öncesindeki olayları arayın.
3. txAdmin performans grafiğinde kötüleşmenin hangi saatlerde başladığına bakın.
4. profiler record 500 ile bir profil alın ve süreyi harcayan kaynağı bulun.
5. İstemci FPS sorunlarında resmon’u CPU msec ve Streaming sütunlarına göre sıralayın.
6. oxmysql’in yavaş sorgu uyarılarını okuyun ve indeks ekleyin.
7. Kullanılmayan kaynakların ensure satırlarını kaldırın, artifact’ı güncelleyin.
8. İşlemciyi çekirdek bazında okuyun; tek çekirdek doluysa donanımı büyütün.

Başka bir oyun için sunucu arıyorsanız tüm oyun sunucusu paketlerini tek sayfada karşılaştırabilirsiniz. Sunucuyu sıfırdan kurmak için txAdmin ile FiveM server kurulumu, framework seçimi için ESX mi QBCore mu yazılarımıza bakabilirsiniz.

Sık Sorulan Sorular

FiveM sunucum neden kasıyor?

En sık neden, sunucunun ana döngüsünü (svMain) meşgul eden bir script ya da yavaş bir veritabanı sorgusudur; bu durumda konsolda server thread hitch warning satırları görürsünüz. Takılma yalnızca bazı oyuncularda ve FPS düşüklüğü şeklindeyse sebep istemci tarafındaki scriptler ya da ağır model dosyalarıdır. Yüksek ping ve kopmalar ise ağ sorunlarına işaret eder. Önce sorunun hangisi olduğunu ayırın.

resmon’da kaç ms normal?

Kesin bir sınır yoktur, ama resmon’un kendisi bir ölçek kullanır: FiveM’in kaynak koduna göre bir kaynağın ortalama süresi 1 milisaniyenin altındaysa yeşil, 8 milisaniye ve üzerindeyse kırmızı gösterilir. Daha verimli yaklaşım göreli karşılaştırmadır: tabloyu CPU msec sütununa göre sıralayın ve en çok süre harcayan ilk beş kaynağı inceleyin. resmon’un bir geliştirici komutu olduğunu ve geliştirici modu istediğini unutmayın.

Server thread hitch warning ne demek?

Bu uyarı, FXServer’da oyun mantığının ve scriptlerin çalıştığı ana döngünün (svMain) zamanında dönemediğini ve satırdaki milisaniye kadar takıldığını söyler. Bir kaynak yeniden başlatılırken görülen tek tük uyarılar olağandır. Sık tekrarlanan ya da yüzlerce milisaniyelik değerler ise oyuncuların hissettiği takılmadır; uyarının hemen öncesindeki satırlara ve profil aracına bakarak nedeni bulun.

Sorun sunucu donanımında mı, scriptlerde mi?

Önce scriptleri ölçün: profil aracı ve resmon süreyi harcayan kaynağı gösterir, oxmysql yavaş sorguları yazar. Bunları düzelttikten sonra oyuncu sayısı arttıkça hitch uyarıları geri geliyor ve işlemcinin bir çekirdeği sürekli yüzde 100’e yakın çalışıyorsa sınır donanımdır. FXServer’ın ana döngüsü tek iş parçacığında çalıştığı için bu durumda daha fazla çekirdek değil, daha hızlı tek çekirdek gerekir.

txAdmin performans grafiği nerede ve ne gösterir?

Grafik txAdmin’in ana sayfasındadır ve sunucu döngülerinin turlarını ne kadar sürede tamamladığını zaman içinde gösterir. txAdmin’in kaynak koduna göre svMain, svNetwork ve svSync döngüleri ayrı ayrı seçilebilir ve varsayılan olarak svMain açılır. Takılmaların belirli saatlerde mi, bir güncellemeden sonra mı başladığını görmek için kullanın.

Wait(0) neden performansı düşürür?

Lua scriptlerinde Wait(0) ile bekleyen bir döngü her karede çalışır. Her karede yapılması gerekmeyen bir işi bu şekilde çalıştırmak, oyuncu ya da sunucu tarafında sürekli işlemci zamanı harcar. Döngünün bekleme süresini işin gerektirdiği kadar uzatın ya da döngü yerine olay kullanın. resmon’da sürekli yüksek süre gösteren kaynaklarda ilk bakılacak yer bu döngülerdir.

Kaynaklar

• FiveM belgeleri: Using the Profiler
• FiveM belgeleri: Console Commands (resmon, cl_drawperf)
• FiveM belgeleri: Server Commands (OneSync ayarları)
• FiveM GitHub: hitch warning satırlarını içeren hata kaydı
• oxmysql (GitHub)

Önem Bilişim Teknik Ekibi · Son güncelleme: Ekim 2026