Sunucunuzda Gizli Kalan I/O Darboğazı

Minecraft Java 1.20.5+ sunucularında kaydetme anındaki donmaları aşmak ve disk/CPU dengesini optimize etmek için teknik bir rehber.

Minecraft sunucu sahipleri için hazırladığım "Bölge Dosyası Sıkıştırması" konusunu profesyonel bir sunum haline getirdim.

Sunumda;

• Sıkıştırma algoritmalarının (deflate, LZ4, gzip) teknik karşılaştırmaları,

• Sunucu kaynaklarına göre doğru algoritma seçim karar ağacı,

• Güvenli geçiş adımları ve performans ölçüm kriterleri,

• Hibrit chunk yapısı ve yaygın teknik yanılgılar

gibi kritik başlıklar, izometrik ve modern bir tasarımla yer almaktadır.

Sunucunuzda Gizli Kalan Ve Bir Türlü Çözülemeyen TPS Düşüşlerinin Gizli Sebebi:

Sunucunuzda farkında olmadan bir I/O darboğazı yaşıyor olabilirsiniz. Bu ayar, oyuncuya giden paketleri değil, dünya verisinin diske yazılma şeklini belirliyor. Özellikle büyük dünyalarda ve otomatik yedekleme öncesi yaşanan kaydetme sıçramalarında bu ayar kritik bir rol oynar. Çözüm her zaman render distance düşürmek değildir; doğru sıkıştırma algoritmasını seçmek performansı artırabilir. Şimdi bu algoritma seçeneklerine daha yakından bakalım.

Doğru algoritma seçimi sunucu performansınız için çok önemli. Varsayılan deflate, disk alanı ve CPU kullanımı arasında dengeli bir başlangıç noktası sunar. Eğer sunucunuzda CPU darboğazı yaşıyorsanız, LZ4 disk alanı karşılığında daha az CPU kullanır. Paper sunucularında gzip, daha fazla alan odaklı bir seçenek olarak karşımıza çıkıyor, ancak sürüm bağımlılığı nedeniyle test etmeniz şart. Son olarak, none seçeneği, dosya sistemi düzeyinde sıkıştırma kullanan ileri seviye kurulumlar dışında genellikle önerilmez. Peki, bu seçeneklerden hangisi sizin için en uygun?

İşte bu sorunun cevabı için bir karar ağacı. Öncelikle sunucunuzun asıl darboğazını belirlemelisiniz: CPU zamanı mı, yoksa disk alanı mı? Eğer CPU zamanı ve kaydetme sıçramaları sorununuz varsa, LZ4'ü tercih edin. Disk alanı sizin için daha öncelikliyse, deflate veya Paper 26.1+ kullanıyorsanız gzip'i değerlendirin. Unutmayın, her değişikliği canlıya almadan önce staging ortamında test etmek, olası sorunların önüne geçer. Ancak bir şeyi bilmelisiniz, bu değişiklikler anında etki etmiyor.

Önceki slayttaki seçiminiz anında tüm dünyayı dönüştürmez. Bu çok kritik bir ayrım. Algoritmayı değiştirdiğinizde, yalnızca yeni veya güncellenen chunk'lar yeni biçimde yazılır. Eski chunk'lar eski biçimleriyle kalır. Bu yüzden bir süre hibrit bir dünya yapısı görmeniz normaldir. Ayar değişikliğinin hemen disk alanı kazandırmamasının nedeni de tam olarak budur. Peki, bu geçişi nasıl güvenli bir şekilde yaparız?

Güvenli bir geçiş için izlemeniz gereken adımlar basit ama önemli. İlk olarak, çalışan dünyanızın tam yedeğini alın ve sunucuyu durdurun. Ardından, server.properties dosyasında region-file-compression değerini değiştirin. Sunucuyu normal şekilde başlatın ve yeni chunk'ların yazılmasını gözlemleyin. Disk alanı, yoğun kaydetme anındaki CPU kullanımı ve en yüksek MSPT/TPS değerlerini ölçerek karşılaştırın. Başarı kriterimiz, disk alanı artışına rağmen MSPT sıçramalarının azalması ve TPS değerinin stabil kalmasıdır. Şimdi, tüm dünyayı yeniden yazmak her zaman gerekli mi, buna bakalım.

Kopyalanabilir Kod: java -jar paper.jar --forceUpgrade --recreateRegionFiles --nogui

Peki, tüm dünyayı yeni sıkıştırma formatına dönüştürmek istersek ne yapmalıyız? Bu işlem, özellikle büyük dünyalarda, dikkatli planlama gerektiren bir bakım operasyonudur. Mevcut chunk'ları yeni formata dönüştürmek için Paper'ın --recreateRegionFiles bayrağını kullanabilirsiniz. Ancak bu komutu çalıştırmadan önce mutlaka tam bir yedek alın ve canlı sunucunuzda denemeden önce bir test ortamında çalıştırın. Bu işlem yoğun CPU ve I/O kullanımı gerektirdiğinden, sadece oyuncu olmayan bir bakım penceresinde yapılmalıdır. Şimdi, bu optimizasyon sürecinde sıkça karşılaşılan yanlış anlamalara bir göz atalım.

Önceki slaytta bahsettiğimiz gibi, bu tür teknik ayarlamalar bazen yanlış beklentilere yol açabiliyor. Örneğin, region-file-compression ayarının oyuncunun pingini düşüreceğini düşünenler var; oysa bu ayar sadece disk üzerindeki bölge dosyalarını etkiler, ağ gecikmesini değil. Ayrıca, ayarı değiştirince dünyanın anında küçüleceğini beklemek de yaygın bir yanılgı. Unutmayın, eski chunk'lar yeniden yazılmadıkça eski biçimde kalır. Son olarak, LZ4 her sunucuda en iyi ayar değildir; daha az CPU kullanımı karşılığında daha fazla disk alanı tüketir. Bu nedenle, sunucunuzun ihtiyaçlarına göre doğru dengeyi bulmak çok önemli. Peki, tüm bu bilgileri nasıl bir sonuca bağlayabiliriz?

Gördüğünüz gibi, bölge dosyası sıkıştırması büyük dünyalarda önemli bir depolama stratejisidir. Ezbere ayarlar yerine, sunucunuzun gerçek iş yükünü ölçerek karar vermelisiniz. Eğer CPU baskısı yaşıyorsanız LZ4'ü, disk alanını korumak önceliğinizse deflate'i aynı yük altında ölçerek karşılaştırın. En önemlisi, kendi sunucunuzda yaptığınız testleri, sürümünüzü ve ölçümlerinizi toplulukla paylaşın. Gerçek iş yükü karşılaştırmaları, ezbere ayar listelerinden çok daha değerlidir.

Dikkat edilmesi gerekenler:
Sunucu bölge dosyası sıkıştırma ayarlarını uygularken hata yapmamanız ve en iyi verimi almanız için dikkat etmeniz gereken kritik noktaları aşağıda madde madde özetledim:

• Önce Tam Yedek Alın: Herhangi bir algoritma değişikliği yapmadan veya --recreateRegionFiles komutunu çalıştırmadan önce mutlaka dünyanızın (world klasörü) tam bir yedeğini alın. Veri bozulması riski düşük olsa da, geri dönüş planınızın olması hayat kurtarır.

• Sürüm Uyumluluğunu Kontrol Edin: region-file-compression ayarı Minecraft 1.20.5 ve üzeri sürümlerde mevcuttur. Eğer Paper kullanıyorsanız ve gzip seçeneğini deneyecekseniz, Paper 26.1 veya daha güncel bir sürüm kullandığınızdan emin olun.

• Donanım Kaynaklarınızı Tanıyın:

  • LZ4: CPU kullanımını düşürür ancak disk alanını %10-30 oranında artırır. Eğer CPU limitiniz varsa ve disk alanınız bolsa bu seçeneği kullanın.

  • Deflate: Varsayılandır, daha az disk alanı kaplar ama CPU'ya daha fazla yük bindirir.

• Hibrit Yapıya Hazır Olun: Ayarı değiştirdiğiniz an tüm dünyanız yeni formata dönmez. Sadece yeni keşfedilen veya oyuncuların etkileşime girip "değiştirdiği" chunklar yeni formatta kaydedilir. Bu yüzden disk boyutunda hemen bir değişim görmezseniz panik yapmayın.

• Canlı Sunucuda Deney Yapmayın: Ayar değişikliğinin performans etkisini (MSPT ve CPU kullanımı) önce bir staging (test) sunucusunda, benzer bir oyuncu yükü simülasyonu ile gözlemleyin.

• Bakım Penceresi Belirleyin: Eğer tüm dünyayı tek seferde yeni formata dönüştürmek için --recreateRegionFiles komutunu kullanacaksanız, bunu sunucu boşken ve planlı bir bakım saatinde yapın. Bu işlem yoğun I/O ve CPU tüketir.

• Ağ Gecikmesiyle Karıştırmayın: Bu ayarın oyuncuların ping değerine doğrudan bir etkisi yoktur. Ping sorunları için network-compression-threshold ayarına bakılmalıdır; bu rehberdeki ayar tamamen disk üzerindeki veri depolama biçimiyle ilgilidir.

• Disk Türünüzü Göz Önünde Bulundurun: Eğer sunucunuz çok hızlı bir NVMe SSD üzerinde çalışıyorsa, sıkıştırmayı kapatmak (none) dosya sistemi düzeyinde sıkıştırma yoksa disk alanını hızla tüketebilir. I/O hızınız düşükse (HDD veya yavaş SATA SSD), LZ4 gibi hızlı açılan algoritmalar donmaları azaltabilir.

• Logları Takip Edin: Ayar sonrası sunucu başlatılırken konsolda herhangi bir "Bölge dosyası okunamadı" veya "Chunk hatası" mesajı olup olmadığını dikkatlice kontrol edin.

Bu kontrol listesi, sunucunuzu optimize ederken veri güvenliğini en üst düzeyde tutmanıza yardımcı olacaktır.


Konuda yer verilen bilgileri aşağıdaki kaynaklardan inceleyebilirsiniz.