Yüksek IO bekleme - Temel nedeni nasıl belirlenir?


10

İki özel sunucuda bir MySQL örneğim var. Biri üretim için, diğeri test platformu için.

2 sunucu aynıdır, tek fark RAID denetleyicisi ve sanal birimdir (HD aynıdır). Üretimde özel bir HW RAID denetleyicisi ve bir RAID 10 birimi var. Diğer yandan, RAID denetleyicisi yazılım (Lenovo ThinkServer RAID 110i) gibi görünüyor ve birim RAID 5.

MySQL işlemlerinde yüksek düzeyde iowait olduğunu fark ettik:

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

dm-10-8 ve dm-14-8 veritabanı bölümleriyle ilgilidir.

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

Baskın denetleyicisinden şüpheleniyorum, nasıl emin olabilirim?


Belki konu dışı: Ama neden bir veritabanında RAID5? Yazma boşluğu nedeniyle kötü fikir. BBU'lu HW bunu biraz hafifletir, ancak RAID 5 temel olarak küçük işlemler yazmak için değil, okumak için iyidir.
Hennes

Başka seçeneğim olmadığı için ... RAID 10, bu RAID denetleyicisinde (RHEL sürümümle) desteklenmedi ...
Bob Sauvage

@BobSauvage herhangi bir ilerleme var mı?
Huygens

sadece açık olmak gerekirse: io-wait, yığın depolama tarafından sağlanmayan dosya tanımlayıcıları da bekler mi? prizler gibi ...
Massimo

Yanıtlar:


7

Cevabımın 2 bölümü vardı: blok aygıt sürücüsünün araştırılması; ve kullanım durumunuza bakmaya değer optimizasyon. Ancak veri kaybına neden olabileceği bildirildiği için son bölümü kaldırdım. Yorumlara bakınız.

Donanımın İncelenmesi

Aynı uygulama için ancak 2 farklı donanım setinde performansın çok farklı olduğunu ve nedenini anlamak istediğinizi anladım. Bu yüzden önce "neden" için bir cevap bulmanıza yardımcı olacak bir araç öneriyorum.

Performans için, genellikle blogunda Brendan Gregg tarafından sağlanan Linux Performans Haritasına başvuruyorum . Düşük seviye (donanıma en yakın) için bir aracın blktracemükemmel olacağını görebilirsiniz.

Bu aracı gerçekten bilmiyorum, etrafına baktım ve Marc Brooker'ın blktrace ile ilgili bu ilginç makalesini buldum . Temel olarak aşağıdakileri önerir: kullanarak bir G / Ç izlemesi yapmak blktrace; bu izlemeden bilgi almak için btt aracını kullanarak . Bu böyle bir şey olurdu (30 saniyelik bir iz için):

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

Çıkış oldukça uzun olabilir, ancak D2C girişlerini arayın. Aygıt sürücüsüne gönderilen bir G / Ç'nin bu sürücü tarafından tamamlandığı bildirildiği zaman hakkında bir fikir verecektir.

Örnek çıktı ( dnf upgrademeşgul dizüstü bilgisayarımdaki bir VirtualBox VM'de çalışıyor):

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

En kötü durum için 3,94 s'ye kadar I / O başına 45 ms hayal kırıklığı yaratan bir ortalama gösterir!

Bu araştırmayı yapmak için blktrace'ı kullanmanın daha fazla yolu için, Marc Brooker'ın çok öğretici makalesini okuyun.


Innodb performansını artırmak için cevap tweak referans Percona blog yazısı ile güncellendi: Güncelleme: bunu yapmayın, bu verileri bozduğu kanıtlanmıştır!
vkats

@vkats çok teşekkürler. Öneri ve makaleyi kaldırmak için cevabı güncelledim.
Huygens

1

jbd2 işlemi ext4 günlük kaydı içindir. Dosya sisteminin mysql işlemleri sırasında günlüğe yazması gerektiği mantıklıdır, bu herhangi bir endişenin nedeni olmamalıdır. Jbd'nin neden olduğu yük miktarı dm-10-8 ve dm-14-8 bölümleri için montaj parametrelerinizden etkilenir. Bir şey olursa veritabanınızın bozulmamasını ve sunucunuzun yanlışlıkla yeniden başlatılmasını sağlamak için veritabanı bölümünde çok muhafazakar dergi bulundurmak büyük olasılıkla arzu edilir. Sadece karşılaştırma için test ortamında başka bir günlük kaydı bağlama seçenekleri belirleyebilirsiniz.


benim jbd2 / dm-2-8 iotop her zaman yaklaşık 8.5% gibi görünüyor, ama .. Hiçbir disk okuma olduğu gibi sorunlu olduğunu sanmıyorum ve toplam disk yazma 1 saat sonra 35mb olduğunu. btw, / dev'de en fazla dm-2 vardır (bu -8'in nereden geldiğini bilmiyorum ..)
Kova Gücü
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.