Oyun sunucusu için MySQL performans ayarları

Roleplay sunucularında yoğun saat takılmalarının büyük kısmı CPU veya RAM yetersizliğinden değil, veritabanından gelir. İyi haber şu: bu, donanım almadan düzeltilebilen tek darboğaz.

Önce ölçün

Tahminle ayar değiştirmek yerine yavaş sorgu logunu açın:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SET GLOBAL log_queries_not_using_indexes = 'ON';

Yarım saniyeyi geçen her sorgu loglanır. Bir saat çalıştırıp loga bakmak, çoğu sunucuda sorunun tek bir sorguda olduğunu gösterir.

En yüksek getirili ayar: innodb_buffer_pool_size

InnoDB verinin sıcak kısmını bellekte tutar. Varsayılan değer (128 MB) oyun sunucusu için anlamsız derecede küçüktür.

Kural: sunucu RAM'inin %25-40'ı. Daha fazlasını vermek oyun sunucusunun belleğini alır ve net zarar üretir — MySQL'in tek başına çalıştığı bir makine değil bu.

Tablodaki değerler elinizdeki paketin RAM'ine göre okunur. Buffer pool'a da oyun süreçlerine de yer bırakmak için gereken bellek mevcut paketten büyükse, ayarı kurcalamak yerine RAM'i bir kademe yukarı almak daha kestirme yoldur; kaynakları tek tek seçip aylık tutarı sunucu yapılandırıcıda görebilirsiniz.

[mysqld]
innodb_buffer_pool_size = 4G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2
max_connections = 200

innodb_flush_log_at_trx_commit takası

Bu ayar bilinçli bir seçim gerektirir:

• `1` (varsayılan): her işlem diske yazılır. En güvenli, en yavaş.
• `2`: saniyede bir diske yazılır. Elektrik kesintisinde son ~1 saniye kaybedilir.

Oyun sunucusunda 2 genellikle doğru seçimdir: bir saniyelik oyuncu ilerlemesi kaybı, sürekli disk yazma gecikmesinden daha kabul edilebilir. Finansal veri tutuyorsanız 1'de kalın.

İndeks: gerçek sorunun bulunduğu yer

Ayarlardan önce bakılacak şey budur. ESX/QBCore gibi framework'lerin veritabanı şemaları sık sorgulanan kolonlarda indeks içermeyebilir:

EXPLAIN SELECT * FROM players WHERE identifier = 'license:abc';

Çıktıda type: ALL görüyorsanız tablo baştan sona taranıyor. 50.000 satırlık bir players tablosunda bu, her bağlanan oyuncu için 50.000 satır okumak demektir.

ALTER TABLE players ADD INDEX idx_identifier (identifier);

Tek bir indeks, bazı sunucularda tüm yoğun saat takılmasını ortadan kaldırır. Donanım büyütmeden önce bakılacak yer kesinlikle burasıdır.

Oyun döngüsü içindeki senkron sorgular

İkinci en sık sebep: sorgunun kendisi hızlı ama oyun döngüsü onu bekliyor. FiveM'de MySQL.Sync kullanımı ana iş parçacığını durdurur; MySQL.Async durdurmaz. Kod tarafındaki bu fark, hiçbir MySQL ayarıyla telafi edilemez. Oyuncu sayısına göre hangi paketin veritabanı ile oyun sürecini birlikte taşıdığı oyun sayfasında derli toplu duruyor: FiveM sunucu paketleri

Disk

MySQL'in iş yükü küçük rastgele okuma/yazmadır ve NVMe ile SATA SSD arasındaki fark burada yüzdelerle değil katlarla ölçülür (NVMe SSD nedir?). Aynı makinede oyun sunucusu da çalışıyorsa ikisi aynı diski paylaşır; iostat -x 1 çıktısında await milisaniye mertebesine çıkıyorsa darboğaz disktedir.

Ne zaman ayrı sunucuya taşımalı?

Pratik eşikler: FiveM/RedM'de 200-250 eşzamanlı oyuncu, Metin2'de 4 kanal veya 700-800 oyuncu. Bu noktadan sonra MySQL ile oyun süreçleri aynı belleği ve diski paylaştığı için ikisi birlikte yavaşlar; veritabanını aynı lokasyonda ikinci bir sanal sunucuya almak tek makinede kaynak büyütmekten daha iyi sonuç verir. Tek çekirdek performansını da doldurduysanız sıradaki adım fiziksel sunucudur: diskin ve belleğin tamamı tek iş yükünde kalır.

İlgili okuma

• Kaç vCPU ve kaç GB RAM gerekir?
• VDS mi fiziksel sunucu mu: hangisi uygun?