Centos 5.5'te Basit PostgreSQL 8.4.4 Sorguları ile Son Derece Yavaş IO

Gördüğüm garip ve son derece yavaş IO kalıbı (çıktısı iostat -dxk 1 /dev/xvdb1):

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.99  0.99     7.92     3.96    12.00     1.96 2206.00 502.00  99.41

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     1.00    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     1.00    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.99  0.00     3.96     0.00     8.00     0.99 2220.00 1004.00  99.41

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     1.00    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.99  0.99  0.00     7.92     0.00    16.00     1.14 2148.00 1004.00  99.41

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     2.01    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  1.00  1.00     4.00     8.00    12.00     2.01 1874.00 502.00 100.40

Neden disk kullanımı ve beklemenin bu kadar yüksek olduğunu ve okuma / yazma oranlarının bu kadar düşük olduğunu bilmiyorum. Bunun nedeni ne olabilir?

Sorgulanan tablonun sadece birkaç varchar sütunu vardır, bunlardan biri last_name olup dizine eklenir (aslında lower(last_name)dizine eklenir). Sorgunun kendisi basittir:

SELECT * FROM consumer_m WHERE lower(last_name) = 'hoque';

İşte açıklama çıktısı:

                                           QUERY PLAN                                            
-------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on consumer_m  (cost=2243.90..274163.41 rows=113152 width=164)
   Recheck Cond: (lower((last_name)::text) = 'hoque'::text)
   ->  Bitmap Index Scan on consumer_m_last_name_index  (cost=0.00..2215.61 rows=113152 width=0)
         Index Cond: (lower((last_name)::text) = 'hoque'::text)

Ayrıca veritabanının auto_vacuum üzerinde olduğunu, bu nedenle açık vakum / analiz yapılmadığını unutmayın.

Cihazınızın /dev/xvdb1Xen altında çalıştığınızı ima etmesi. Depolama alanınız nasıl yapılandırıldı? Altta yatan cihaz için orada çekişme mıdır ve nasıl oluyor iostatifadeyi o ?

Bunu olabildiğince ortadan kaldıramazsanız, kötü performans suçunun dönen dönenini göstereceğim.

Temel olarak, böyle bir performans sorununun çözülmesine yönelik genel yaklaşım, bir darboğazın meydana gelebileceği tüm katmanları düşünmek ve ardından sorunu izole edene kadar her birini ortadan kaldırmak için testler yapmaktır.

Aşağıda, az çok rasgele sırayla bazı öneriler verilmiştir:

1. Autovacum, CentOS'ta varsayılan olarak açık değildir. Etkinleştirmek için ayarlamanız gereken birden fazla ayar vardır. Vakum işleminin gerçekten çalışması için iki kez kontrol edin. Gerekli ayarlardan birini kaçırmak kolaydır.

2. Söz konusu sorgu için geri aldığınız ürüne bağlı olarak pahalı olabilecek ikinci bir filtre adımı yapmanız gerektiğini unutmayın. Böyle bir dizin düşünecektim:

   CREATE INDEX tüketici_m_düşümüçü_Açık tüketici_m (düşük (son_adı));

   Bu, sorgunuzla eşleşecek ve Recheck'i kaldıracaktır.

3. Ayrıca, mattdm'nin belirttiği gibi, sanallaştırılmış ortamlarda iostat'a güvenemezsiniz.

4. Bir XEN ortamında GÇ sorunlarınız varsa , muhtemelen http://lonesysadmin.net/2008/02/21/elevatornoop/ adresini kontrol etmelisiniz . Asansör ayarlarının bir etkisi olabilir, ancak bu kadar büyük olmayabilir.

5. Altta yatan disk LVM anlık görüntüleri kullanıyor mu? Bu bir yönetim açısından çok yararlı olsa da IO performansını öldürebilir. Bu, hem kullandığınız blok cihazı bir anlık görüntü ise hem de blok cihazın bir anlık görüntüsü alınmışsa geçerlidir.

Bu PostgreSQL ile ilgili bir sorun olduğunu ve daha büyük olasılıkla sadece Disk IO ile ilgili bir sorun olduğundan şüpheliyim. Başka bir cevabın yorumlarından bahsedildiği gibi, bu bir disk IO sorunu ise, Dom0'dan gerçekten ölçmelisiniz, böylece olan her şeyin bir resmini elde edersiniz.

Bir süre önce çok benzer bir sorun yaşadım ve disk denetleyicisiyle ilgili bir sorun olduğu ortaya çıktı. Çok yavaş disk erişimi, disk IO'sunu beklerken sistemin tıkanmasına neden oluyordu (bu da çok yüksek yük ortalamaları ve bekleme süreleri olarak ortaya çıktı, ancak diskin bekleyen işlemlerin aksi takdirde daha fazla CPU tüketmesine neden oldu. denetleyiciyi doğru tanımıyordu ve hızlı bir sata yerine eski okul IDE denetleyicisine geri dönüyordu.

Düzeltme önyükleme yapmaktı

hda=noprobe hda=none 

/etc/grub.conf dosyasındaki çekirdek dizesinin sonunda. (Elbette, sahip olduğunuz tüm diskleri ekleyin, ala: hdc=noprobe, hdc=none, hdd=...)