Sanal sunucuda yüksek disk I/O sorunu, uygulamaların yavaşlamasına, SSH oturumlarının gecikmesine, veritabanı sorgularının uzamasına ve zaman zaman servis zaman aşımlarına neden olabilir. Sorun yalnızca sanal makine içindeki bir süreçten kaynaklanmayabilir; disk alanının dolması, yoğun günlük yazımı, veritabanı geçici dosyaları, snapshot işlemleri veya fiziksel ana makinedeki depolama çekişmesi de aynı belirtileri oluşturur. Bu rehber, Linux tabanlı sanal sunucularda önce I/O beklemesinin gerçekten yüksek olup olmadığını doğrulamayı, sonra yükü üreten katmanı ayırmayı ve veri kaybı riski oluşturmadan kalıcı iyileştirme yapmayı açıklar.
Belirtiler ve kapsam: Disk I/O darboğazı nasıl anlaşılır?
Yüksek CPU kullanımı ile disk I/O darboğazı birbirinden farklıdır. Disk beklemesinde işlemci büyük ölçüde boş görünse bile süreçler depolama yanıtını beklediği için sistem yavaşlar. Toplam CPU değerindeki wa (iowait) alanının sürekli yükselmesi önemli bir işarettir; ancak tek başına kesin karar için yeterli değildir.
- Web uygulamasında aralıklı veya sürekli yavaşlama, 504 ya da uygulama tarafında zaman aşımı görülmesi
- SSH üzerinden komutların, özellikle
ls,dfveya günlük okuma işlemlerinin geç yanıt vermesi - Veritabanında sorgu sürelerinin uzaması, kilitlenme veya bağlantı zaman aşımı
topya davmstatçıktısında yüksek iowait ve bekleyen görev sayısıdmesgveya sistem günlüklerinde I/O hatası, dosya sistemi hatası ya da blok aygıt sıfırlama kayıtları
Bu makaledeki komutlar systemd kullanan güncel Debian/Ubuntu, RHEL, AlmaLinux, Rocky Linux ve benzeri dağıtımlar içindir. Aygıt adı ortamınıza göre /dev/vda, /dev/sda veya NVMe tabanlı sistemlerde /dev/nvme0n1 olabilir. Sanal makine içinde görünen aygıt adını tahmin etmeyin; önce tespit edin.
Sanal sunucuda yüksek disk I/O sorunu için hızlı teşhis özeti
- Sorunun anlık mı, düzenli tekrar eden mi olduğunu ve etkilenen servisleri kaydedin.
- CPU iowait, disk gecikmesi, kuyruk uzunluğu ve disk doluluk oranını birlikte ölçün.
- En çok okuma/yazma yapan işlem, dosya veya dizini belirleyin.
- Sistem günlüklerinde blok aygıt, dosya sistemi ve bellek baskısı hatalarını inceleyin.
- Yük konuk işletim sisteminde açıklanamıyorsa snapshot, yedekleme, başka VM yoğunluğu ve depolama gecikmesi için sanallaştırma katmanını kontrol edin.
Önemli: Dosya sistemi onarımı, bölüm işlemleri, LVM değişiklikleri, veritabanı kurtarma veya geri yükleme öncesinde doğrulanmış yedek alın ve mümkünse bakım penceresi planlayın. Ani yeniden başlatma ya da zorla kapatma, zaten gecikme yaşayan depolamada veri tutarsızlığı riskini artırabilir.
Olası nedenler
| Katman | Yaygın neden | İlk kontrol |
|---|---|---|
| Uygulama | Yoğun log yazımı, büyük dosya taraması, sıkıştırma, indeksleme | iotop, pidstat -d |
| Veritabanı | Geçici tablo, yetersiz bellek, ağır sorgu, büyük bakım işi | Yavaş sorgu kaydı, aktif sorgular, disk yazım oranı |
| Dosya sistemi | Diskin dolması, inode tükenmesi, hata veya yoğun metadata işlemi | df -h, df -i, günlükler |
| Bellek | Swap kullanımı ve sürekli sayfa geri yazımı | free -h, vmstat 1 |
| Sanallaştırma/depolama | Snapshot, yedekleme, datastore gecikmesi, komşu VM çekişmesi | Hiper yönetici ve depolama metrikleri |
Özellikle geceleri veya belirli saatlerde başlayan yük, çoğunlukla zamanlanmış yedek, güvenlik taraması, log rotasyonu, indeksleme ya da veritabanı bakım göreviyle ilişkilidir. Sürekli yük ise uygulama hatası, sorgu paterni, yetersiz IOPS kapasitesi veya ana makine tarafındaki depolama çekişmesine işaret edebilir.
Loglar ve teşhis komutları
1. Disk aygıtlarını, alanı ve inode durumunu doğrulayın
Aşağıdaki kontroller salt okunur niteliktedir ve üretim ortamında güvenle uygulanabilir.
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
findmnt -D
df -hT
df -i
free -h
df -hT çıktısında doluluğu yüksek bağlama noktalarını, df -i çıktısında ise inode kullanımını inceleyin. İnodelar bittiğinde boş alan olsa bile yeni dosya oluşturulamaz; bu durum uygulama hataları ve olağan dışı I/O davranışı üretebilir.
2. I/O beklemesini ve aygıt gecikmesini ölçün
iostat komutu çoğu dağıtımda sysstat paketiyle gelir. Debian/Ubuntu için apt install sysstat, RHEL türevleri için dnf install sysstat gerekebilir. Paket kurulumunu değişiklik kaydınıza ve bakım politikanıza uygun yürütün.
uptime
vmstat 1 10
iostat -xz 1 10
vmstat içindeki wa değeri CPU’nun disk beklediği zamanı gösterir. iostat -xz çıktısında aygıt bazında await, aqu-sz ve %util alanlarını birlikte değerlendirin. Yüksek await gecikmeye, büyüyen aqu-sz kuyruk oluştuğuna işaret eder. %util ise sanal ve paylaşımlı depolamada tek başına kapasite ölçüsü değildir; trend ve uygulama etkisi daha değerlidir.
3. I/O üreten süreci bulun
iotop kök yetkisi ister ve bazı sistemlerde ek paket olarak kuruludur. Kısa bir gözlem alın; sürekli açık bırakmak gereksiz ek yük oluşturabilir.
sudo iotop -oPa
sudo pidstat -d 1 10
ps -eo pid,ppid,user,comm,%cpu,%mem --sort=-%cpu | head -n 20
iotop üzerinde görülen PID’nin hangi hizmete ait olduğunu doğrulayın. Örneğin web sunucusu, yedekleme aracı, veritabanı veya güvenlik tarayıcısı farklı çözüm yolları gerektirir. Sadece süreç adını görerek işlemi sonlandırmayın; önce ebeveyn süreç, zamanlayıcı ve uygulama günlükleriyle görevi doğrulayın.
4. Çekirdek ve servis günlüklerini inceleyin
sudo journalctl -k -b --no-pager | tail -n 200
sudo dmesg -T | tail -n 200
sudo journalctl -p warning..alert -b --no-pager
systemctl --failed
I/O error, Buffer I/O error, EXT4-fs error, XFS hata kayıtları veya aygıtın yeniden bağlanmasına ilişkin mesajlar, normal kapasite yetersizliğinden farklı bir arıza olasılığını gösterir. Bu durumda yazma yükünü artıracak bakım işleri çalıştırmayın; sağlayıcı ya da depolama yöneticisiyle olay zamanını, VM adını ve ilgili günlük kesitlerini paylaşın.
Güvenli adım adım çözüm
Yükü oluşturan işi erteleyin veya sınırlandırın
Bir yedekleme, arşivleme, dosya tarama veya toplu içe aktarma görevi sorumluysa önce görevin takvimini doğrulayın. İş kritik değilse bakım penceresine ertelemek, aynı anda çalışan benzer işleri ayırmak ve artımlı yedekleme kullanmak güvenli ilk yaklaşımdır. Çalışan yedekleme işini durdurmadan önce tutarlılık ve yeniden başlatma davranışını ilgili yazılımın belgelerinden kontrol edin.
Linux’ta yeni başlatılacak, önceliği düşük toplu işler için nice CPU, ionice ise I/O zamanlamasını etkileyebilir. Etkisi kullanılan blok I/O zamanlayıcısına ve sanal disk sürücüsüne göre değişir; üretim servisini doğrudan bu komutlarla yeniden başlatmayın.
ionice -c3 nice -n 19 /path/to/backup-script
Buradaki /path/to/backup-script örnek yer tutucudur; yalnızca kendi doğrulanmış betik yolunuzu kullanın. ionice -c3 boşta I/O sınıfıdır ve etkileşimli işler için uygun değildir.
Disk alanı, günlük büyümesi ve geçici dosyaları yönetin
Alan açmak için önce en büyük dizinleri ölçün; dosyaları körlemesine silmeyin. Açık bir günlük dosyasını silmek alanın hemen geri dönmesini sağlamayabilir; süreç dosya tanıtıcısını kapatana kadar alan tutulabilir.
sudo du -xhd1 / 2>/dev/null | sort -h
sudo lsof +L1
du ile büyük dizinleri kademeli inceleyin. lsof +L1, silinmiş ancak hâlâ açık dosyaları gösterebilir. Bir servis tarafından tutulan günlük tespit edilirse, uygulamanın desteklenen log rotasyonu veya kontrollü servis yeniden yükleme yöntemi kullanılmalıdır. Üretimde rastgele rm -rf, günlük dosyasını truncate etme veya geçici dizinleri topluca temizleme veri kaybına yol açabilir.
Veritabanı kaynaklı yazmayı doğru ele alın
MySQL/MariaDB kullanılıyorsa büyük geçici tablolar, eksik indeksler veya yoğun raporlama sorguları disk yazımını artırabilir. Önce aktif işlemleri ve yavaş sorgu kaydını inceleyin; sorgu iyileştirmesi, indeks tasarımı ve iş yükünün zamanlanması çoğu zaman disk ayarını değiştirmekten daha güvenlidir.
mysql -e "SHOW FULL PROCESSLIST;"
mysql -e "SHOW GLOBAL STATUS LIKE 'Created_tmp%';"
mysql -e "SHOW GLOBAL STATUS LIKE 'Threads_running';"
Tablo veya dosya sistemi bozulması şüphesi varsa işlem öncesi tutarlı yedek alın. InnoDB tablolarında klasik REPAIR TABLE komutunu çözüm olarak kullanmayın. Şüpheyi destekleyen hata günlükleri varsa uygun yaklaşım; mümkünse mantıksal dump alma ve temiz ortama geri yükleme, doğrulama için dikkatli CHECK TABLE veya mysqlcheck kullanımı ya da geri dönülemez hasar senaryosunda uzman gözetiminde innodb_force_recovery ile yalnızca veri kurtarmaya çalışmaktır. innodb_force_recovery normal çalışma modu değildir ve yazma yapılması veri kaybını büyütebilir.
Sanallaştırma katmanındaki çekişmeyi giderin
Konuk işletim sisteminde belirgin bir yazan süreç yokken gecikme yüksekse, sorun VM dışındadır. Hiper yönetici yöneticisi şu zaman aralığında snapshot oluşturma veya birleştirme, yedekleme, datastore doluluğu, depolama gecikmesi ve aynı datastore üzerindeki diğer yoğun VM’leri incelemelidir. Snapshot’ı yalnızca yaşına bakarak silmeyin; silme/birleştirme işlemi ek I/O üretebilir. Yeterli boş alan, güncel yedek ve bakım penceresi olmadan bu işlemi başlatmayın.
Depolama kapasitesi yetersizse kalıcı çözüm, iş yüküne uygun IOPS ve gecikme hedefi olan depolamaya geçiş, VM disk yerleşimini gözden geçirme veya iş yükünü ayırmadır. Bu karar, konuk içi metriklerle birlikte hiper yönetici ve depolama metriklerine dayanmalıdır.
Çözümü doğrulama
Yaptığınız her değişiklikten sonra aynı ölçümü tekrar edin ve önceki zaman damgalı çıktıyla karşılaştırın. Başarılı sonuç yalnızca I/O değerinin kısa süreli düşmesi değildir; uygulama yanıt süresi, hata oranı ve disk gecikmesinin normal iş yükünde istikrarlı kalmasıdır.
vmstat 1 10
iostat -xz 1 10
df -hT
sudo journalctl -p warning..alert -b --no-pager
Ayrıca web uygulaması, zamanlanmış görevler ve veritabanı için olağan bir işlem akışını test edin. Yeni dosya sistemi veya blok aygıt hatası oluşursa değişikliği geri değerlendirin ve depolama katmanında inceleme başlatın.
Önleme: Disk I/O darboğazının tekrarını azaltma
- Disk gecikmesi, doluluk, inode, iowait ve swap için eşik tabanlı izleme kurun; anlık değil eğilim odaklı alarmlar kullanın.
- Yedekleme, tarama, raporlama ve indeksleme işlerini aynı zaman penceresine yığmayın.
- Log rotasyonunu test edin; günlük saklama süresini operasyonel ve yasal ihtiyaçlara göre belirleyin.
- Veritabanı yavaş sorgularını düzenli inceleyin ve büyük sorguları düşük yoğunluk saatlerine taşıyın.
- Snapshot’ları geçici işlem olarak yönetin; uzun süre açık kalan snapshot’lar için sorumluluk ve kontrol süreci tanımlayın.
- Kapasite planında yalnızca GB/TB miktarını değil, gecikme, IOPS, eşzamanlı yük ve büyüme eğilimini de değerlendirin.
Sonuç
Sanal sunucuda yüksek disk I/O sorunu için güvenli çözüm, önce hangi katmanın yük ürettiğini kanıtlamaktır. iostat, vmstat, süreç analizi ve sistem günlükleri; uygulama kaynaklı yazma, bellek baskısı, dosya sistemi problemi ve sanallaştırma katmanı çekişmesini ayırmanıza yardım eder. Ölçmeden süreç sonlandırmak, snapshot silmek veya dosya sistemi üzerinde onarım yapmak yerine yedekli, kayıt altına alınmış ve aşamalı bir müdahale planı uygulayın.
Sık sorulan sorular
Yüksek iowait her zaman disk arızası anlamına gelir mi?
Hayır. Yoğun yedekleme, veritabanı geçici dosyaları, swap geri yazımı veya paylaşımlı depolama çekişmesi de iowait değerini yükseltebilir. Çekirdek günlüklerindeki I/O hata kayıtları arıza şüphesini güçlendirir.
Diskte boş alan varken neden I/O sorunu yaşanır?
Boş kapasite, düşük gecikme garantisi değildir. IOPS sınırı, kuyruk oluşması, snapshot işlemleri, inode tükenmesi veya başka VM’lerin datastore’u yoğun kullanması soruna yol açabilir.
Yüksek I/O sırasında sunucuyu yeniden başlatmak doğru mu?
Genellikle ilk tercih olmamalıdır. Yeniden başlatma geçici rahatlama sağlayabilir ancak nedeni gizler; aktif yazmalar ve dosya sistemi tutarlılığı açısından risk oluşturabilir. Önce kritik günlükleri ve metrikleri toplayın.
InnoDB tablosunda bozulma şüphesinde REPAIR TABLE çalıştırabilir miyim?
Hayır. REPAIR TABLE InnoDB için uygun kurtarma yöntemi değildir. Hata günlüklerine göre dump/restore, doğrulama kontrolleri, yedekten dönüş veya uzman denetiminde yalnızca kurtarma amaçlı innodb_force_recovery değerlendirilmelidir.
VM içinde sorun görünmüyorsa ne yapmalıyım?
Ölçüm zamanlarını, iostat çıktısını ve çekirdek günlüklerini saklayın. Ardından hiper yönetici yöneticisinden aynı aralık için datastore gecikmesi, snapshot, yedekleme ve kaynak çekişmesi incelemesi isteyin.
