Yükleniyor
In-memory cache altyapinizda tek cekirdek tikanikliklarini ve Linux Copy-on-Write (CoW) kaynakli OOM cokmelerini engelleyin. Redis, Valkey, KeyDB ve Dragonfly mimarilerini donanim ve maliyet acisindan kiyaslayin.
Tek Cekirdek (Single-Thread Event Loop)
Cok Is Parcacikli (Shared Memory Mutex)
Shared-Nothing Fiber Mimarisi (Lock-Free)
Dragonfly ve Valkey icin CPU limitleri, memlock ve ulimit optimizasyonlari.
# 2026 Production In-Memory Cache Karsilastirma Sablonu
# docker-compose.yml
services:
# 1. Dragonfly (Yuksek Throughput + Dusuk RAM + Sifir Fork CoW Riski)
dragonfly:
image: 'docker.dragonflydb.io/dragonflydb/dragonfly:latest'
container_name: dragonfly_cache
restart: unless-stopped
ulimits:
memlock: -1
ports:
- '6379:6379'
volumes:
- dragonfly_data:/data
command:
- '--maxmemory=26.2GB'
- '--proactor_threads=8'
- '--save_schedule=*:00' # Otomatik snapshot
- '--dbfilename=dump.rdb'
deploy:
resources:
limits:
cpus: '8'
memory: 31G
# 2. Valkey (Acik Kaynakli Redis Alternatifi)
valkey:
image: 'valkey/valkey:8.0-alpine'
container_name: valkey_cache
restart: unless-stopped
ports:
- '6380:6379'
volumes:
- valkey_data:/data
command: >
valkey-server
--maxmemory 40gb
--maxmemory-policy allkeys-lru
--io-threads 4
--save 900 1
--protected-mode yes
volumes:
dragonfly_data:
valkey_data:vm.overcommit_memory, somaxconn ve Transparent Huge Pages (THP) yonetimi.
# /etc/sysctl.d/99-cache-optimization.conf # 1. Linux bellek asiri tahsisine izin ver (Redis BGSAVE fork hatasini engeller) vm.overcommit_memory = 1 # 2. TCP baglanti kuyrugunu genislet (SYN Flood ve C10K tikanmalarina karsi) net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 32768 # 3. Transparent Huge Pages (THP) Redis gecikme sicramalarini onlemek icin kapatilmalidir # echo never > /sys/kernel/mm/transparent_hugepage/enabled # (Dragonfly THP'den olumsuz etkilenmez ancak Redis icin 'never' zorunludur)
Yillarca endustri standardi olan Redis, tek is parcacikli (single-threaded event loop) mimari uzerine kuruludur. Bu tasarim kucuk veri kumelerinde kilit cekismesini onleyerek yuksek tahmin edilebilirlik sunsa da, modern 16, 32 veya 64 cekirdekli AMD EPYC ve Intel Xeon sunucularda islemci kapasitesinin %90'ini atil birakmaktadir.
Redis 6 ile gelen ve Valkey 8 tarafindan surdurulen io-threads, yalnizca ag soketlerinden bayt okuma ve yazma islemlerini coklu is parcacigina dagitir. Komutlarin veritabani uzerinde islenmesi (SET, GET, HSET vb.) halen tek bir ana is parcaciginda (main thread) calisir. Bu durum, tek bir sunucuda 120.000 - 150.000 QPS seviyesinde tavan olusmasina yol acar. Daha yuksek throughput icin mecburen Redis Cluster (sharding) kurulumu yapilmalidir.
Dragonfly, modern C++20 ve Linux io_uring uzerine sifirdan insa edilmistir. Shared-nothingmimarisinde her CPU cekirdegi bagimsiz bir veri dilimini (slice) yonetir ve cekirdekler arasinda kilit (mutex lock) bulunmaz. Hafif siklet fiber yapisi sayesinde tek bir 64 vCPU sunucuda 4 milyon QPS seviyesine ulasabilir. Redis Cluster gibi 16 ayri sunucu acma gerekliligini ortadan kaldirir.
Geleneksel Redis, veri tabaninin snapshot'ini diske kaydederken (BGSAVE) veya AOF yeniden yazarken Linux fork() sistem cagrisini kullanir. Sunucuda yogun yazma (SET/DEL) islemleri devam ediyorsa, degisen her 4KB'lik bellek sayfasi kopyalanir (CoW). 32 GB RAM kullanan bir Redis sunucusu snapshot sirasinda aniden 50-55 GB RAM talep edebilir. Sunucuda bu kadar bos alan yoksa Linux oom-killer devreye girerek Redis surecini derhal sonlandirir. Dragonfly ise noktasal anlik goruntuleme (point-in-time snapshotting) kullanarak fork() cagirmaz; bu sayede CoW bellek siçramasi yasanmaz.
Redis, her anahtar icin bir dictEntry yapisi ve jemalloc tahsis basi overhead'i (ortalama 56-80 bayt) tutar. Milyonlarca kucuk anahtar barindiran sistemlerde bu metadata, verinin kendisinden daha fazla yer kaplar. Dragonfly'in gelistirdigi Dashtable algoritmasi, onbellek anahtarlarini onbellek satiri (cache-line) dostu kovalarda (buckets) sikistirarak saklar. Bu sayede ayni veri kumesi Dragonfly'da ortalama %22 ila %30 daha az RAM kaplar.