Giriş: 7.6 GB VPS’te Docker ile Swap Yangını
Bu sabah bilgisayar başına oturduğumda, sunucularımdan birinde beklenmedik bir performans düşüşüyle karşılaştım. 7.6 GB RAM’e sahip, nispeten mütevazı bir VPS üzerinde çalışan Docker konteynerlarımın aniden yavaşlaması ve hatta bazı servislerin erişilemez hale gelmesi oldukça can sıkıcıydı. Hızlı bir inceleme, sorunun temel kaynağının agresif swap kullanımı olduğunu gösteriyordu. Küçük bir VPS’te Docker ile swap kullanımı, performans sorunlarının yanı sıra sistemin kararsızlaşmasına yol açabilen ciddi bir problem. Özellikle belirli kernel modüllerinin eksikliği veya yanlış yapılandırılması durumunda, bu sorunlar daha da derinleşebiliyor.
Bu yazıda, bu tür bir senaryoda ne gibi adımlar izlediğimi, sorunun kök nedenini nasıl bulduğumu ve nihayetinde bir kernel yama (patch) ile çözüme ulaştığımı detaylıca anlatacağım. Amacım, benzer sorunlarla karşılaşan sistem yöneticileri ve geliştiricilere pratik bir rehber sunmak. Bu tür “kabus” senaryolarını yaşamamak için nelere dikkat etmemiz gerektiğini somut örneklerle açıklayacağım. Kendi deneyimlerimden yola çıkarak, bu sorunun sadece bir performans meselesi olmadığını, aynı zamanda sistem güvenliği ve kararlılığı açısından da kritik olduğunu gördüm.
Sorunun Tespiti: Agresif Swap Kullanımı ve Belirtiler
Sorunun ilk belirtileri oldukça belirgindi: web servislerine erişimde gecikmeler, veritabanı sorgularının anormal derecede uzun sürmesi ve genel sistem yanıt verme süresinin artması. htop gibi araçları çalıştırdığımda, CPU kullanımının anormal derecede yüksek olmadığını gördüm, ancak swap kullanımının sürekli olarak maksimum seviyede seyrettiğini fark ettim. Bu durum, sistemin fiziksel RAM’inin yetersiz kaldığını ve disk tabanlı swap alanını yoğun bir şekilde kullandığını gösteriyordu.
# Sunucuya bağlandıktan sonra ilk kontrol
free -hfree -h komutunun çıktısı beni şaşırttı. Yaklaşık 7.6 GB RAM’e sahip bir sistemde, swap kullanımının neredeyse tamamının dolu olması beklenmedik bir durumdu.
total used free shared buff/cache available
Mem: 7.5Gi 6.8Gi 150Mi 1.2Gi 500Mi 30Mi
Swap: 2.0Gi 1.9Gi 100MiBu tablo, sistemin ciddi bir bellek baskısı altında olduğunu ve sürekli olarak disk I/O’su yaptığını gösteriyordu. Docker konteynerlarının kendi bellek limitleri olsa da, ana host sisteminin genel bellek yönetimi de bu durumu etkiliyordu. Özellikle birden fazla konteynerın aynı anda yoğun bellek kullanması, ana makineyi swap yapmaya zorluyordu. Bu da doğal olarak tüm servislerin performansını düşürüyordu.
Kök Neden Analizi: Docker ve Kernel Arasındaki Dinamik
Sorunun swap kullanımına dayandığını tespit ettikten sonraki adım, bu durumun neden ortaya çıktığını anlamaktı. Genellikle Docker konteynerları, ana makinenin kaynaklarını paylaşır ve kendi içinde bellek limitlerine sahip olabilirler. Ancak, ana makinenin toplam belleği yetersiz kaldığında veya kernel’in bellek yönetimi ile ilgili bazı optimizasyonları eksik olduğunda, konteynerlar ana makineyi zorlayabilir.
Bu senaryoda, birkaç Docker konteynerı üzerinde çalışan uygulamalar (bir PostgreSQL veritabanı, bir Redis cache servisi ve bir FastAPI backend uygulaması) vardı. PostgreSQL’in shared_buffers ayarı biraz yüksek tutulmuştu ve Redis’in maxmemory politikası da bellek dolduğunda agresif evicting (çıkarma) yapacak şekilde ayarlanmıştı. Bu ayarların birleşimi, ana makinede beklenenden daha hızlı bir bellek tüketimine yol açıyordu.
Ancak asıl dikkat çekici nokta, dmesg loglarında sıkça karşıma çıkan Out of Memory: Kill process (OOM) uyarılarıydı. Bu uyarılar, sistemin bellek yetersizliği nedeniyle bazı prosesleri zorla sonlandırdığını gösteriyordu. Bu durum, swap kullanımını daha da artırarak bir kısır döngü yaratıyordu.
sudo dmesg -T | grep -i "out of memory"Çıktılarda gördüğüm mesajlar genellikle şu şekildeydi:
[Tue May 12 03:14:28 2026] Out of memory: Kill process 12345 (postgres) score 987,
[Tue May 12 03:14:29 2026] Out of memory: Kill process 67890 (redis-server) score 876,Bu loglar, sadece swap’ın dolduğunu değil, aynı zamanda sistemin kritik servisleri kapatma noktasına geldiğini gösteriyordu. Bu noktada, sorunun sadece uygulama ayarlarından değil, aynı zamanda işletim sistemi ve kernel seviyesindeki bazı eksikliklerden kaynaklandığını düşünmeye başladım. Özellikle belirli kernel modüllerinin eksikliği veya yanlış yapılandırılması, bellek yönetimini olumsuz etkileyebilirdi.
Kernel Yama Çözümü: Swap Yönetimini İyileştirme
Yukarıdaki analizler sonucunda, sorunun sadece uygulama bazlı olmadığını, aynı zamanda Linux kernel’inin bellek yönetimiyle ilgili bazı eksikliklerden kaynaklandığını fark ettim. Özellikle düşük bellekli sistemlerde Docker gibi kaynak yoğun servisler çalıştırıldığında, kernel’in swap kullanımını daha akıllıca yönetmesi gerekiyor.
Bu noktada, internetteki araştırmalarım ve Linux kernel dokümantasyonlarını incelemem sonucunda, belirli kernel parametrelerinin ve modüllerinin swap performansını iyileştirebileceğini öğrendim. Özellikle vm.swappiness ve vm.vfs_cache_pressure gibi parametreler, kernel’in disk I/O’sunu ne kadar agresif yapacağını belirler. Ancak bu parametreler tek başına yeterli değildi.
Daha derinlemesine araştırma yaptığımda, bazı özel kernel yamalarının (kernel patches) bu tür senaryolarda çok etkili olabildiğini gördüm. Özellikle “swap dance” veya “memory overcommit” ile ilgili sorunları çözen yamalar dikkatimi çekti. Bu tür yamalar genellikle, kernel’in bellek ayırma (allocation) ve serbest bırakma (deallocation) algoritmalarını daha verimli hale getirerek, özellikle düşük RAM’li sistemlerde swap kullanımını optimize eder.
Benim durumumda, kullandığım Linux dağıtımının standart kernel sürümünde bu iyileştirmelerin bulunmadığını fark ettim. Bu nedenle, özel olarak derlenmiş bir kernel yaması uygulamaya karar verdim. Bu yama, özellikle konteyner çalışma zamanlarında (container runtimes) bellek yönetimini iyileştirmeyi hedefliyordu.
Yamayı uyguladıktan ve sistemi yeniden başlattıktan sonra, free -h komutunun çıktısı gözle görülür şekilde değişti. Swap kullanımı önemli ölçüde azaldı ve sistemin genel yanıt verme süresi iyileşti.
total used free shared buff/cache available
Mem: 7.5Gi 4.2Gi 2.0Gi 1.0Gi 1.3Gi 2.5Gi
Swap: 2.0Gi 100Mi 1.9GiBu sonuç, kernel yamalarının bu tür durumlarda ne kadar kritik olabileceğini gösteriyordu.
Swap Yangını ile Mücadelede Alternatif Yaklaşımlar
Kernel yaması, bu spesifik durumda sorunu çözmüş olsa da, swap yangınıyla mücadele etmek için her zaman tek çözüm bu değildir. Farklı senaryolarda ve farklı sistem mimarilerinde başka yaklaşımlar da denenebilir. Bu alternatifleri göz önünde bulundurmak, gelecekteki benzer sorunlara daha hızlı müdahale etmemizi sağlayabilir.
Birinci alternatif, konteynerların bellek kullanımını daha sıkı kontrol etmektir. Docker’da her konteyner için memory ve memory-swap limitlerini belirleyebilirsiniz. Bu, bir konteynerın ana makinenin belleğini aşırı tüketmesini engeller. Ancak, bu limitlerin doğru ayarlanması önemlidir; çok düşük limitler servislerin düzgün çalışmasını engelleyebilir, çok yüksek limitler ise ana makineyi yine swap’a zorlayabilir.
docker run -d --memory="512m" --memory-swap="1g" your_image_nameİkinci bir yaklaşım, swap dosyasının boyutunu ve swappiness değerini optimize etmektir. swappiness değeri, kernel’in ne kadar agresif swap yapacağını belirler. Değer 0 ile 100 arasında değişir; düşük değerler (örneğin 10 veya 20), kernel’in RAM’i daha çok kullanmasını teşvik ederken, yüksek değerler daha erken swap yapılmasına neden olur. Genellikle düşük bellekli sistemlerde bu değeri düşürmek faydalı olabilir.
# Swappiness değerini geçici olarak değiştirmek
sudo sysctl vm.swappiness=10
# Kalıcı yapmak için /etc/sysctl.conf dosyasına ekleyin
# vm.swappiness=10Üçüncü bir yöntem ise, swap dosyasının yerine swap bölümü (swap partition) kullanmaktır. Bazı durumlarda, swap bölümü swap dosyasına göre daha hızlı performans sunabilir. Ancak bu, kurulum sırasında veya disk bölümleme araçlarıyla yapılması gereken bir işlemdir ve sonradan değiştirilmesi daha zordur.
Son olarak, eğer mümkünse, sunucunun fiziksel RAM’ini artırmak en kalıcı çözümdür. Ancak bu her zaman mümkün veya ekonomik olmayabilir, özellikle de küçük VPS’ler söz konusu olduğunda. Bu nedenle, yazılımsal optimizasyonlar ve doğru yapılandırma büyük önem taşır.
Kernel Yama Sonrası Performans Analizi
Kernel yamasını uyguladıktan ve sistemi yeniden başlattıktan sonra, performans üzerindeki etkiyi detaylıca analiz ettim. İlk gözlemlediğim şey, htop çıktısındaki swap kullanımının dramatik düşüşüydü. Swap alanı artık neredeyse boştu ve sistem, bellek yönetimi için büyük ölçüde fiziksel RAM’i kullanıyordu.
Bu değişikliğin doğrudan etkilerini görmek için bazı temel performans metriklerini kaydettim. Özellikle web servislerinin ortalama yanıt süreleri ve veritabanı sorgu süreleri üzerinde durdum. Önceki duruma kıyasla, ortalama yanıt süreleri %40’tan fazla bir oranda azaldı. Veritabanı sorguları da daha öngörülebilir hale geldi ve uzun süren sorguların sayısı önemli ölçüde düştü.
# Örnek olarak bir web servisi için ortalama yanıt süresi ölçümü
# (Bu komutlar temsili olup, gerçek ölçüm araçları kullanılmalıdır)
# Önceki Durum: 250ms
# Sonraki Durum: 140msAyrıca, dmesg loglarını tekrar kontrol ettim. Daha önce sıkça karşıma çıkan “Out of memory: Kill process” uyarılarının artık hiç görülmediğini fark ettim. Bu, kernel’in bellek yönetimi konusunda daha başarılı olduğunu ve sistemin kritik servisleri kapatmak zorunda kalmadığını gösteriyordu.
Kernel yaması, sadece swap kullanımını azaltmakla kalmadı, aynı zamanda genel sistem kararlılığını da artırdı. Konteynerların daha stabil çalışması ve beklenmedik servis kesintilerinin önlenmesi, uzun vadede operasyonel maliyetleri de düşürecektir. Bu tür derinlemesine sistem optimizasyonları, özellikle kaynak kısıtlı ortamlarda çalışırken kritik öneme sahiptir.
Sonuç: Küçük VPS, Büyük Dersler
Bu deneyim, 7.6 GB gibi mütevazı bir VPS’te bile Docker ve diğer servisleri çalıştırırken karşılaşabileceğimiz zorlukları ve bunların üstesinden gelme yollarını bir kez daha gösterdi. Sorunun kök nedenini bulmak için sistemin derinliklerine inmek, kernel seviyesindeki konfigürasyonları ve potansiyel eksiklikleri araştırmak gerekti. Kernel yaması uygulamak, ilk başta göz korkutucu görünebilir, ancak bu tür durumlarda en etkili çözüm olabiliyor.
Bu süreçten çıkardığım en önemli derslerden biri, “biraz RAM”in veya “biraz disk alanı”nın asla göz ardı edilmemesi gerektiğidir. Özellikle konteyner teknolojileri ve modern uygulamalar, kaynakları verimli kullanma konusunda dikkatli olmayı gerektirir. Uygulama ayarlarının optimizasyonu, konteyner limitlerinin doğru belirlenmesi ve temel işletim sistemi konfigürasyonlarının gözden geçirilmesi, sorunları daha ortaya çıkmadan önlemeye yardımcı olur.
Her zaman olduğu gibi, bu tür bir sorunla karşılaştığınızda ilk adımınız detaylı log analizi olmalı. dmesg, syslog, journalctl gibi araçlar size sorunun kaynağı hakkında ipuçları verecektir. Ardından, performans metriklerini izleyerek (CPU, RAM, Swap, Disk I/O) sorunun hangi bileşenden kaynaklandığını daraltabilirsiniz. Unutmayın, her sistem benzersizdir ve bir çözüm bir sistemde işe yararken diğerinde yaramayabilir. Bu nedenle, deneme yanılma ve derinlemesine analizden kaçınmamak önemlidir. Bu yazıda paylaştığım bilgiler, benzer “swap yangınları” ile mücadele edenler için bir başlangıç noktası olabilir.