Metin2 Server İçin Hangi Sunucu Gerekir? VDS, Dedicated ve Donanım

Bir Metin2 sunucusu tek bir program değil, aynı makinede birlikte çalışan süreçlerdir: db çekirdeği, auth çekirdeği, her kanal için birkaç oyun çekirdeği ve MySQL. Her oyun çekirdeği oyun mantığını tek iş parçacığında yürütür; bu yüzden işlemcinin tek çekirdek hızı, çekirdek sayısından önce gelir. Bellek ise oyuncudan önce kanal sayısıyla büyür, çünkü her kanal bütün haritaları ve canavarları ayrıca yükler.

Bu yazıda "oyun çekirdeği" Metin2'nin game sürecini, "işlemci çekirdeği" CPU çekirdeğini anlatır. Süreç yapısı ve sınırlar oyun ve db çekirdeğinin kaynak kodundan, sayılar kanal yapısını gen.py ile üreten yaygın sunucu paketinden alındı; harita ve kanal düzeni farklı olan sunucularda rakamlar değişir.

Metin2 sunucusu hangi süreçlerden oluşur?

Varsayılan pakette altı süreç ve MySQL çalışır: db, auth, birinci kanalın üç oyun çekirdeği ve ch99. Her yeni kanal üç oyun çekirdeği daha ekler.

Paketle gelen derlemede açık olan port güvenliği, oyun çekirdeklerinin P2P bağlantısını yalnız aynı makineden kabul eder. Bütün oyun çekirdekleri bu yüzden tek makinede durur; sunucu büyüdükçe daha çok makine değil, daha güçlü bir makine gerekir. MySQL özel ağdaki ayrı bir makineye alınabilir, ama lonca işlemleri, krallık değiştirme ve bazı quest fonksiyonları MySQL'in yanıtını oyun döngüsünün içinde beklediği için aradaki gecikme doğrudan oyuna yansır. Port düzeni kanal ve portlar yazısında.

MySQL bağlantı sayısı da süreçlerden hesaplanır: her oyun çekirdeği ve auth 5, db çekirdeği 12 bağlantı açar. Varsayılan pakette bu 37 bağlantı eder. Kanal sayısı arttıkça MySQL'in max_connections değerini bu toplamla karşılaştır.

İşlemci: oyun çekirdeği başına yük

Oyun çekirdeği saniyede 25 tur atar. Her turda olaylar, canavar yapay zekâsı, ağ okuma ve yazma aynı iş parçacığında sırayla işlenir. Bir tur 40 milisaniyeyi aşarsa kaçan turlar arka arkaya çalıştırılır ve oyuncu bunu takılma olarak görür. Çekirdeğin MySQL için üç yardımcı iş parçacığı vardır, ama bunlar çoğu zaman veritabanının yanıtını bekler. Sonuç: bir oyun çekirdeği oyun mantığı için en fazla bir işlemci çekirdeğini doldurabilir ve sekiz yavaş çekirdek dört hızlı çekirdekten kötü sonuç verebilir.

Canavarlar her an çalışmaz. Bir canavarın yapay zekâsı yalnız çevresindeki bölgede oyuncu varken döner, oyuncu uzaklaşınca durur. İşlemci yükü bu yüzden canavar sayısını değil, oyuncuların nerede ve ne kadar kalabalık olduğunu izler. Varsayılan dağılımda yük şöyle toplanır:

• Birinci çekirdek üç krallığın birinci ve ikinci köylerini taşır; açılış gününde bütün yeni oyuncular buradadır.
• İkinci çekirdek kasma haritalarının çoğunu ve zindanları taşır; oyuncular köylerden ayrıldıkça yükün çoğunun buraya kayması beklenir.
• Üçüncü çekirdek yüksek seviye haritalarını, ch99 yalnız etkinlikleri taşır. auth ve db zirve anları dışında sakindir.

Köylerin tek çekirdekte toplanması açılışın darboğazıdır. Krallıkların köylerini MAP_ALLOW satırlarıyla ayrı çekirdeklere dağıtmak ilk günün yükünü birden fazla işlemci çekirdeğine yayar. Satırların yazımı CONFIG ayarları yazısında.

Belleği neler tüketir?

share/bin/game dosyası 86 MB görünür, ama belleğe yüklenen kod ve veri yaklaşık 13,5 MB'tır; dosyanın 70 MB'tan fazlası hata ayıklama bilgisidir ve çalışırken belleğe alınmaz. Belleği dosya değil, çalışan dünya doldurur:

• Haritalar ve canavarlar. Çekirdek açılır açılmaz kendi haritalarını ve bu haritalardaki bütün canavarları, hiç oyuncu olmasa da, belleğe yükler. Regen, boss ve stone dosyalarındaki adetlerle grup boyutları toplandığında varsayılan pakette birinci çekirdek yaklaşık 15 bin, ikinci 33 bin, üçüncü 13 bin canavar ve metin taşıyla açılır. İkinci bir kanal bu yaklaşık 61 bini, yani bütün dünyayı belleğe ikinci kez koyar. Dosyaların biçimi regen dosyaları yazısında.
• Bağlantılar. Her bağlantı için 128 KB çıkış ve 64 KB giriş tamponu ayrılır. Bir çekirdek en fazla 4.096 bağlantı kabul eder; bu sınırda yalnız tamponlar 768 MB eder.
• Karakterler. Oyuncunun karakteri, eşyaları ve quest durumu oyundayken çekirdekte durur. Karakter ve eşyalar ayrıca db çekirdeğinin önbelleğinde, oyuncu çıktıktan sonra da 10 dakika tutulur.
• MySQL. Tablolar MyISAM'dır. MyISAM yalnız indeksleri kendi önbelleğinde (key_buffer_size) tutar, veriyi işletim sisteminin dosya önbelleğinden okur; süreçlere gitmeyen bellek boşa gitmez, veritabanını hızlandırır.

Bir sınır daha var: game ve db 32 bit programlardır ve her biri en fazla 4 GB adres alanı kullanabilir. Makinenin belleği bunu aşabilir, tek bir çekirdek aşamaz. Çok kalabalık haritaları tek çekirdekte toplamak yerine çekirdeklere bölmek bu yüzden de gerekir.

Disk ve veritabanı

Disk yükünü MySQL yazımları, günlük dosyaları ve yedekler belirler. db çekirdeği değişen karakter verisini yaklaşık 7, eşyaları 5 dakikada bir toplu yazar; log veritabanına DB_LOG_LEVEL seviyesine göre sürekli satır eklenir. Bu küçük ve dağınık yazımlar için SSD, sabit diskten çok daha uygundur.

Günlüklerde iki şeye dikkat et:

• Paketle gelen derlemede açık olan ENABLE_SYSLOG_PACKET_SENT, çekirdeğin gönderdiği her paket için syslog'a bir satır yazar. Kalabalık bir çekirdekte syslog'u en hızlı büyüten şey budur; tanımı kapatıp derlemek hem disk hem işlemci yükünü azaltır (service.h özellikleri).
• syslog her saat log/YYYYAAGG klasörüne taşınır ve her gün 3 gün önceki günün klasörü silinir. syserr hiç taşınmaz, temizlenene kadar büyür. Çöken bir çekirdek kendi klasörüne süreç belleği büyüklüğünde bir .core dosyası bırakabilir.

Yarım saniyeyi aşan her sorgu syslog'a [QUERY : LONG INTERVAL satırıyla düşer. Bu satırlar çoğalıyorsa disk ya da MySQL yetmiyor demektir. Günlük satırlarının anlamı syserr mesajları, yedeklerin yer ihtiyacı yedekleme yazısında.

İşletim sistemi: FreeBSD mi Linux mu?

Paketteki game ve db, FreeBSD 11.4 i386 üzerinde derlenmiş statik 32 bit ikililerdir; Linux'ta çalışmazlar. FreeBSD'nin güvenlik sayfasına göre Ekim 2026'da desteklenen dallar 14 ve 15'tir, 11.x çoktan desteğin dışındadır. FreeBSD 15 ile i386 donanım platformu kaldırıldı; 32 bit uygulamalar 64 bit sistemde uyumluluk kipiyle çalışmaya devam eder. Bu yüzden güncel ve doğru seçim 64 bit (amd64) FreeBSD 14 ya da 15'tir. Statik ikililer bu kiple ek kitaplık istemeden çalışır.

Quest derleyicisi qc ise 32 bit ve dinamik bağlıdır; libstdc++.so.6, libm.so.5, libgcc_s.so.1 ve libc.so.7 kitaplıklarının 32 bit kopyalarını ister. Bunları sunucuya kurmak istemiyorsan questleri ayrı bir derleme ortamında derleyip yalnız object klasörünü taşıyabilirsin; derlenmiş quest dosyaları düz metindir.

Linux'ta çalıştırmak için kaynak kodun uyarlanması gerekir: olay döngüsü FreeBSD'nin kqueue arayüzünü, Makefile'lar FreeBSD yollarını ve BSD sed biçimini kullanır. Derleme ortamı source derleme yazısında. Pakette Windows için bir sunucu ikilisi yoktur.

Ağ ve konum

Oyuncular auth'un ve bütün oyun çekirdeklerinin PORT'larına doğrudan bağlanır; P2P, db ve MySQL portları yalnız makinenin içinde kalır. Oyun çekirdeği UDP dinlemez, trafik tamamen TCP'dir. Ağ arabiriminde genel IP görünmeyen sanal sunucularda oyunculara bildirilecek adresin ayarlanması gerekir (server kurulumu).

Sunucuyu seçerken iki şey öne çıkar: oyuncuların çoğunun bulunduğu ülkeye düşük gecikme ve barındırmanın saldırı koruması. Bir saldırı, oyunun kendi trafiğinden çok daha fazla bant genişliği tüketebilir; hat kapasitesini bu yüzden korumayla birlikte değerlendir. Koruma türleri DDoS ve altyapı güvenliği yazısında.

VDS mi, dedicated mı?

Oyun çekirdekleri tek iş parçacıklı olduğu için VDS seçiyorsan işlemcisi paylaşılmayan ve tek çekirdek hızı belli olan bir paket seç. Ölçümü boş saatte değil, yoğun saatte yap.

Oyuncu sayısına göre başlangıç yapısı

Beta için canlıda kullanacağın sınıfta bir makine kullan ki ölçtüğün sayılar açılışta da geçerli olsun. Bellek için tek bir rakam yerine şu ölçümü yap:

1. Bütün çekirdekler açıldıktan sonra, oyuncu yokken her sürecin bellek kullanımını not et (top ya da ps RES sütunu). Bu, haritaların ve canavarların sabit payıdır.
2. Betada belli bir saatte herkesi oyuna çağır; çekirdeklerin bellek artışını ve işlemci yüzdesini izle. Yüzde 100'e yaklaşan oyun çekirdeği tek iş parçacığının sınırına gelmiştir.
3. db klasöründeki usage.txt, saatlik ortalama ve en yüksek çevrimiçi sayısını yazar (clear.py bu dosyayı da siler). İkinci adımda ölçtüğün bellek artışını o saatteki en yüksek oyuncu sayısına böl ve hedef oyuncu sayınla çarp; MySQL ve işletim sisteminin dosya önbelleği için ayrıca pay bırak.
4. Kanal ekleyeceksen birinci adımdaki sabit payı kanal sayısıyla çarp.

Açılış takvimi ve yük provası açılış planı yazısında.