Yüksek Yük Altında Node Optimizasyonu: RAM, CPU, SSD

CPU: Mikrosaniye Savaşı ve Çekirdek İzolasyonu

Çoğu kişi nod çalıştırmak için sadece bolca çekirdeğin yettiğini sanır. Oysa işlemlerin işlenmesi ve konsensüs aşaması için asıl kritik olan tek çekirdek performansıdır (Single-Core Performance) ve context switch sırasındaki gecikmeleri minimuma indirmektir. Eğer işlemciniz sürekli güç tasarrufu modları arasında mekik dokuyor ya da nodun thread'ini bir çekirdekten diğerine fırlatıp duruyorsa, o çok değerli milisaniyeleri kaybedersiniz ve TPS tarafında çakılmalar başlar.

• 1. İşlemciyi Tam Savaş Moduna Almak

  Linux varsayılan olarak, yük düştüğü an CPU frekansını aşağı çeken powersave veya schedutil governor’larını kullanır. Yüksek yüklü bir nod için bu tam bir ölüm fermanıdır: İşlemci yeni bir bloğu işlemek için "uyanana" kadar ağ çoktan uçup gider.

  Vakit kaybetmeden tüm çekirdekleri kalıcı olarak maksimum performans moduna kilitliyoruz:

  cpupower frequency-set --governor performance

  Az bilinen ince bir detay: Intel işlemcili modern Linux kernellerinde intel_pstate governor'ı klasik ayarları görmezden gelebilir. En yüksek frekansı (Turbo Boost dahil) beton gibi sabitlemek için şu komutu çakmanız gerekir:

  echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
  # (Ters mantık: 0 değeri, Turbo Boost'un AÇIK ve sürekli aktif olduğu anlamına gelir)
  echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo

• 2. Çekirdekleri Nod İşlemine Rezerve Etmek (CPU Pinning)

  İşletim sisteminin scheduler'ı (zamanlayıcı) validatörün o ağır thread'ini farklı fiziksel çekirdekler arasında gezdirdikçe, CPU'nun L1/L2 önbelleği sürekli geçersiz kılınır (invalidate olur). Buna Cache Thrashing denir. Sistem süreçlerini 0 ve 1 numaralı çekirdeklere paslayıp, nodu tamamen belirli çekirdeklere çivileyeceğiz.

  Diyelim ki validator.service adında bir nod servisimiz var. Systemd konfigürasyonunda CPUAffinity ayarı yapmamız gerekiyor.

  [Service]
  # Süreci 0 ve 1'i pas geçerek doğrudan 2 ila 7 arasındaki fiziksel çekirdeklere bağlıyoruz
  CPUAffinity=2-7
  # Scheduler önceliğini en tepeye çekiyoruz (Realtime/FIFO ya da direkt maksimum Nice değeri)
  Nice=-20

RAM: OOM Killer'ı Evcilleştirmek ve HugePages Sihri

Blockchain nodlarında bellek adeta su gibi akar. Veri tabanları (LevelDB, RocksDB) State Tree'ye ait devasa miktardaki veriyi önbelleğe alır. Eğer RAM biterse, Linux hiç gözünün yaşına bakmaz ve OOM Killer üzerinden nod sürecinizi anında infaz eder.

• 1. Swap Ayarları ve Saldırgan Önbellekleme

  Hızlı SSD'ler varken swap'e gerek olmadığı efsanesini unutun. Swap şart, ama RAM'i genişletmek için değil, tamamen bir hava yastığı (emniyet kemeri) niyetine. Eğer nod aktif olarak swap kullanmaya (swapping) başlarsa, deli dehşet gecikmeler yüzünden konsensüsten direkt şutlanır.

  Sanal bellek alt sisteminin davranışını /etc/sysctl.conf dosyası içinden ayarlıyoruz:

  # Sayfaların swap'e taşınma eğilimini minimuma indiriyoruz (yalnızca gerçek bir RAM krizinde devreye girsin)
  vm.swappiness=10
  # Sistemi, dosya sistemi önbelleğini hafızada daha agresif tutmaya zorluyoruz
  vm.vfs_cache_pressure=50
  # Sistemin kirli sayfaları (dirty pages) diske yazmak için aniden donup kaldığı senaryoların önüne geçiyoruz
  vm.dirty_background_ratio=3
  vm.dirty_ratio=10

• 2. RocksDB/LevelDB İçin HugePages Aktifleştirme

  Linux'ta varsayılan bellek sayfa boyutu 4 KB'tır. Nod 500 GB'lık bir veri tabanıyla çalışırken sayfa tablosu (Page Table) devasa boyutlara ulaşır ve işlemci TLB (Translation Lookaside Buffer) miss'leri içinde boğulup zaman kaybeder. HugePages (2 MB veya 1 GB sayfa boyutu) mimarisine geçmek bellek erişim hızını uçurur.

  Desteği kontrol edip, runtime sırasında canlı canlı örneğin 2 MB'lık 2048 sayfa (toplamda 4 GB) ayırıyoruz:

  sysctl -w vm.nr_hugepages=2048

  Bunu kalıcı hale getirmek ve sistem boot edilirken ayrılmasını sağlamak için /etc/sysctl.conf dosyasına ekleyin:

  vm.nr_hugepages = 2048

  Ardından, nodunuzun konfigürasyon dosyasında (eğer RocksDB kullanan Go/Rust tabanlı custom bir client çalıştırıyorsanız) use_direct_reads=true flag'ini açmanız ve bellek ayırıcıyı (memory allocator) set etmeniz gerekir (örneğin standart glibc malloc yerine jemalloc kullanın; çünkü ağır yük altında bellek fragmantasyonunu çok daha iyi yönetir).

SSD/NVMe: Disk Alt Sistemini Hayatta Tutma Stratejileri

Disk, herhangi bir nodun en net darboğazıdır (bottleneck). Saniyedeki girdi-çıktı işlemi sayısı (IOPS) ve yazma gecikmesi (Latency), nodunuzun blokları zamanında valid edip edemeyeceğini belirler. Standart son kullanıcı (consumer) NVMe diskleri (en kral Samsung EVO serisi bile), Solana veya Ethereum gibi nodlarda TBW (Terabytes Written) ömrünü tükettiği için birkaç ay içinde elinizde kalır ve önbellek dolduğu an hız tarafları feci çakılır.

Nodlar İçin Disk Özelliklerinin Karşılaştırmalı Analizi

DWPD - Drive Writes Per Day (Garanti süresi boyunca diskin her gün kaç kez tamamen üzerine yazılabileceğini gösteren değer).

1. Dosya Sistemi Seçimi ve Bağlama (Mount) Parametreleri

RocksDB/LevelDB veritabanları için, eğer cerrah hassasiyetinde ince ayar (fine-tuning) yapmayı bilmiyorsanız ZFS kullanmayı direkt unutun. Çift önbelleğe alma (hem ZFS ARC hem de DB'nin kendisinde) ve CoW (Copy-on-Write) mekanizmasının getirdiği ekstra yük, uzun vadede IOPS değerlerinizi kelimenin tam anlamıyla çöp eder. Eski dostumuz EXT4 veya XFS bu senaryoda tek mantıklı seçimdir.

Diski bağlarken, gereksiz metadata güncellemelerini kapatan flag'ler kullanmanız şart. Node'un her nefes alışında dosyanın son erişim zamanını (last access time) diske tekrar tekrar yazmak, bu seviyede asla lüksümüz olmayan bir fuzuli masraftır.

/etc/fstab dosyasındaki doğru yapılandırma satırı:

UUID=disk-uuid-niz /mnt/node-data ext4 noatime,nodiratime,data=writeback,barrier=0,nobh,alloc_policy=contiguous 0 2

"Yüreği yetmeyenler" için parametrelerin detaylı dökümü:

• noatime,nodiratime — Dosya ve klasörlere erişim zamanlarının diske yazılmasını tamamen kapatır. Böylece arka planda dönen bir dünya asalak yazma (parasitic write) operasyonunu kökten kesmiş olursunuz.
• data=writeback — Dosya sistemi metadatasının, asıl veri diske basıldıktan sonra geriden gelerek yazılmasına izin veren moddur. Dikkat: Ani bir güç kesintisinde dosya sistemi yapısının (FS structure) bozulma riski vardır. Ama biz zaten UPS'li veya direkt Tier III sınıfı bir veri merkezinde çalışan, hataya dayanıklı (fault-tolerant) bir node setup'ı kuruyoruz, değil mi? Maksimum hız için bu trade-off'u gözümüz kapalı kabul ediyoruz.
• barrier=0 — Yazma bariyerlerini (write barriers) devre dışı bırakır. Bu flag, dosya sisteminin belirli aralıklarla disk önbelleğini (disk cache) zorla temizlemesini engeller. Güç kesintisi korumasına (Power Loss Protection, PLP) sahip enterprise-grade disklerde bu flag tamamen güvenlidir ve rastgele yazma (random write) performansında devasa bir hız artışı sağlar.

Network Stack: Milyonlarca Paket İçin Kernel Ayarları

Bir node, özünde tam bir ağ merkezidir (network hub). Diğer peer'larla sürekli aktif halde yüzlerce, hatta binlerce eşzamanlı TCP/UDP bağlantısı sürdürür. Standart bir Linux dağıtımı, sıradan bir ofis sunucusu veya ortalama bir web sitesi baz alınarak optimize edilmiştir. Bu yüzden ağda ani bir işlem (transaction) dalgası patladığında (hype anlarında), ağ tamponları (network buffers) saniyede taşar, node paket düşürmeye (drop) başlar ve konsensüsten koparak senkronizasyon dışı kalırsınız.

Kernele ait ağ parametrelerine, /etc/sysctl.conf dosyası üzerinden oldukça agresif dokunuşlar yapıyoruz:

# Maksimum açık dosya ve tanımlayıcı sayısı ("Too many open files" hatasına takılmamak için)
fs.file-max = 2097152
# Gelen ağ paketleri için maksimum kuyruk boyutunu artırıyoruz
net.core.netdev_max_backlog = 100000
# Bağlantı bekleyen soketlerin maksimum sayısı (backlog taşmasını önlemek için koruma)
net.core.somaxconn = 65535
# TCP tamponları için ince ayar (bayt cinsinden minimum, varsayılan ve maksimum boyut)
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# TIME_WAIT durumundaki soketlerin tekrar kullanılmasına izin veriyoruz
net.ipv4.tcp_tw_reuse = 1
# Boşta kaldıktan sonra TCP Yavaş Başlangıcı'nı (TCP Slow Start) kapatıyoruz — node her milisaniyede her zaman anında tepki vermeli
net.ipv4.tcp_slow_start_after_idle = 0

Dosyayı düzenledikten sonra, değişiklikleri canlı sistemde anlık olarak uygulamayı kesinlikle unutmayın:

sysctl -p

Node sürecini (process) arkada çalıştıran kullanıcı (örneğin: validator) için limitleri (limits) yukarı çekmeyi de atlamayın. /etc/security/limits.conf dosyasına şu satırları ekliyoruz:

validator soft nofile 1048576
validator hard nofile 1048576

Mimari Alpha Hack: WAL Klasörünü RAM-Diske Taşımak

Özel ve yüksek işleme kapasiteli (high-throughput) kurulumlar için çok az bilinen ama verimliliği muazzam bir stratejidir. İşlemsel (transactional) herhangi bir veritabanı (RocksDB dahil), işlemi onaylamadan önce operasyonu diske, yani WAL (Write-Ahead Log) loguna yazar. Bu senkronize bir işlemdir. Disk, "WAL yazıldı" raporunu dönene kadar süreç kilitlenir ve bekler.

Eğer sisteminizde bolca RAM varsa, sadece node'un wal dizini için küçük bir RAM disk (tmpfs) oluşturabilir, veritabanının asıl ağır yükünü (SST dosyalarını) ise Enterprise NVMe diskinizde bırakabilirsiniz.

mkdir -p /mnt/node-data/wal
mount -t tmpfs -o size=8G tmpfs /mnt/node-data/wal

• Risk: Sunucu yeniden başladığında veya kapandığında, RAM diskteki veriler saliseler içinde tamamen uçar.
• Çözüm: Günümüzdeki modern blockchain istemcilerinin (client) büyük çoğunluğu, ana diskteki SST dosya yapısı zarar görmediği ve WAL düzgün şekilde kapatıldığı ya da gözden çıkarıldığı sürece, yeniden başlatma esnasında snapshot'lardan veya peer'lardan senkronize olarak durumlarını (state) sorunsuzca kurtarabilir. Bu stratejiyi canlıya almadan önce, kullandığınız blockchain istemcisinin WAL loglarını tam olarak nasıl handle ettiğine dair dokümantasyonunu mutlaka hatmedin!

Gerçek Zamanlı Darboğaz (Bottleneck) Takibi

En kusursuz ince ayar (tuning) bile metrikleri sürekli takip etmiyorsanız çöp olmaya mahkumdur. Düğümünüz (node) ağın gerisinde kalmaya (lag çekmeye) başladığında, top veya htop gibi klasik araçlar genellikle %100 CPU yükü gösterir ama bu tamamen ters köşe bir sinyaldir. İşlemciniz aslında hiçbir şey yapmıyor, sadece diskten veya ağdan veri gelmesini beklerken boşta (idle) sayıklıyor olabilir.

Bir altyapı (infra) mühendisinin yatıp kalkıp dua edeceği, gözünü ayırmaması gereken asıl kutsal gösterge io_wait ve PSI (Pressure Stall Information) metrikleridir.

iostat Aracının Değerleri Nasıl Okunur?

Node en yoğun yük altındayken (peak load) iostat -xmd 1 komutunu ateşleyin ve şu iki kritik parametreye kilitlenin: %util ve await.

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme0n1           0.00     4.00 4500.00 1200.00   280.00    75.00   124.50     1.20    0.21    0.15    0.42   0.15  85.50

Kritik Performans Kaybı Sinyali: Eğer %util değeri %100'e yaklaşıyorsa diskiniz durmaksızın çalışmaktan can çekişiyor demektir. Fakat bundan çok daha ölümcül olanı await parametresidir (milisaniye cinsinden I/O isteklerinin ortalama işlenme süresi). Blockchain ağlarındaki enterprise-grade NVMe diskler için await değerinin hiçbir şekilde 0.5–1.0 ms sınırını aşmaması gerekir. Eğer buralarda 5.0–10.0 ms gibi rakamlar görüyorsanız, node fiziksel olarak yeni blokları diske yetiştiremiyor demektir; en nihayetinde desync olur ve active validator set dışına şutlanır.

Checklist: Canlı Ortam (Production) İçin Nihai Optimizasyon Matrisi

İşleri kolaylaştırmak adına, tüm kritik optimizasyon noktalarını tek bir çalışma tablosunda topladık. Node'u ayağa kaldırmadan önce herhangi bir bare-metal sunucuyu denetlemek (audit) için bu tabloyu kullanabilirsiniz.

Özetle: Açığı Olmayan Kusursuz Bir Mimari

Yüksek işlem hacimli (high-throughput) bir node'u optimize etmek, her zaman aşırı hız ile veri saklama güvenliği arasında bir ödünleşim (trade-off) yönetmektir. Dosya sisteminin yazma bariyerlerini kapatarak veya logları RAM diske taşıyarak, olası bir ani güç kesintisinde son birkaç saniyelik işlem verisini kaybetme riskini doğrudan üzerinize alırsınız. Ancak konsensüs hızının yüzlerce milisaniye ile ölçüldüğü modern Web3 dünyasında, üst sıralardaki validator'lar arasında kalmanın ve blok kaçırmadan istikrarlı bir uptime sağlamanın tek yolu bu agresif ayarları yapmaktır. Bu konfigürasyonları adım adım uygulayın, her zaman önce testnet ortamlarında test edin ve I/O izleme (monitoring) panellerinizden gözünüzü ayırmayın.