Gecen hafta, tam da bir pazartesi sabahi, monitörümdeki “Critical Alert” bildirimleri gozumu korkuttu. Kendi VPS’imde kurulu olan sistemler, özellikle de Docker container’larim, aniden yavaslamaya baslamisti. SSH baglantilari bile gecikiyor, komutlarimin calismasi uzun suruyordu. Oysa hicbir sey yapmamistim, sadece her zamanki gibi gece guncellemelerini uygulamistim.
Bu aniden baslayan yavaslama, benim icin buyuk bir problemdi. Cunku bu VPS benim tum dunyam. Uzerinde 13’ten fazla Docker container calisiyor; PostgreSQL veritabani, Redis cache, Next.js uygulamalarim ve tabii ki bu blogun yayinlandigi Astro sitesi. Hepsi bir arada, guzelce isliyordu. Ta ki bu sabah olana kadar. Sorunun kaynagini bulmak icin derinlemesine incelemeye basladim.
Swap Kullanımının Çığırından Çıkması
İlk baktigim yer, sunucunun genel kaynak kullanimi oldu. htop komutunu calistirdigim anda gozlerime inanamadim: Swap kullanımı %100’e dayanmisti. Normalde swap alanimi cok dusuk tutarim, hatta bazen kapatirim bile. Ancak bu sefer durum farkliydi. Swap’in bu kadar yuksek kullanilmasi, sistemin RAM’inin yetersiz kaldigini ve diskteki swap alanini kullanmaya basladigini gosteriyordu. Bu da performansin dibe vurmasina neden oluyordu.
Neden swap bir anda bu kadar yukselmisti? Hemen dmesg ve journalctl loglarina baktim. Bir suru kcompactd ve oom-killer ile ilgili uyari goruyordum. Özellikle kcompactd’nin CPU’yu %90’lar seviyesinde tukettigini fark ettim. Bu, kernel’in bellek yonetiminde ciddi bir sorun yasadigini isaret ediyordu.
Kernel CVE Yamasıyla Başlayan Kabus
Loglari daha detayli inceledigimde, sorunun gece uyguladigim kernel guncellemesiyle basladigini anladim. Tam olarak CVE-2026-31431 ile ilgili bir yama uygulamistim. Bu CVE, kernel’in network stack’indeki bir guvenlik acigini kapatmaya yonelikti. Ancak gorunuse gore, bu yama benim sistemimde beklenmedik yan etkilere yol acmisti.
Bu CVE yamasi, kernel’in bellek yonetimiyle yakindan ilgiliydi. Ozelikle algif_aead moduluyle ilgili bir duzeltme iceriyordu. Bu modül, VPN ve sifreleme islemlerinde kullaniliyor. Benim sistemimde dogrudan VPN baglantisi yapmasam da, Docker’in ag islemleri ve bazi guvenlik duvarı kurallari bu modulu dolayli yoldan etkilemis olabilir. Yasananlar, “kurumsal danisman” tonunda degil, tamamen benim yasadigim, “olur o kadar” dedigim bir durumdu.
Sorunun Kaynagini Tespit Etme
kcompactd’nin CPU’yu bu kadar yuksek kullanmasinin arkasinda yatan sebep, kernel’in bellek sayfalarini bir arada tutmaya calismasiydi. Ancak bu islem, bellek yonetiminde bir darbozaza neden oluyordu. Her sey, gece uyguladigim kernel guncellemesiyle baslamisti. Bu guncelleme, benim durumumda, mevcut yapimla uyumsuzluk gostermisti.
Bu noktada aklima, Astro build’imin cok fazla RAM tukettigi zamanlar geldi. O durumlarda da sistem swap’e yukleniyordu. Ancak bu seferki sorun daha derindi, kernel seviyesindeydi. kcompactd’nin CPU’yu %92’ye kadar cikarmasi, normal bir durum degildi. Bu durum, sunucunun SSH baglantisini bile kabul edemez hale getirmesine neden olmustu.
# Dmesg loglarindan bir kesit (gercek hata mesaji degildir, orneklendirme amacli)
[Mon May 09 06:15:32 2026] kcompactd0: highmem-intensive workload detected, entering compact mode
[Mon May 09 06:16:01 2026] Out of memory: Kill process 12345 (kworker/u8:1) score 1000 or sacrifice child
[Mon May 09 06:16:05 2026] systemd invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0Çözüm Yolları ve Trade-off’lar
Sorunu cozmek icin ilk aklima gelen, uyguladigim kernel guncellemesini geri almak oldu. Ancak bu, guvenlik acigi olan bir surumu tekrar sisteme yuklemek demekti. Bu kabul edilebilir bir secenek degildi. Bunun yerine, daha guvenli bir yaklasim benimsemem gerekiyordu.
Bir diger secenek, kcompactd’nin davranisini ayarlamakti. Kernel parametrelerini degistirerek, bellek sikistirma isleminin daha az agresif olmasini saglayabilirdim. Ancak bu, uzun vadeli bir cozum degildi ve baska sorunlara yol acabilirdi.
Nihayetinde, en mantikli cozumun, soruna neden olan CVE yamasiyla ilgili alternatif bir cozum bulmak olduguna karar verdim. Bu, daha cok zaman alacakti ama guvenli bir cozumdu.
Geçici Çözüm: Swap Kullanımını Azaltma
Sorunun kokune inene kadar, sistemi ayakta tutmak icin bazi gecici cozumler uygulamam gerekiyordu. İlk olarak, Docker imajlarimdan ve build cache’lerimden gereksiz olanlari temizledim. docker system prune -a komutuyla diskte yer acmaya calistim. Ardindan, Astro projemin build surecini optimize etmeye odaklandim.
Bu sirada, GitHub Actions’da yasadigim runner state corruption sorununu da hatirladim. O durumda da /home/runner/_work/_temp altindaki dizinleri silmek cozum olmustu. Bu tur sorunlar, mevcut sistemdeki dengesizlikleri gosteriyor.
Gecici bir cozum olarak, swap kullanimi cok yuksek oldugunda, otomatik olarak bazi islemleri durduracak veya onceligini dusurecek bir script yazmayi dusundum. Ancak bu, tam bir yama degildi, sadece bir onleyici tedbirdi.
Gerçek Çözüm: CVE Yama Alternatifi
CVE-2026-31431 ile ilgili resmi yamayi geri almak yerine, bu yamaya bagli olmayan, ancak benzer bir guvenlik acigini kapatan alternatif bir kernel modulu kullanmaya karar verdim. Bu, biraz arastirma gerektirdi. algif_aead modulu yerine daha stabil ve benim sistemimle uyumlu baska bir sifreleme modulu bulmam gerekiyordu.
Sonunda, bu spesifik CVE’nin etkisini azaltan ve benim sistemimde stabil calisan bir kernel versiyonu buldum. Yeni kernel surumunu kurdum ve sistemi yeniden baslattim. İlk kontrolumde, swap kullanimi normal seviyelere donmustu ve kcompactd artik CPU’yu zorlamiyordu. SSH baglantilari hizlanmisti.
Bu surecte, kendi VPS’imde 28 Nisan’da yasadigim disk doluluk sorununu da hatirladim. O zaman diskte 33 GB build cache ve 23 GB kullanilmayan imajlar vardi. Bu seferki sorun daha cok bellek yonetimiyle ilgiliydi ama genel olarak sistemin saglikli kalmasi icin duzenli temizlik ve optimizasyonun ne kadar onemli oldugunu bir kez daha gormus oldum.
Çıkarılan Dersler ve Geleceğe Yönelik Adımlar
Bu yasadigim olay, bana birkaç onemli ders cikartti. Ilk olarak, kernel guncellemelerini uygularken cok daha dikkatli olmam gerektigini anladim. Her guncelleme, sistemde beklenmedik yan etkilere yol acabilir. Özellikle production ortamlarda, guncellemeleri once test ortaminnda denemek sart.
İkincisi, sistem kaynaklarinin (RAM, swap) duzenli olarak izlenmesi ve anormalliklerin erken tespit edilmesi cok onemli. htop, dmesg, journalctl gibi araclarin yaninda, daha gelişmiş monitoring sistemleri kullanmak faydali olabilir. Kendi sunucumda bu kadar cok container yonetirken, tek bir container’daki sorun bile tum sistemi etkileyebiliyor.
Son olarak, CVE’lere karsi hizli ve etkili bir sekilde yama uygulamak onemli olsa da, bu yamalarin kendi iclerinde sorunlara yol acabilecegini unutmamaliyim. Bu nedenle, guvenlik yamalarini uygularken, sistemin genel davranisini da yakindan takip etmeliyim. Belki de bir sonraki blog yazimda, GitHub Actions’daki self-hosted runner’larin ekonomik avantajlari ve kotayi asmamak icin VPS kullanimi uzerine bir rehber hazirlayabilirim.
Senin de basina boyle beklenmedik sistem sorunlari geldi mi? Yorumlarda paylasirsan sevinirim.