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.
| Sunucu RAM'i | Önerilen buffer pool |
|---|---|
| 8 GB | 2 GB |
| 16 GB | 4-6 GB |
| 32 GB | 8-12 GB |
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.
[mysqld]
innodb_buffer_pool_size = 4G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2
max_connections = 200innodb_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.
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. 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; aynı lokasyonda ikinci bir sunucu almak tek makinede kaynak büyütmekten daha iyi sonuç verir.