Centos 5.5의 간단한 PostgreSQL 8.4.4 쿼리로 매우 느린 IO

내가보고있는 이상하고 매우 느린 IO 패턴은 다음과 같습니다 (출력 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

디스크 사용률 및 대기가 왜 그렇게 높으며 읽기 / 쓰기 속도가 너무 낮은 지 모르겠습니다. 그 이유는 무엇입니까?

쿼리되는 테이블에는 단순히 여러 개의 varchar 열만 있으며 그 중 하나는 last_name이며 인덱스 lower(last_name)는 실제로 인덱스됩니다. 쿼리 자체는 간단합니다.

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

Explain 출력은 다음과 같습니다.

                                           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)

또한 데이터베이스가 auto_vacuum에 있으므로 명시적인 진공 / 분석이 수행되지 않았습니다.

장치가 /dev/xvdb1Xen에서 실행되고 있음을 의미합니다. 스토리지는 어떻게 구성되어 있습니까? 기본 장치가 경합인가, 어떻게 수행 iostat에 모습을 그 ?

가능한 한 그것을 제거 할 수 없다면, 그 곳에서 성능 비난의 소용돌이 치는 회 전자를 가리킬 것입니다.

기본적으로 이와 같은 성능 문제를 풀기위한 전반적인 접근 방식은 병목 현상이 발생할 수있는 모든 계층에 대해 생각한 다음 문제를 격리 할 때까지 각 계층을 제거하기위한 테스트를 고안하는 것입니다.

다음은 임의 순서로 제안됩니다.

1. CentOS에서는 Autovacum이 기본적으로 켜져 있지 않습니다. 활성화하려면 여러 설정을해야합니다. vacum 프로세스가 실제로 실행되도록 다시 확인하십시오. 필요한 설정 중 하나를 놓치기 쉽습니다.

2. 해당 검색어에 대해 두 번째 필터 단계를 수행해야하며,이 정보에 따라 비용이 많이들 수 있습니다. 나는 다음과 같은 색인을 고려할 것이다.

   인덱스 INDEX consumer_m_lower_last ON consumer_m (lower (last_name));

   쿼리와 일치하고 다시 검사를 제거합니다.

3. 또한 mattdm이 지적했듯이 가상화 된 환경에서 iostat를 신뢰할 수 없습니다.

4. XEN 환경에서 IO 문제가있는 경우 http://lonesysadmin.net/2008/02/21/elevatornoop/을 확인해야 합니다. 엘리베이터 설정은 영향을 줄 수 있지만이 정도는 아닙니다.

5. 기본 디스크가 LVM 스냅 샷을 사용합니까? 관리 측면에서 매우 유용하지만 IO 성능을 저하시킬 수 있습니다. 사용중인 블록 장치가 스냅 샷이고 블록 장치의 스냅 샷이 생성 된 경우에도 마찬가지입니다.

이것이 PostgreSQL의 문제이며 의심 할 여지없이 디스크 IO의 문제 일 것입니다. 다른 답변의 의견에서 언급했듯이 디스크 IO 문제 인 경우 Dom0에서 실제로 측정하여 발생하는 모든 것을 파악해야합니다.

나는 아주 비슷한 문제가 있었고 디스크 컨트롤러에 문제가있는 것으로 나타났습니다. 디스크 액세스 속도가 너무 느려 디스크 IO를 기다리는 동안 시스템 병목 현상이 발생했습니다 (로드 평균 및 대기 시간이 매우 높음) 컨트롤러를 제대로 인식하지 못하고 빠른 SATA 컨트롤러 대신 구식 IDE 컨트롤러로 되돌아갔습니다.

수정은 함께 부팅했다

hda=noprobe hda=none 

/etc/grub.conf의 커널 문자열 끝에서 (물론, 당신이 가지고있는 모든 디스크를 추가하십시오 : hdc=noprobe, hdc=none, hdd=...)