iostat ve iotop: Linux depolama darboğazlarını teşhis etme

Bir Linux sunucusu yavaşladığında, ilk bakılması gereken yerlerden biri depolamadır. iostat, diskin aşırı yüklenip yüklenmediğini gösterir; iotop ise yükü hangi işlemin oluşturduğunu gösterir. Birlikte kullanıldıklarında, önemli olan iki soruyu yanıtlarlar: disk gerçekten darboğaz mı ve eğer öyleyse, onu zorlayan nedir? Bu yazı, kurulumu, çıktının nasıl okunacağını (iostat'ın %util metriklerinin modern donanımlarda nerede yer aldığı dahil) ve semptomdan çözüme giden bir iş akışını ele almaktadır.

iostat ve iotop'u yükleme

iostat, sysstat paketi ile birlikte gelir; iotop ise ayrı olarak dağıtılır. Her ikisini de kurun:

# Debian/Ubuntu
sudo apt install sysstat iotop
 
# RHEL, AlmaLinux, Rocky, CentOS Stream
sudo dnf install sysstat iotop
 
# Arch
sudo pacman -S sysstat iotop

Ubuntu'da sysstat devre dışı olarak gelir. Daha sonra sar, /etc/default/sysstat, ENABLED="true"ve hizmeti yeniden başlatın:

sudo systemctl restart sysstat

iotop, root olarak çalıştırılmalıdır. RHEL 9 ve daha yeni sürümlerde, gecikme hesaplaması varsayılan olarak devre dışıdır; bu da IO ve SWAPIN sütunları boş kalır. Aşağıdaki komutla etkinleştirin:

echo 1 | sudo tee /proc/sys/kernel/task_delayacct

Add kernel.task_delayacct = 1 dosyasına /etc/sysctl.conf dosyasına ekleyin.

iostat çıktısını okuma

Genişletilmiş istatistiklerle iostat'ı çalıştırın ve yalnızca önyüklemeden bu yana ortalamaları gösteren ilk örneği göz ardı edin:

iostat -xz 2

-x -x bayrağı genişletilmiş istatistikler ekler, -z boşta olan cihazları gizler ve 2 iki saniyede bir yenilenir. Önemli sütunlar:

• await: kuyruk süresi dahil olmak üzere bir I/O isteğinin tamamlanması için geçen ortalama süre (milisaniye cinsinden). Kullanıcılar yavaşlıktan şikayet ettiğinde en önemli tek rakam budur.
• r/s ve w/s: okuma ve yazma IOPS. rkB/s ve wkB/s bunlarla birlikte, iş yükünüzün rastgele (yüksek IOPS, düşük verim) mi yoksa sıralı (düşük IOPS, yüksek verim) mi olduğunu gösterir.
• aqu-sz: ortalama kuyruk derinliği. HDD'ler için, 1'in üzerinde kalıcı bir değer, diskin iş yüküne yetişemediği anlamına gelir.
• %util: Aygıtın en az bir aktarım halindeki I/O'su olduğu sürenin yüzdesi. HDD'lerde yararlıdır, NVMe'de yanıltıcıdır (aşağıya bakın).

Hızlı bir eşik referansı:

%util'in bulunduğu yer

%util , çoğu kişinin ilk olarak baktığı metriktir ve NVMe'de bu aktif olarak yanıltıcıdır. Çekirdek %util "herhangi bir anda işlenmekte olan herhangi bir I/O" olarak sayar; bu, bir seferde tek bir isteği işleyen dönen bir disk için uygundur, ancak donanım kuyrukları üzerinden binlerce isteği paralel olarak işleyen NVMe aygıtları için anlamsızdır. Bir NVMe sürücüsü, gerçek kapasitesinin %5'inde çalışırken %util , ancak gerçek kapasitesinin %5'inde çalışabilir.

NVMe'de r_await, w_awaitve aqu-sz buna güvenin. r_await 1 ms'nin altında kalırsa ve kuyruk derinliği cihazın donanım kuyruk derinliğinin (genellikle 1024 veya daha yüksek) oldukça altındaysa, %util ne derse desin.

kB/s yerine MB/s cinsinden hızlı bir NVMe görünümü için:

iostat -xm 1

Uzun vadeli toplama için daha sonra uygulama günlükleriyle ilişkilendirebilirsiniz:

iostat -x -t 5 720 > /var/log/iostat.log

Bu, bir saat boyunca her 5 saniyede bir örnekleme yapar. sar Aynı sysstat paketinden alınan veriler, kalıcı geçmiş depolama ile eşdeğer veriler sağlar ve sürekli izleme için daha iyi bir seçimdir.

CPU iowait ile doğrulama

iostat depolama stresi gösteriyorsa, aynı çıktının üst kısmındaki CPU özetindeki %iowait sütunuyla çapraz kontrol edin. Sürekli %iowait %15-20'nin üzerinde kalması ve yüksek await değeri, darboğazın depolama olduğunu doğrular. Eğer %iowait yüksekse ancak await normal görünüyorsa, vmstat 1 ve si ve so sütunlarını kontrol edin. Sıfırdan farklı takas etkinliği, bellek sınırlı olduğunuzu ve disk trafiğinin uygulama G/Ç'si değil, sayfalama olduğunu gösterir.

iotop çıktısını okuma

iostat bir depolama darboğazını doğruladıktan sonra, iotop hangi işlemin sorumlu olduğunu size bildirir. Şu komutla başlayın:

sudo iotop -o

- -o bayrağı, boşta olan işlemleri gizler ve yalnızca aktif olarak I/O yapanları bırakır. Dikkat edilmesi gereken sütunlar:

• DISK READ / DISK WRITE: işlem başına gerçek zamanlı verim. Bariz ağır yükü olanları belirler.
• IO: İşlemin I/O'da bloke olduğu sürenin yüzdesi. Sadece 50 kB/s yazan bir işlem, küçük senkron fsync() çağrıları yapıyorsa %99 IO gösterebilir. Bu sütun, ham verimden daha önemlidir.
• SWAPIN: takas sayfalarında bekleme süresinin yüzdesi. Buradaki değerin sıfırdan farklı olması, sistemin sayfalandırma yaptığı ve "depolama sorununuzun" aslında bir bellek sorunu olduğu anlamına gelir.

Çok iş parçacıklı uygulamalar için (MySQL, PostgreSQL, Java iş yükleri), iş parçacıklarını -Pve -a iotop'un başladığı andan itibaren toplamları biriktirmek için:

sudo iotop -oPa

`-c` -a bayrağı, bir seferde sadece birkaç saniye çalışan ve aksi takdirde canlı görünümde tespit edilmesi zor olan yedekleme işleri gibi ani iş yüklerini yakalamak için bir püf noktasıdır.

Kimsenin izlemediği gece saatlerinde gözetimsiz günlük kaydı için:

sudo iotop -botqq -d 10 > /var/log/iotop.log

Bu, her 10 saniyede bir etkileşimsiz bir anlık görüntü yazar. Bunu yedekleme veya cron işlerinizden gelen zaman damgalarıyla eşleştirerek, olaydan sonra sorunun kaynağını bulabilirsiniz.

Bir tanılama iş akışı

Çoğu disk I/O araştırması aynı yolu izler:

1. iostat -xz 2 diskin gerçekten darboğaz olup olmadığını doğrulamak. Şuraya bakın await, aqu-szve %iowait. Bunlar normalse, sorun depolamada değildir ve tamamen başka bir yere bakmalısınız.
2. iotop -oPa Yükü oluşturan işlemi bulmak için. Verim sütunundan çok IO sütununa bakın. En kötü suçlular genellikle en fazla bayt aktaran programlar değil, çok sayıda küçük senkron yazma işlemi yapan programlardır.
3. lsof -p <pid> Bu işlemin hangi dosyalara dokunduğunu görmek için. Bu genellikle iş yükü türünü hemen belirler: bir veritabanı önceden yazma günlüğü, bir uygulama günlük dosyası, bir yedekleme bağlama noktası, bir geçici dosya.

Bilmeniz gereken iki model.

(ext4 journal) gibi çekirdek iş parçacıkları görürseniz jbd2/... (ext4 journal) veya txg_sync (ZFS) gibi çekirdek iş parçacıkları görürseniz, bunlar yazma işlemlerini başlatmıyor, diğer işlemlerden gelen yazma işlemlerine yanıt veriyorlar. Günlük trafiğini yönlendiren kullanıcı alanı işlemi asıl nedendir; araştırmaya devam edin.

Bir VPS'de, yüksek await ve düşük %util değerleri, klasik "gürültücü komşu" sinyalidir. Başka bir kiracı paylaşılan depolama alanını tek başına kullanıyor ve I/O'nuz sanal diskinizde değil, hipervizör tarafında kuyrukta bekliyor. Bunu konuk sistem içinden doğrulayabilirsiniz ancak düzeltemezsiniz; çözüm, ya sağlayıcıya bildirmek ya da yalıtılmış depolama alanına sahip bir sunucuya geçmektir.

Yaygın I/O darboğazlarını giderme

Diski etkileyen sorunun ne olduğunu belirledikten sonra, çözümler genellikle basittir.

Kritik olmayan I/O'ların önceliğini düşürün. ionice bir işlemi boşta zamanlama sınıfına yerleştirir; burada işlem, başka hiçbir şey disk bant genişliğini istemediğinde disk bant genişliğini kullanır:

ionice -c 3 -p <pid>
sudo ionice -c 3 rsync -a /data /backup

İlk form çalışan bir işlemi değiştirir; ikincisi ise zaten boşta sınıfında bulunan yeni bir işlem başlatır. iotop içinde, i tuşuna basarak çalışan bir işlemin önceliğini etkileşimli olarak değiştirebilirsiniz.

Yoğun iş yüklerini daha hızlı depolama alanına taşıyın. iostat, bir SATA diskin veritabanı yazma işlemleri nedeniyle aşırı yüklü olduğunu gösteriyorsa ve aynı kutuda boşta duran bir NVMe varsa, veritabanı veri dizinini başka bir yere taşıyın. IOPS'deki büyük fark, bunu mevcut en etkili çözüm haline getirir.

Doğru I/O zamanlayıcısını ayarlayın. Modern çekirdekler varsayılan olarak makul ayarlara sahiptir, ancak kontrol etmeye değer. NVMe ve SSD'ler için zamanlayıcıyı noneolarak ayarlayın. Aygıt, kuyruklamayı çekirdeğin yapabileceğinden daha iyi bir şekilde donanım düzeyinde yönetir:

echo none > /sys/block/nvme0n1/queue/scheduler

Karışık iş yüklerini işleyen HDD'ler için mq-deadline genellikle tercih edilen seçenektir.

noatime ile bağlayın. Her okuma işlemi varsayılan olarak dosyanın son erişim zaman damgasını günceller ve her okuma için bir yazma işlemi oluşturur. Okuma yoğunluğu yüksek dosya sistemlerinde bu gereksiz bir I/O işlemidir. noatime 'yi /etc/fstab:

UUID=... /data ext4 defaults,noatime 0 2

Ani yazma işlemleri için yazma geri dönüşünü ayarlayın. Bol miktarda RAM'e sahip sunucularda, varsayılan kirli sayfa eşikleri, sayfa önbelleğinin gigabaytlarca yazılmamış veri biriktirmesine izin verir, ardından bunu tek bir büyük işlemde boşaltır. Bunu düzeltmek için /etc/sysctl.conf düşürün:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

Sorun genellikle diskin kendisinde değildir. iostat yüksek IOPS ve düşük verim gösterdiğinde, iş yükü sıralı olabilecek veriler üzerinde rastgele I/O yapıyor veya toplu işlenebilecek birçok küçük yazma işlemi gerçekleştiriyor olabilir. Donanımı suçlamadan önce uygulamaya bakın.

Ağın diski geride bırakabileceği bir sunucuda depolama yoğun iş yükleri çalıştırıyorsanız, FDC'nin NVMe destekli özel sunucuları, yukarıdaki ayarlamaları verimli bir şekilde uygulamanız için size gerekli esnekliği sağlar.