IO cực kỳ chậm với các truy vấn đơn giản PostgreQuery 8.4.4 trên Centos 5.5

Mẫu IO lạ và cực kỳ chậm mà tôi thấy là đây (đầu ra của 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

Tôi không biết tại sao việc sử dụng đĩa và chờ đợi lại quá cao và tốc độ đọc / ghi rất thấp. Lý do cho điều này là gì?

Bảng được truy vấn đơn giản chỉ có một số cột varchar, một trong số đó là last_name, được lập chỉ mục (thực sự lower(last_name)được lập chỉ mục). Bản thân truy vấn rất đơn giản:

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

Đây là đầu ra giải thích:

                                           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)

Cũng lưu ý rằng cơ sở dữ liệu là trên auto_vacuum, vì vậy không có phân tích / chân không rõ ràng nào được thực hiện.

Thực tế là thiết bị của bạn /dev/xvdb1ngụ ý rằng bạn đang chạy theo Xen. Bộ nhớ của bạn được cấu hình như thế nào? Có cạnh tranh cho các thiết bị cơ bản, và như thế nào iostatnhìn vào đó ?

Trừ khi bạn có thể loại bỏ điều đó rất có thể, đó là nơi tôi sẽ chỉ ra kẻ quay vòng quay cuồng của sự đổ lỗi hiệu suất kém.

Về cơ bản, cách tiếp cận tổng thể để giải quyết vấn đề hiệu năng như thế này là suy nghĩ về tất cả các lớp có thể xảy ra tắc nghẽn, và sau đó đưa ra các thử nghiệm để loại bỏ từng vấn đề cho đến khi bạn tách biệt vấn đề.

Dưới đây là một số gợi ý, theo thứ tự ngẫu nhiên nhiều hay ít:

1. Autovacum không được bật theo mặc định trong CentOS. Có nhiều cài đặt bạn phải đặt để kích hoạt nó. Kiểm tra lại để quá trình trống thực sự chạy. Thật dễ dàng để bỏ lỡ một trong các cài đặt cần thiết.

2. Lưu ý rằng bạn phải thực hiện bước lọc thứ hai cho truy vấn đó, có thể tốn kém tùy thuộc vào những gì bạn nhận lại. Tôi sẽ xem xét một chỉ số như:

   TẠO INDEX Consumer_m_lower_last ON Consumer_m (thấp hơn (last_name));

   Cái nào sẽ phù hợp với truy vấn của bạn và loại bỏ Recheck.

3. Ngoài ra, như mattdm chỉ ra, bạn không thể tin tưởng vào iuler trong môi trường ảo hóa.

4. Bạn có thể nên kiểm tra http://lonesysadmin.net/2008/02/21/elevatornoop/ nếu bạn gặp vấn đề về IO trong môi trường XEN. Cài đặt thang máy có thể có tác động, nhưng không lớn như vậy.

5. Là đĩa bên dưới sử dụng ảnh chụp nhanh LVM? Mặc dù điều này rất hữu ích từ góc độ quản lý, nó có thể giết chết hiệu suất IO. Điều này đúng cả nếu thiết bị khối mà bạn sử dụng là ảnh chụp nhanh và nếu ảnh chụp nhanh đã được chụp từ thiết bị khối.

Tôi nghi ngờ đây là một vấn đề với PostgreSQL và nhiều khả năng chỉ là sự cố với Disk IO. Như các ý kiến ​​từ một câu trả lời khác đề cập, nếu đó là vấn đề IO của đĩa, bạn thực sự nên đo từ Dom0 để bạn có được hình ảnh về mọi thứ đang xảy ra.

Tôi đã có một vấn đề rất giống một lúc trước và hóa ra đó là một vấn đề với bộ điều khiển đĩa. Truy cập đĩa rất chậm đã khiến hệ thống bị nghẽn cổ chai trong khi chờ IO đĩa (xuất hiện ở mức trung bình tải rất cao và thời gian chờ, nhưng cũng khiến các quá trình chờ đĩa tiêu thụ nhiều CPU hơn so với cách khác. đã không nhận ra bộ điều khiển đúng cách và rơi vào bộ điều khiển IDE trường cũ thay vì bộ điều khiển sata nhanh.

Cách khắc phục là khởi động với

hda=noprobe hda=none 

ở cuối chuỗi kernel trong /etc/grub.conf. (Tất nhiên, thêm tất cả các đĩa bạn có, ala: hdc=noprobe, hdc=none, hdd=...)