Gece Yarısı 'Swap Storm': Bir SRE'nin Bellek Kabusu

Gece yarısı, cep telefonunuzdan gelen o anlamsız bip sesiyle uyanmak, bir SRE (Site Reliability Engineer) için pek de yeni bir durum değildir. Ancak bazı alarmlar vardır ki, derin bir uykudan sıyrılıp, yatağınızdan fırlamanıza neden olur. Bu, sistemlerin durma noktasına geldiğini, kullanıcıların erişemediğini ve iş sürekliliğinin ciddi tehlike altında olduğunu haber veren o kritik çağrıdır. İşte o gece, bu türden bir çağrıyla uyandım ve kendimi bir “Swap Storm” kabusunun tam ortasında buldum.

Bu yazıda, bir SRE olarak yaşadığım “Swap Storm” deneyimini, bu korkutucu olayın teknik detaylarını, neden bir kabusa dönüştüğünü ve bu tür kritik durumlarla nasıl başa çıktığımızı anlatacağım. Sadece teknik bir rehberden öte, bu olayların SRE’lerin hayatları üzerindeki etkisine ve çıkarılan derslere odaklanacağız.

”Swap Storm” Nedir ve Neden Bir Kabustur?

Sistemlerimizde çalışan uygulamaların ve servislerin ihtiyaç duyduğu bellek (RAM) sınırlıdır. Bu bellek yetersiz kaldığında, işletim sistemi daha az kullanılan bellek sayfalarını diske “swap alanı” adı verilen özel bir bölüme yazar. Bu işlem, sistemin fiziksel belleği dolduğunda uygulamaların çalışmaya devam etmesini sağlar. Ancak, bu durumun bir de karanlık yüzü vardır: “Swap Storm”.

Bir “Swap Storm”, sistemin sürekli olarak bellek sayfalarını disk ile RAM arasında taşıması, yani aşırı derecede “swapping” yapması durumudur. Disk, RAM’den çok daha yavaştır ve bu sürekli veri taşıma işlemi, CPU kaynaklarını tüketir, I/O operasyonlarını artırır ve sistemin genel performansını felç eder. İşte bu yüzden bir “Swap Storm”, bir SRE için gerçek bir kabustur.

Bu durum, kullanıcılar için yavaş yanıt süreleri, zaman aşımları ve servis kesintileri anlamına gelir. SRE’ler için ise, uykusuz geceler, stresli teşhis süreçleri ve hızlıca çözüm bulma baskısı demektir. Bellek yönetimi, karmaşık bir alandır ve bir “Swap Storm”un kök nedenini bulmak, bazen samanlıkta iğne aramaktan farksız olabilir.

Gece Yarısı Çağrısı: Olayın Başlangıcı

Saat gece 03:00 civarıydı. Derin bir uykudaydım ki, telefonumun rahatsız edici alarm sesiyle uyandım. PagerDuty’den gelen kritik bir uyarı: “Service X - High Latency & Error Rate”. Gözlerimi ovuşturarak, refleks olarak dizüstü bilgisayarımı açtım ve VPN bağlantımı kurdum. İlk başta ne olduğunu anlamaya çalışıyordum; CPU mu yüksekti, disk mi doluydu, yoksa ağ sorunları mı vardı?

Dashboards’a baktığımda, her şeyin kırmızı alarm verdiğini gördüm. Servisler yanıt vermiyor, veritabanı bağlantıları düşüyor, ve en kötüsü, sistemin genel performansı adeta buz kesmişti. Bu tip bir durumla karşılaştığınızda, adrenalin seviyeniz anında tavan yapar ve “focus” moduna geçersiniz.

Diagnostik Süreci: Kabusun İzini Sürmek

Panik yapmak yerine, soğukkanlılıkla adımları takip etmeye başladım. İlk olarak, etkilenen sunuculardan birine SSH ile bağlandım. top komutunu çalıştırdığımda gördüğüm manzara, beni doğrudan “Swap Storm” şüphesine yöneltti. wa (wait for I/O) yüzdesi fırlamış, free bellek neredeyse sıfıra inmiş ve swap kullanımı tavan yapmıştı.

free -h çıktısı içler acısıydı:

              total        used        free      shared  buff/cache   available
Mem:           32Gi       31Gi        100Mi       1Gi         500Mi       100Mi
Swap:          16Gi       16Gi          0B

Bu, sistemin tüm fiziksel belleğini tükettiğini ve tüm swap alanını da kullandığını gösteriyordu. Diske sürekli yazma ve okuma operasyonları, sistemi tamamen yavaşlatmış, servislerin yanıt verememesine neden olmuştu. Bu durum, “thrashing” olarak da bilinir ve sistemin asıl işini yapmak yerine, bellek sayfalarını yönetmekle meşgul olduğu anlamına gelir.

Bellek Tüketimini Anlamak

Sistemin neden bu kadar bellek tükettiğini anlamak için daha derinlemesine incelemeler yapmam gerekiyordu. top ve htop gibi araçlar, hangi süreçlerin en çok bellek kullandığını gösterir. RES (Resident Set Size) ve VIRT (Virtual Memory Size) gibi metrikler, bir sürecin fiziksel bellekte ne kadar yer kapladığını ve toplamda ne kadar sanal bellek kullandığını anlamak için önemlidir.

Ancak, bazen sorun tek bir büyük süreçten değil, birçok küçük sürecin toplam bellek tüketiminden veya işletim sistemi çekirdeği tarafından kullanılan bellekten (örneğin, kernel slab cache) kaynaklanabilir. Bu durumda, vmstat, sar veya doğrudan /proc/meminfo ve /proc/slabinfo gibi komutlar daha detaylı bilgi sağlar.

vmstat çıktısı, bellek ve swap aktivitesinin anlık durumunu gösterir:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0  16Gi   100Mi  200Mi  300Mi   1k   1k   500  1000  100  200 10 10 70 10  0

Buradaki si (swap in) ve so (swap out) değerleri, saniyede ne kadar belleğin swap alanına yazıldığını ve diskten okunduğunu gösteriyordu. Bu değerler, bir “Swap Storm” sırasında genellikle çok yüksek olur. Yüksek wa (I/O wait) değeri ise CPU’nun I/O operasyonlarını beklemekle meşgul olduğunu kanıtlar nitelikteydi.

Çözüm Yolları ve İlk Müdahaleler

Olayın kök nedenini bulmak zaman alsa da, önce sistemi kurtarmak ve servisleri ayağa kaldırmak gerekiyordu. İlk müdahale genellikle en bariz ve hızlı olanıdır:

1. En çok bellek tüketen süreçleri durdurma/yeniden başlatma: top veya htop ile tespit edilen, anormallik gösteren süreçleri durdurmak veya yeniden başlatmak, geçici bir nefes alma alanı yaratabilir. Ancak bu, sorunu sadece erteleyebilir.
2. Kritik olmayan servisleri durdurma: Eğer ortamda birden fazla servis çalışıyorsa ve bazıları daha az kritikse, onları geçici olarak durdurmak, kritik servisler için bellek açabilir.
3. Ek kaynak sağlama (Bulut ortamında): Eğer bulut tabanlı bir altyapıda çalışıyorsanız, sunucunun RAM’ini artırmak (scale up) hızlı bir çözüm olabilir. Ancak bu, genellikle “bant genişliği” çözümü olup, asıl sorunu çözmez.

Benim durumumda, belirli bir uygulama servisinin aniden bellek tüketimini artırdığını tespit ettim. Uygulama, son yapılan bir deploy ile birlikte, veritabanından çekilen büyük veri kümelerini bellekte tutmaya başlamıştı. Bu, bir “memory leak” olmasa da, beklenenden çok daha fazla bellek kullanılmasına neden olan bir verimsizlikti.

Geçici çözüm olarak, ilgili servisi yeniden başlattım. Bu, belleği serbest bıraktı ve sistemin swap kullanımını normale indirdi. Ancak bu sadece bir bandajdı. Kalıcı bir çözüm için daha fazlası gerekiyordu.

Kalıcı Çözümler ve Gelecek İçin Dersler

Bir “Swap Storm” gibi olaylardan sonra, sadece anlık krizi yönetmekle kalmaz, aynı zamanda gelecekte benzer durumların yaşanmaması için kalıcı çözümler uygularsınız. Bu süreç, SRE’nin en önemli görevlerinden biridir: öğrenmek ve sistemi güçlendirmek.

Kalıcı çözümler genellikle şunları içerir:

• Kod Optimizasyonu: Uygulama kodu incelenerek bellek sızıntıları, verimsiz veri yapıları veya gereksiz bellek kullanımı tespit edilir ve düzeltilir. Benim durumumda, uygulamanın büyük veri kümelerini işleme mantığı optimize edildi.
• Kaynak Limitleri ve İzolasyon:
  • cgroups (Control Groups): Linux’ta süreçlerin CPU, bellek, I/O gibi kaynakları kullanımını sınırlamak ve izole etmek için kullanılır. Böylece bir sürecin tüm sistemi felç etmesi engellenebilir.
  • Kubernetes Resource Limits: Containerized uygulamalar için CPU ve bellek limitleri tanımlamak, bir pod’un belirli bir eşiği aşmasını engeller.
• Proaktif İzleme ve Uyarılar: Bellek kullanımının belirli bir eşiği aşması durumunda (örneğin, %80 RAM kullanımı veya swap kullanımında artış) önceden uyarı veren daha hassas monitörler kurulur. Bu, bir “Swap Storm” başlamadan önce müdahale etme fırsatı sunar.
• Performans Testleri: Yeni özellikler veya büyük değişiklikler devreye alınmadan önce, stres ve yük testleri yaparak bellek kullanımının ve performansın beklenenin ötesine geçip geçmediği kontrol edilir.
• swappiness Ayarı: Linux çekirdeğinin swappiness parametresi, sistemin ne kadar agresif bir şekilde swap kullanacağını belirler. Değeri 0 ile 100 arasında değişir. Düşük bir değer (örneğin, 10), sistemin swap’ı mümkün olduğunca az kullanmaya çalışacağı anlamına gelir. Ancak, bu ayarı değiştirmeden önce dikkatli olunmalı ve sistemin davranışına göre optimize edilmelidir.

Bir SRE’nin Hayatından Çıkarılacak Dersler

Bu gece yarısı deneyimi, bir SRE olarak bana ve ekibime önemli dersler öğretti:

1. Proaktif İzlemenin Önemi: Sadece servislerin durumunu değil, altyapının temel metriklerini (CPU, bellek, disk I/O, ağ) derinlemesine izlemek, potansiyel sorunları erken aşamada tespit etmek için kritik öneme sahiptir.
2. Sistem İçsel Dinamiklerini Anlamak: Bir “Swap Storm” gibi karmaşık bir sorunu çözmek için sadece semptomları değil, işletim sisteminin bellek yönetimi gibi içsel dinamiklerini de anlamak gerekir. vmstat, sar, /proc filesystem gibi araçlar bu konuda vazgeçilmezdir.
3. Stres Yönetimi ve Soğukkanlılık: Gece yarısı gelen kritik bir uyarı, herkesi panikletebilir. Ancak bir SRE’nin en önemli özelliklerinden biri, baskı altında bile soğukkanlılığını koruyarak sistematik bir şekilde sorun giderme yeteneğidir.
4. Dokümantasyon ve Runbook’lar: Olay anında hızlıca hareket edebilmek için iyi hazırlanmış runbook’lar (adım adım sorun giderme kılavuzları) ve dokümantasyonlar hayat kurtarır.
5. Otomasyon ve Geriye Dönük İncelemeler: Benzer sorunların tekrar etmemesi için otomasyon geliştirmek ve her olayın ardından detaylı bir geriye dönük inceleme (post-mortem) yaparak öğrenilen dersleri belgelemek, sürekli iyileşmenin anahtarıdır.

Sonuç

Gece yarısı gelen bir “Swap Storm” çağrısı, her SRE’nin kariyerinde karşılaşabileceği en stresli anlardan biridir. Bu tür olaylar, sadece teknik becerilerimizi değil, aynı zamanda problem çözme, stres yönetimi ve ekip çalışması gibi “life” becerilerimizi de sınar. Ancak her kabusun bir sonu olduğu gibi, bu tür krizlerin de bir sonu vardır ve her kriz, bizi daha iyi, daha dirençli ve daha bilgili SRE’ler yapar.

Bir SRE olarak hayat, sürekli bir öğrenme ve adaptasyon yolculuğudur. Her “Swap Storm” veya benzeri kritik olay, sistemlerimizi daha iyi anlamamızı, daha sağlam çözümler üretmemizi ve en önemlisi, bir sonraki bilinmeyenle yüzleşmeye hazır olmamızı sağlar. Unutmayın, önemli olan düşmek değil, her düştüğümüzde bir ders çıkarıp ayağa kalkmaktır.