CPU I / O% 50 civarında sabit beklemek var, ama çalıştırdığımda iostat 1disk aktivitesi az veya hiç gösterir.

İops olmadan beklemeye ne sebep olur?

NOT: Burada NFS veya FUSE dosya sistemi yoktur, ancak Xen sanallaştırmasını kullanıyor.

NFS bunu yapabilir ve diğer ağ dosya sistemlerinin (ve hatta FUSE tabanlı cihazların) benzer etkilere sahip olması beni şaşırtmaz.

Sunucudaki diğer VM'lerin diski atma şansı var mı?

Sanallaştırma ile, ana bilgisayar düğümü aşırı yüklenmişse bazı garip sonuçlar elde edebileceğinizi biliyorum.

Bu, örnek tabanlı depolama kullanan Amazon EC2 Xen ortamı ise, Amazon'dan bu resmi içeren ana bilgisayarın sağlığını kontrol etmesini isteyin.

Bu, hiper yöneticiye erişebileceğiniz bir Xen ortamı ise, IOwait'i xvda ve xvdb aygıtları için kullanılan disk görüntüsü (dosya, ağ, LVM dilimi, ne olursa olsun) olmadan kontrol edin. Ayrıca, diğer disk aygıtları sistemin kaynaklarını tekelleştirebileceğinden, G / Ç sistemini genel olarak hiper denetimci için kontrol etmek istersiniz.

iostat -txk 5

genellikle iyi bir başlangıç ​​teşhis aracıdır. Kullanabileceği TÜM aygıtlar için 5 saniyelik G / Ç özetleri alır ve bu nedenle VM görüntüsünün hem içeri hem de dışarı solması için yararlıdır.

Kullanılabilir dosya tanımlayıcılarınızı / düğümlerinizi kontrol edin. Sınıra geldiğinizde takas yaparlar ve iowait'i taklit ederler

Düzenle

Xen kullandığınızı gördüm, mevcut kesintilerinize bir bakın, blkif'in normalden daha yüksek olduğunu görebilirsiniz.

Şimdi biraz geç ama munin kur ve gelecekteki hata ayıklamaya gerçekten yardımcı olacak.

sudo sysctl vm.block_dump=1

Daha sonra blok okuma / yazma veya kirletici düğümleri neyin gerçekleştirdiğini görmek için dmesg'i kontrol edin.

Ayrıca limit.conf dosyasındaki nofile sınırını kontrol edin, bir işlem açılmasına izin verilenden daha fazla dosya istiyor olabilir.

UYARI: HDPARM TEHLİKELİDİR, HER ZAMAN KULLANIM KOMUTUNU OKUYUN!

Sabit disk (ler) i vurgulayan başka hiçbir sanal makine yoksa,

hdparm -f

temel fiziksel disk (ler) üzerinde. Disk önbelleği düzgün çalışmıyor olabilir. Bu, önbellekte depolanan verileri temizler ve yıkamadan sonra tekrar yükselmek üzere olup olmadığını G / Ç'yi sürekli olarak izleyebilirsiniz. Evetse, bir önbellek sorunu olacaktır.

Yük ortalaması ile, engellenen ağ işlemlerinin (harici bir DB sunucusuna yapılan uzun çağrıların) arttığını gördüm. Emin değilim ama ağ IO'nun CPU bekleme süresinin artmasına neden olabileceğini tahmin ediyorum. Herkes onaylayabilir mi?

Kendileri ağ üzerinden monte edilen geri döngü cihazları olabilir.

Makinelerimde NFS en büyük IO-WAIT "yapımcısı". Dizüstü bilgisayarımda bir cehennem gibi hızlı bir SSD var, bu yüzden "gerçek IO" sorun değil. Yine de monte nfs paylaşımları nedeniyle bazen IO bekleme çok var.

SCP bazen IO Wait'e de yol açmış gibi görünür ancak çok daha az uzar.

Bu her şey olabilir. Bu sadece bir şeyin G / Ç işleminin bitmesini beklediği anlamına gelir. Hangi işlemin ps yoluyla olduğunu anlayabilir, daha sonra gdb'yi ekleyebilir ve hangi çağrının asılacağını belirlemek için geri izlemeye bakabilirsiniz (genellikle bu ağla ilgili bazı şeyler veya aniden bağlantısı kesilmiş bir disktir). Fd bilgisi için / proc.

RAID'deki bir disk başarısız olmadan ve bunlarda sıkı kıvrımlara sahip bazı SATA kablolarının arızalanmasından hemen önce benzer bir sorun yaşadım .

CPU kullanımı% 0'a yakındı, ancak 4 çekirdekli bir sistemdeki 1 veya daha fazla CPU, zamanlarının% 100'ünü topçok düşük IOps ve bant genişliğiyle (bulunan) uzun süreler boyunca ( çok satırlı işlemci ekranıyla bulundu) IOwait'te geçiriyordu yoluyla iostat), ancak patlama yüksek kesme aktivitesi. Etkileşimli komut satırı kullanımı herhangi bir disk erişimi sırasında acı vericiydi (yani birinin emacsoturumundan otomatik kaydetme ), ancak IOwait süreleri geçtikten sonra (ve muhtemelen birçok yeniden denemeden sonra işlemler başarılı oldu) başka bir şekilde tolere edilebilir.