IO Sangat Lambat dengan Simple PostgreSQL 8.4.4 Kueri di Centos 5.5

10

Pola IO aneh dan sangat lambat yang saya lihat adalah ini (output 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

Saya tidak tahu mengapa pemanfaatan disk dan menunggu sangat tinggi, dan tingkat baca / tulis sangat rendah. Apa alasannya?

Tabel yang ditanyai hanya memiliki beberapa kolom varchar saja, salah satunya adalah last_name, yang diindeks (sebenarnya lower(last_name)diindeks). Permintaannya sendiri sederhana:

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

Inilah output yang dijelaskan:

                                           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)

Juga catat bahwa database ada di auto_vacuum, jadi tidak ada kekosongan / analisis eksplisit yang dilakukan.

performance postgresql hard-drive iostat ehsanul
sumber
Apakah Anda mengkustomisasi postgresql.conf Anda? Jika CentOS memiliki standar yang sama dengan RHEL 5.x Anda akan memiliki sedikit memori untuk postgres, yang dapat memaksa banyak IO disk. Seberapa besar baris pada tabel ini?
Thiago Figueiro
Tabel sesuai dengan memori, seperti halnya indeks; dipartisi seperti itu. Dan postgresql.conf telah dikustomisasi dengan tepat (shared_buffers, effective_cache_size dll). Bahkan jika ini tidak terjadi, saya tidak akan mengharapkan kinerja yang merosot seperti itu.
ehsanul

Jawaban:

5

Fakta bahwa perangkat Anda /dev/xvdb1menyiratkan bahwa Anda menjalankan di bawah Xen. Bagaimana penyimpanan Anda dikonfigurasi? Apakah ada pertentangan untuk perangkat yang mendasari, dan bagaimana iostatraut itu ?

Kecuali jika Anda bisa menghilangkan itu sebagai kemungkinan, di situlah saya akan menunjukkan pemintal menyalahkan kinerja yang buruk.

Pada dasarnya, pendekatan keseluruhan untuk mengurai masalah kinerja seperti ini adalah untuk memikirkan semua lapisan di mana hambatan dapat terjadi, dan kemudian menyusun tes untuk menghilangkan masing-masing sampai Anda mengisolasi masalah.

mattdm
sumber
Tidak ada pertentangan. Meskipun Anda benar bahwa ini adalah server virtual, hard disk telah sepenuhnya didedikasikan untuk server ini, dan saya hanya menjalankan satu permintaan basis data pada satu waktu tanpa operasi server intensif lainnya. Penyimpanan hanyalah disk SATA berputar tunggal. Perhatikan bahwa saya memiliki beberapa server / database (terpisah) lainnya dengan pengaturan yang hampir sama, tetapi bekerja cepat dengan IO rendah, seperti yang diharapkan, diberikan pertanyaan / pengindeksan yang serupa.
ehsanul
Bisakah Anda menjalankan iostatpada disk dari dom0 hanya untuk melihat apakah gambarnya mirip? Bisakah Anda melakukan beberapa tolok ukur disk dasar lainnya dari kedua level? Setidaknya itu akan membantu mempersempit ke mana harus mencari berikutnya.
mattdm
Tentu. Mengapa Anda mengharapkan perbedaan berdasarkan dari mana iostatlari? Haruskah itu penting? Saya sebenarnya tidak memiliki akses langsung ke dom0 sekarang, meskipun saya bisa mendapatkannya. Saya akan mencoba fiomelakukan pembandingan sementara.
ehsanul
3
untuk satu hal: foto dapat menciptakan situasi seperti itu
Hubert Kario
3
Anda benar mattdm, ada pertentangan, muncul di dom0. Itu adalah masalah komunikasi, bos saya telah memberikan sebagian hard disk ke server lain di bawah manajemen orang lain, tanpa sepengetahuan saya. Saya mendapat kesan bahwa itu didedikasikan, karena itulah kami selalu mengaturnya. Saya kira itu sebabnya selalu penting untuk memeriksa ulang asumsi Anda. Terima kasih!
ehsanul
1

Berikut adalah beberapa saran, dalam urutan acak:

  1. Autovacum tidak diaktifkan secara default di CentOS. Ada beberapa pengaturan yang harus Anda atur untuk mengaktifkannya. Periksa ulang agar proses vacum benar-benar berjalan. Sangat mudah untuk melewatkan salah satu pengaturan yang diperlukan.

  2. Perhatikan bahwa Anda harus melakukan langkah filter kedua untuk permintaan itu, yang bisa mahal tergantung pada apa yang Anda dapatkan kembali. Saya akan mempertimbangkan indeks seperti:

    CREATE INDEX consumer_m_lower_last ON consumer_m (lebih rendah (nama belakang));

    Yang akan cocok dengan kueri Anda dan menghapus Periksa ulang.

  3. Juga, seperti yang ditunjukkan oleh mattdm, Anda tidak dapat mempercayai iostat dalam lingkungan tervirtualisasi.

  4. Anda mungkin harus memeriksa http://lonesysadmin.net/2008/02/21/elevatornoop/ jika Anda memiliki masalah IO di lingkungan XEN. Pengaturan lift dapat berdampak, tetapi tidak sebesar ini.

  5. Apakah disk yang mendasarinya menggunakan snapshot LVM? Meskipun ini sangat berguna dari sudut pandang manajemen, itu dapat membunuh kinerja IO. Ini benar baik jika perangkat blok yang Anda gunakan adalah snapshot, dan jika snapshot telah diambil dari perangkat blok.

pehrs
sumber
Terima kasih atas sarannya. Indeks sebenarnya di bawah (last_name), meskipun saya meninggalkan "lebih rendah" dari nama indeks. Jadi saya tidak tahu mengapa ada pemeriksaan ulang di sana. Disk yang dipasang /menggunakan snapshot LVM sebenarnya, tetapi bukan yang di mana database disimpan. Jadi saya tidak berpikir begitu. Saya akan melihat saran Anda yang lain!
ehsanul
1

Saya ragu ini adalah masalah dengan PostgreSQL, dan lebih cenderung hanya masalah dengan Disk IO. Seperti komentar dari jawaban lain menyebutkan, jika itu adalah masalah IO disk, Anda benar-benar harus mengukur dari Dom0 sehingga Anda mendapatkan gambar dari segala sesuatu yang terjadi.

Saya punya masalah yang sangat mirip beberapa waktu lalu dan ternyata menjadi masalah dengan pengontrol disk. Akses disk yang sangat lambat menyebabkan sistem macet saat menunggu disk IO (yang muncul sebagai rata-rata beban sangat tinggi dan waktu tunggu, tetapi juga menyebabkan proses menunggu disk untuk mengkonsumsi lebih banyak CPU daripada yang seharusnya. Ternyata kernel tidak mengenali controller dengan benar dan jatuh kembali ke pengendali IDE sekolah lama bukannya yang cepat.

Cara mengatasinya adalah dengan boot 

hda=noprobe hda=none

di akhir string kernel di /etc/grub.conf. (Tentu saja, tambahkan semua disk yang Anda miliki, ala: hdc=noprobe, hdc=none, hdd=...)

Jed Daniels
sumber
Terima kasih, tetapi ternyata itu adalah sesuatu yang jauh lebih konyol dalam kasus ini. Pilih bagaimanapun juga.
ehsanul