VDS’de RAM, CPU ve Disk Yükseltme Zamanı

VDS’de RAM, CPU ve disk yükseltme kararı, sunucu yönetiminin en pahalı tahmin oyunudur. “Sunucu ağırlaştı, bir paket üstüne geçelim” cümlesi kulağa mantıklı gelir ama çoğu zaman yanlış kaynağı büyütmeye yol açar. Destek taleplerinde en sık gördüğümüz şey de bu: RAM yükseltilmiş, fatura artmış, TPS aynı yerde durmaktadır.

Doğru yaklaşım basit. Önce ölçün, sonra yorumlayın, en son yükseltin. Bu rehberde yük ortalamasını çekirdek sayısına bölerek nasıl okuyacağınızı, free -h çıktısındaki bellek doluluğu ile önbellek farkını, disk bekleme süresini ve takas kullanımının ne zaman kırmızı çizgi olduğunu gerçek çıktılar üzerinden göreceksiniz. Ardından hangi belirtinin hangi darboğaza işaret ettiğini gösteren bir teşhis tablosu ve yükseltme günü için kesinti planı var.

Komut örnekleri Linux üzerinden verilmiştir. Windows Server kullanıyorsanız aynı metrikleri Görev Yöneticisi’nin Performans sekmesinden, Kaynak İzleyici’den (resmon) ve PowerShell’in Get-Counter komutundan okuyabilirsiniz; yorumlama mantığı birebir aynıdır.

Yükseltme Kararı Neden Hisle Verilemez?#

“Yavaşlık” tek bir şey değildir. Oyuncular için gecikme demektir, web sitesi ziyaretçisi için geç açılan sayfa, panelde bakan yönetici için ise kırmızı bir grafik. Bu üç şikâyetin altında tamamen farklı üç darboğaz olabilir ve hepsinin çözümü aynı değildir.

Bir sunucuda dört temel kaynak yarışır: işlemci zamanı, bellek, disk giriş/çıkışı ve ağ. Bunlardan biri sınıra dayandığında diğerleri de yavaş görünür. Disk beklemesi yükselince CPU grafiği de tırmanır, çünkü süreçler işlemciyi tutup disk cevabı bekler. Bu yüzden tek bir grafiğe bakıp karar vermek yanıltıcıdır.

Ölçmediğiniz bir darboğazı yükselterek çözemezsiniz; yalnızca faturayı büyütürsünüz.

Kalıcı bir izleme sisteminiz yoksa işe oradan başlayın. Tek seferlik komut çıktıları anlık fotoğraf verir, oysa yükseltme kararı için eğilim gerekir: değer ne zaman yükseliyor, oyuncu sayısıyla mı ilişkili, yedekleme saatinde mi zıplıyor? Sunucu izleme ve monitoring rehberindeki kurulum bir akşamınızı alır ve sonraki tüm kararları veriye bağlar.

Yük Ortalamasını Çekirdek Sayısına Bölerek Okumak#

Yük ortalaması, çalışan ve çalışmayı bekleyen süreçlerin ortalama sayısıdır. Yüzde değil, adet. Bu yüzden “yük 6” tek başına hiçbir şey ifade etmez; 4 çekirdekli bir sunucuda felaket, 16 çekirdekli bir sunucuda rahat bir gündür.

# Yük ortalaması: 1, 5 ve 15 dakikalık
uptime
#  21:14:07 up 42 days,  3:11,  1 user,  load average: 6.42, 5.88, 4.13

# Çekirdek sayısı
nproc
# 8

# Ham hâli
cat /proc/loadavg
# 6.42 5.88 4.13 3/412 20841

Bu örnekte 6,42 / 8 = 0,80 çıkar. Yani sistem kapasitesinin yaklaşık %80’ini kullanıyor ve henüz kuyruk oluşmuyor. Üç değerin sırası da önemlidir: 15 dakikalık ortalama 4,13 iken 1 dakikalık 6,42 ise yük artıyor demektir. Tersi olsaydı geçmiş bir tepe noktasından iniyor olurdunuz.

Bellek Doluluğu ile Önbellek Farkı: free -h Nasıl Okunur?#

Linux’ta bellek okumak, ilk kez bakan herkesi yanıltan bir konudur. Çünkü işletim sistemi boşta duran RAM’i israf sayar ve okunan dosyaları orada tutar. Sonuç olarak sağlıklı bir sunucuda bile bellek neredeyse “dolu” görünür.

free -h
#                total        used        free      shared  buff/cache   available
# Mem:            15Gi       9.1Gi       412Mi        18Mi       6.2Gi       5.8Gi
# Swap:          4.0Gi       128Mi       3.9Gi

Buradaki free sütunu 412 MiB gösteriyor ve panik yaratıyor. Oysa gerçek gösterge o değil. Sütunları tek tek açalım:

used

Uygulamaların gerçekten tuttuğu bellek. Java heap’i, veritabanı, web sunucusu süreçleri buradadır.

free

Hiçbir işe koşulmamış, tamamen boş bellek. Bu değerin düşük olması normaldir, hatta iyidir.

buff/cache

Disk önbelleği. Uygulama bellek isterse çekirdek burayı anında boşaltır. “Kaybedilmiş” bellek değildir.

available

Asıl bakılacak sütun. Takasa gitmeden, yeni bir uygulamaya verilebilecek bellek miktarı.

Örnekteki sunucuda available değeri 5,8 GiB, yani toplamın yaklaşık %38’i. Bu sunucunun RAM sorunu yok. Aynı çıktıda available 800 MiB olsaydı (%5 civarı) durum bambaşka olurdu.

# Yalnızca available yüzdesini hesapla
free | awk '/Mem:/ {printf("Kullanilabilir bellek: %%%.0f\n", $7/$2*100)}'
# Kullanilabilir bellek: %38

# Belleği en çok tüketen 8 süreç
ps -eo pid,comm,%mem,rss --sort=-rss | head -9
#   PID COMMAND         %MEM    RSS
#  2041 java             52.1 8412208
#  1108 mariadbd          9.4 1518044
#  1442 nginx             0.6  102340

Takas (Swap) Kullanımı Başladıysa#

Takas alanı, RAM dolduğunda çekirdeğin sayfa taşıdığı disk bölümüdür. NVMe disk bile RAM’den kat kat yavaştır; takasa düşen bir uygulamada gecikme nanosaniyeden mikrosaniyeye sıçrar. Oyun sunucusunda bu, oyuncuların anında hissettiği donmalar demektir.

Ama dikkat: free -h çıktısında görünen 128 MiB’lik statik takas kullanımı tek başına alarm değildir. Sistem, günlerdir dokunulmamış sayfaları oraya taşımış olabilir. Kırmızı çizgi, akıştır.

# si = takastan okuma, so = takasa yazma (KB/s)
vmstat 2 5
# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
#  3  1 131072 421884 118004 6182144   84  212    18   940  842 1503 61  6 24  9  0
#  4  2 148992 398120 118004 6104928  128  396     4  1120  980 1721 64  7 19 10  0

# Takas alanları ve doluluk
swapon --show
# NAME      TYPE SIZE USED PRIO
# /swapfile file   4G 145M   -2

# Hangi süreç takasa düşmüş?
for f in /proc/*/status; do awk '/^Name|^VmSwap/{printf $2" "} END{print ""}' "$f"; done | sort -k2 -hr | head -5

so sütunu ölçüm boyunca sürekli sıfırdan büyük çıkıyorsa sistem aktif olarak RAM boşaltmaya çalışıyordur. Bu noktada yapılacak şey ayar değil, RAM eklemektir. Takas alanını büyütmek sorunu çözmez, yalnızca yavaşlığı uzatır.

Disk: Doluluk Değil, Bekleme Süresi#

Disk konusunda iki ayrı problem vardır ve karıştırılırlar. Birincisi alan bitmesidir, ikincisi hızın yetmemesi. İlkini df gösterir, ikincisini iostat.

df -h
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/nvme0n1p2  196G  171G   16G  92% /

# Yeri kim yiyor?
sudo du -h --max-depth=1 / 2>/dev/null | sort -hr | head -6

# Disk gecikmesi ve doygunluk (sysstat paketi gerekir)
sudo apt install -y sysstat
iostat -x 2 3
# Device  r/s   w/s   rkB/s   wkB/s  r_await  w_await  aqu-sz  %util
# nvme0n1 42.0 318.5  1204.0 18942.0    0.42    14.86    4.21   96.4

Bu çıktıda üç sayı konuşur. %util diskin meşgul olduğu sürenin yüzdesidir; sürekli %90 üzerindeyse disk doygundur. w_await yazma isteğinin ortalama bekleme süresidir (milisaniye); NVMe bir diskte 1 ms altı beklenirken 14,86 ms görüyorsanız ya disk gerçekten dolmuştur ya da altta paylaşımlı bir depolama vardır. aqu-sz ise kuyruk uzunluğudur, 1’in üzerindeki değerler istekler sıraya giriyor demektir.

CPU tarafındaki karşılığı wa sütunudur. vmstat ya da top çıktısında iowait sürekli çift haneliyse darboğaz işlemci değil disktir ve daha güçlü bir CPU almak hiçbir şeyi değiştirmez.

Hangi Kaynak Darboğaz? Teşhis Tablosu#

Ölçümleri aldıysanız karar tablosu şu şekilde işler. Satırları yukarıdan aşağıya kontrol edin; ilk uyan satır sizin durumunuzdur.

Minecraft’ta Çekirdek Eklemek Neden İşe Yaramaz?#

Bu, oyun sunucusu yönetenlerin en pahalı yanılgısıdır. “TPS düştü, 8 çekirdekten 16’ya çıkalım” denir, fatura ikiye katlanır, TPS aynı kalır. Sebebi mimaridir: Minecraft’ın ana tick döngüsü tek bir iş parçacığında çalışır ve o iş parçacığı aynı anda yalnızca bir çekirdek kullanabilir.

Bunu kendi sunucunuzda görmek çok kolay:

# Java sürecinin iş parçacıklarını CPU kullanımına göre listele
top -H -p $(pgrep -f "paper.jar")

#   PID USER      PR  NI    VIRT    RES  %CPU  %MEM COMMAND
#  2049 minecraft 20   0   12.3g   8.2g  98.7  52.1 Server thread
#  2061 minecraft 20   0   12.3g   8.2g   6.2  52.1 Netty Server IO
#  2062 minecraft 20   0   12.3g   8.2g   4.1  52.1 Chunk Executor
#  2070 minecraft 20   0   12.3g   8.2g   0.7  52.1 Paper Async Task

Server thread satırı %98’de otururken diğer iş parçacıkları boşta duruyorsa tablo nettir: sunucu tek çekirdeğe sıkışmıştır. Bu makineye 8 çekirdek daha eklerseniz o satır yine %98’de kalır. İşe yarayacak tek şey, o tek çekirdeğin daha hızlı olmasıdır. Ryzen 9 sınıfı yüksek frekanslı işlemcilerin oyun sunucularında öne çıkmasının sebebi de tam olarak budur.

Çekirdek sayısı yine de tamamen işlevsiz değildir. Chunk üretimi, otomatik yedekleme, Dynmap gibi eklentilerin arka plan işleri ve aynı makinede çalışan veritabanı ek çekirdeklerden faydalanır. Yani çekirdek “ana döngü için değil, yanındaki işler için” alınır.

Yükseltmeden Önce: Optimizasyon Kontrol Listesi#

Yükseltme düğmesine basmadan önce şu listeyi bitirin. Çoğu sunucuda listenin yarısı bile yükseltme ihtiyacını ortadan kaldırır; kalanı da yükseltmeden alacağınız verimi artırır.

1. Heap değerlerini pakete göre ayarlayın#

   RAM artırdıysanız Java heap’i de artırın, yoksa yeni bellek boşta durur. 8 GB pakette -Xms6G -Xmx6G, 12 GB pakette -Xms10G -Xmx10G, 16 GB pakette -Xms14G -Xmx14G verin. Xms ve Xmx daima eşit olmalı; işletim sistemine de pay bırakın.

2. View distance ve simulation distance değerlerini gözden geçirin#

   Bu iki ayar, tick başına işlenen chunk sayısını doğrudan belirler. Tek bir kademe düşürmek bazen tüm yükseltmeden daha çok fark yaratır: view distance ayarları.

3. Eklenti listesini budayın#

   Kullanılmayan her eklenti tick süresinden pay alır. spark raporunda ilk beşe giren eklentileri tek tek sorgulayın; gerçekten gerekli mi, daha hafif bir alternatifi var mı?

4. Entity ve item yoğunluğunu sınırlayın#

   Yerde biriken eşyalar, kontrolsüz hayvan çiftlikleri ve hopper zincirleri tick süresini şişirir. Sınır ayarları ve temizlik için sunucu optimizasyonu rehberini uygulayın.

5. Yedekleme ve pregen saatlerini kaydırın#

   Yoğun saatte çalışan bir yedekleme görevi diski doygunluğa iter ve “sunucu akşamları yavaşlıyor” şikâyeti üretir. Bu işleri oyuncu sayısının en düşük olduğu saate alın.

6. Günlükleri döndürün#

   Dönmeyen bir latest.log ya da Nginx erişim günlüğü haftalar içinde gigabaytlara ulaşır. Hem disk yer, hem yazma yükü üretir.

Listeyi bitirdikten sonra ölçümleri tekrarlayın. Değerler hala kırmızıysa artık yükseltme gerçekten gereklidir ve bu kez neyi neden yükselttiğinizi biliyorsunuz.

Hangi Pakete Geçmeli?#

Yükseltme yönü belliyse hedef paket seçimi kolaylaşır. Aşağıdaki tablo oyun sunucuları için pratik bir başlangıç noktasıdır; web ve veritabanı yükleri için CPU satırı aynı kalır, RAM ihtiyacı uygulamaya göre değişir.

İşlemci seçiminde çekirdek sayısına değil saat hızına bakın. Düşük frekanslı, çok çekirdekli eski sunucu işlemcileri kâğıt üzerinde etkileyici görünür ama tek iş parçacığına bağlı yüklerde geride kalır. Aynı gerekçe disk için de geçerlidir: chunk okuma/yazma gecikmesi yüzünden NVMe dışında bir seçenek önerilmez. Donanım tarafındaki ayrıntılar için doğru donanım seçimi sayfasına bakabilirsiniz.

Kaynak ihtiyacınız tek bir VDS’nin sınırlarını zorluyorsa karar artık paket değiştirmek değil, sunucu tipini değiştirmektir. VDS mi dedicated sunucu mu karşılaştırması bu eşiği nasıl belirleyeceğinizi anlatıyor. Batihost tarafında 156 TL’den başlayan VDS paketleri ve yüksek frekanslı seçenekler arasında geçiş yapabilirsiniz; kaynak artırımı için destek talebi açmanız yeterli.

Yükseltme Günü: Kesinti Planlaması#

Kaynak yükseltmesi çoğu zaman yeniden başlatma gerektirir. Kesintinin kendisi kısa olsa da plansız yapıldığında veri kaybına dönüşebilir. Şu sıra işi güvenli hâle getirir:

1. Bakım penceresini belirleyin ve duyurun#

   Oyuncu sayısının en düşük olduğu saati seçin. Discord ve sunucu içi duyuruyla en az 24 saat önceden haber verin; MOTD’ye de yazın. Habersiz kesinti, kesintinin kendisinden daha çok şikâyet üretir.

2. Tam yedek alın#

   Yükseltme öncesi yedek isteğe bağlı değildir. Dünya klasörü, eklenti yapılandırmaları ve veritabanı dökümü ayrı ayrı alınmalı ve sunucunun dışına kopyalanmalıdır. Yöntem için yedekleme stratejileri sayfasındaki 3-2-1 kuralına bakın.

3. Snapshot alın#

   Sağlayıcınız destekliyorsa yükseltmeden hemen önce bir snapshot oluşturun. Bu, yanlış giden bir işlemden dakikalar içinde dönmenizi sağlar. Snapshot ile yedek arasındaki farkı snapshot, imaj ve yedek sayfasında bulabilirsiniz.

4. Sunucuyu düzgün kapatın#

   Süreci öldürmeyin. Minecraft için konsoldan stop, sistem servisi olarak çalışıyorsa sudo systemctl stop minecraft kullanın. Sert kapatma, kaydedilmemiş chunk’lar yüzünden bozuk dünya dosyası üretebilir.

5. Yükseltmeyi uygulayın ve doğrulayın#

   Sunucu açıldıktan sonra yeni kaynakların gerçekten göründüğünü kontrol edin: free -h, nproc, df -h. Disk büyütmesi yaptıysanız dosya sisteminin genişlediğinden emin olun; bölüm büyütülüp dosya sistemi genişletilmediğinde yeni alan görünmez.

6. Uygulama ayarlarını yeni kaynağa göre güncelleyin#

   Java heap, PHP-FPM havuz boyutu, veritabanı tampon havuzu gibi değerler elle ayarlanır. Bu adım atlanırsa yükseltme kâğıt üzerinde kalır.

7. 24 saat izleyin#

   Yükseltme sonrası ilk gün ölçümleri tekrar toplayın ve öncekiyle karşılaştırın. Beklenen iyileşme olmadıysa teşhis tablosuna dönün — yanlış kaynağı yükseltmiş olabilirsiniz.

Özetle#

Kaynak yükseltmesi bir tahmin değil, ölçüm sonucudur. Yük ortalamasını çekirdek sayısına bölün, bellekte used yerine available sütununa bakın, takasa yazma başladıysa RAM ekleyin, iowait çift haneliyse diske yönelin. Bu dört kontrol, yükseltme kararlarının neredeyse tamamını doğru yere oturtur.

Oyun sunucusu işletiyorsanız bir noktayı özellikle akılda tutun: çekirdek eklemek ana tick döngüsünü hızlandırmaz. Tek iş parçacığı doygunsa cevap saat hızıdır. Ve her yükseltmeden önce optimizasyon listesini bitirin — çünkü yanlış yapılandırılmış bir sunucu, iki katı donanımda da yanlış yapılandırılmış kalır. Yükseltme gününde ise sıralama hep aynı: duyuru, yedek, snapshot, düzgün kapatma, doğrulama.