Acil tıp pratiğinde hekimlerin karşılaştığı en dramatik ve yıldırım hızıyla öldüren tablolardan biri "Masif Pulmoner Tromboemboli"dir (semer emboli). Bacağın derin toplardamarlarında sessizce büyüyen devasa bir pıhtı kitlesi, hastanın aniden ayağa kalkmasıyla yerinden kopar. Dolaşıma katılır, kalbin sağ odacıklarından geçer ve ana akciğer atardamarının ikiye ayrıldığı o kritik kavşağa (bifürkasyon) bir takoz gibi oturur. Akciğerlere kan akışı bir saniyede durur; sağ kalp odacığı o devasa direnci aşamadığı için anında genişler (akut cor pulmonale), tansiyon sıfırlanır ve hasta hekimin gözünün önünde morararak kardiyak arreste girer. Tek bir dev pıhtı, tüm dolaşım sisteminin nefesini kesmiştir.
Linux sunucu yönetimi ve veri merkezi operasyonlarında da sistem yöneticilerinin monitörlerinde tüm grafiklerin kırmızıya çakılmasına ve yüzlerce web sitesinin aynı anda donmasına yol açan o ölümcül semer pıhtı vardır: cPanel Dosya Yöneticisi (File Manager) üzerinden web arayüzüyle 40 gigabaytlık bir ZIP arşivini açmaya (Extract) kalkışmak.
Haftanın en yoğun iş saatinde, paylaşımlı bir sunucuda barınan bir e-ticaret geliştiricisi veya ajans çalışanı işini "hızlıca" halletmek ister. Eski sunucusundan indirdiği 42 GB büyüklüğündeki site yedeğini FTP veya web arayüzünden yeni cPanel hesabının public_html dizinine yüklemiştir: full_backup_mart_2026.zip.
Bu devasa arşivin içinde sadece birkaç büyük veritabanı yedeği yoktur; son 8 yıldır yüklenmiş 450.000 adet ürün görseli, minik minik önbellek dosyaları, oturum kayıtları ve modül dizinleri vardır.
Geliştiricimiz SSH terminalini açıp arka planda düşük öncelikle (nice / ionice) işlem yapmak yerine, cPanel'in web tabanlı Dosya Yöneticisi (File Manager) sekmesini açar. Arşiv dosyasını seçer, sağ üstteki o masum "Extract" (Çıkar) butonuna tıklar ve arkasına yaslanır.
O butona tıklandığı saniyede, veri merkezindeki sunucu kabininde sanal bir semer embolisi patlak verir.
cPanel Dosya Yöneticisi, masaüstü bir işletim sistemi gibi tasarlanmamıştır. Web arayüzünden "Extract" dediğinizde arayüz arka planda bir unzip veya PHP/Perl betiğini web sunucusu kullanıcısının (cpanel-cpsrvd) yetkileriyle doğrudan tek bir çekirdeğe ve I/O kanalına kilitler.
Ve arka planda şu dehşet senaryosu başlar:
Inode Fırtınası: Arşivin içindeki 450.000 küçük dosya diske yazılmaya çalışılır. Her bir dosya için işletim sistemi dosya tablosuna (inode) yeni bir kayıt girmek, izinleri (chmod 0644) kontrol etmek ve dizin ağacını güncellemek zorundadır.
I/O Wait Kilitlenmesi (Disk Kuyruk Patlaması): Sunucunun kurumsal NVMe disk dizileri bile bu eşzamanlı rastgele yazma (random write) fırtınası karşısında nefessiz kalır. Linux çekirdeğinde %iowait değeri %0.5'ten anında %98'e fırlar. Yani işlemci çekirdekleri işlem yapamaz; diskin yazma kuyruğunun boşalmasını beklemekten kilitlenir.
Load Average Patlaması: Normal şartlarda 2.0 veya 3.0 seviyesinde çalışan sunucu yükü (Load Average) saniyeler içinde 65.0, ardından 140.0 seviyesine tırmanır.
MySQL / MariaDB Kalp Durması: Veritabanı motoru diske redo log ve buffer yazmak istediğinde diskten yanıt alamaz. Veritabanı soketi askıda kalır; sunucudaki diğer 250 web sitesinin tamamı aynı anda ekrana o korkunç hatayı basmaya başlar: "503 Service Unavailable" ve "Error establishing a database connection".
Tek bir kullanıcının web arayüzünden tıkladığı o tek buton, sunucudaki tüm komşuların dolaşım sistemini felç etmiştir.
Sistem yöneticisinin cebindeki PagerDuty veya Telegram botu aralıksız titremeye başlar: "SERVER-04 LOAD CRITICAL: 112.4".
Mühendis terminale girmeye çalışır; SSH bağlantısı bile I/O kilitlenmesi yüzünden 45 saniyede zar zor açılır. Terminal açılır açılmaz komutlar hekimin acil tPA (pıhtı eritici ilaç) vermesi gibi seridir:
top -c# veyaiotop -oPa
Tablo anında görünür: user_eticaret kullanıcısı altında koşan /usr/bin/unzip full_backup_mart_2026.zip process'i diskin tüm bant genişliğini tek başına sömürmektedir.
Tereddüt edilmez; pıhtıyı mekanik olarak parçalamak gerekir:
killall -9 unzip# veyapkill -u user_eticaret -9
Komut verildiği anda disk üzerindeki o devasa yazma baskısı kırılır. I/O kuyruğu milisaniyeler içinde erir, işlemci çekirdekleri nefes alır, Load Average dakikalar içinde 140'tan 4'e geriler ve diğer müşterilerin siteleri canlanmaya başlar.
Tabii ki operasyon biter bitmez kullanıcıdan bilet düşer:
"Sitenin yedeğini açıyordum, tam %60'tayken işlem iptal oldu! Dosyalarım eksik çıktı! Sizin sunucunuz 40 GB dosyayı bile açamıyor mu? Ne biçim donanımınız var sizin?"
Mühendis sabırla açıklar: "Sayın kullanıcımız, paylaşımlı bir sunucuda web tarayıcısı üzerinden tek oturumda 450.000 dosyalık bir arşivi açmaya çalışmak sunucunun tüm disk erişimini durdurur. Bu tür devasa yedekler web panelinden değil, SSH üzerinden düşük öncelikle veya parçalı olarak açılmalıdır."
SSH ve ionice Kullanımı: Büyük arşivler asla tarayıcıdan değil, doğrudan SSH konsolundan açılmalıdır. Üstelik Linux'un I/O öncelik yöneticisi (ionice) ile disk yükü sınırlandırılmalıdır:
# İşlemi en düşük disk önceliğiyle (Idle/Best Effort) çalıştır:ionice -c 3 nice -n 19 unzip -q dev_arsiv.zip &
Bu komut sayesinde işlemci ve disk, sadece sistemde boşluk olduğunda arşivi açar; sunucunun ana işleyişi asla aksamaz.
Arşivi Parçalara Bölmek: 40 GB'lık tek bir devasa zip yerine, veritabanını ayrı (db.sql.gz), ürün görsellerini yıllık klasörler halinde ayrı arşivler (images_2025.tar.gz) olarak saklamak.
Bulut Depolama Üzerinden Senkronizasyon (Rsync / Rclone): Arşivi sunucu içinde açmak yerine, dosyaları yerel makinede veya ayrı bir staging alanında açıp sunucuya rsync -avz komutuyla peyderpey göndermek.
Masif pıhtıyı ana damardan geçirmeye çalışmak biyolojiyi nasıl öldürüyorsa, yüz binlerce dosyayı web panelinden açmaya çalışmak da sunucuyu öyle komaya sokar. Arayüzün sunduğu her buton, limitsiz bir sorumsuzluk hakkı vermez. Profesyonel mühendislik, aracın gücünü bilmek kadar sınırlarına da saygı duymayı gerektirir.