PostgreSQL pg_stat_activity는 COMMIT를 보여줍니다

우리는 최근 데이터베이스 서버를 4 개의 쿼드 코어 CPU와 32Gb의 램으로 업그레이드 된 머신으로 교체했습니다. 또한 스트리밍 복제의 슬레이브 역할을하기 위해 기존 박스를 용도 변경했습니다. 두 상자 모두 CentOS 6.3 및 PostgreSQL 9.2를 실행하고 있습니다. 각 상자에서 실행되는 것은 Postgres뿐입니다.

이 구성은 트래픽이 증가하기 시작하면서 갑자기 몇 가지 문제가 발생하기 시작한 지 약 한 달 정도되었습니다. 우리가보기 시작한 것은 때때로 매우 높은 CPU로드 (맨 위의로드 평균 270)이며, 볼 수있을 때 pg_stat_activity대부분의 연결이 COMMIT상태에 있음을 알 수 있습니다. 혼자두면 결국이 작업이 완료되고 시스템은 연결 상태에 응답합니다 IDLE. 복제를 비활성화하여 이것이 문제가 될 수 있는지 확인했지만 문제가 계속 발생합니다.

우리는 무슨 일이 일어나고 있는지 진단하려고 노력했지만 조금 잃어 버렸습니다. 달리기의 결과는 perf아래와 비슷한 것을 보여 주며, 나는 무엇을 0x347ba9나타내는 지 전혀 모른다 .

+  41.40%       48154  postmaster  0x347ba9         f 0x347ba9                                   ◆
+   9.55%       10956  postmaster  0x2dc820         f set_config_option                          ▒
+   8.64%        9946  postmaster  0x5a3d4          f writeListPage     
+   5.75%        6609  postmaster  0x5a2b0          f ginHeapTupleFastCollect                    ▒
+   2.68%        3084  postmaster  0x192483         f build_implied_join_equality                ▒
+   2.61%        2990  postmaster  0x187a55         f build_paths_for_OR                         ▒
+   1.86%        2131  postmaster  0x794aa          f get_collation_oid                          ▒
+   1.56%        1822  postmaster  0x5a67e          f ginHeapTupleFastInsert                     ▒
+   1.53%        1766  postmaster  0x1929bc         f distribute_qual_to_rels                    ▒
+   1.33%        1558  postmaster  0x249671         f cmp_numerics

앱에서 수행 한 쿼리 중 어느 것도 특히 복잡하지 않으며 설명 계획은 최대 1 초가 걸립니다 (대부분 훨씬 빠름). 또한 트래픽이 발생하기 시작할 때 이런 일이 발생하지만 트래픽로드가 크지 않습니다 (오래된 컴퓨터는 트래픽을 쉽게 처리 할 수있었습니다).

이 시점에서 나는 다음에 무엇을 시도해야할지에 대해 약간 혼란스러워했다. 도움이나 제안이 있으면 감사하겠습니다. 도움이 될만한 추가 정보가 있으면 물어 보면 질문을 수정할 수 있습니다.

디스크 구성 :

퍼크 6i RAID 컨트롤러
146GB 15K SAS 드라이브 5 개
WAL의 경우 2x146GB RAID-1 및 시스템 및 데이터의 경우 3x146GB RAID-5로 구성

최신 정보:

아래는 시스템이 정상적으로 작동하고 CPU가 작동 할 때 발생하는 VMStat 출력입니다. 문제가 발생하면 인터럽트가 급증하는 것 같습니다.

정상 작동 중 :

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 18938590 303763 21947154    0    0    28    52 7466 12649  2  1 97  0  0   2013-01-14 16:03:25 EST
 0  0      0 18938396 303763 21947154    0    0     0    19 7107 12679  2  0 98  0  0   2013-01-14 16:03:35 EST
 1  0      0 18938904 303763 21947162    0    0     0    54 7042 12708  1  1 99  0  0   2013-01-14 16:03:45 EST
 1  0      0 18938520 303763 21947260    0    0    33    66 7120 12738  1  1 99  0  0   2013-01-14 16:03:55 EST

CPU 사용량이 많은 경우 :

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
343 0      0 32680468 226279 11339612    0    0     0   214 26692 12225 80  20  0  0  0   2013-01-11 16:45:53 EST
374 1      0 32673764 226291 11340345    0    0     0    77 54893 11572 80  20  0  0  0   2013-01-11 16:46:03 EST
383 0      0 32616620 226304 11340956    0    0     0   102 55540 12922 82  18  0  0  0   2013-01-11 16:46:13 EST
315 0      0 32602038 226320 11341378    0    0     0    79 54539 12441 82  18  0  0  0   2013-01-11 16:46:23 EST

postgresql

— ern 른
소스

새 상자에는 어떤 종류의 디스크가 있습니까? 두 노드 모두에서 발생합니까 아니면 둘 중 하나에서만 발생합니까?

— Trygve Laugstøl

@trygvis-디스크 사양으로 질문을 업데이트했습니다. 마스터 노드에서 문제가 발생하고 있습니다. 나는 슬레이브를 홍보하려고 시도하지 않았고 트래픽을 직접 보내려고했기 때문에 같은 상황에서도 문제가 있는지 확실하지 않습니다. 슬레이브로서 머신에는 문제가없는 것 같습니다.

— jcern

perf시스템 전체 프로파일 링 및 일부 PostgreSQL 프로파일 링을 수행 하기 위해이 도구를 사용해보십시오 . CPU 사용량이 발생하는 곳을 참조하십시오. BTW, 두 번째 형식 vmstat이 절망적으로 어긋나고 첫 번째 열이 잘못 정렬되어 읽기가 어렵습니다. commit_delay개선 사항을 추가해도 문제가 없는지 테스트하십시오 . RAID 컨트롤러에 배터리 백업 라이트 백 캐시가 있는지 확인하고 그렇지 않은 경우 캐시를 받으십시오. 많은 시간이 소비 iowait됩니까? 이 나타납니다 일부보고에서 CPU 사용을 할 것이 아니라, 정말 아니다.

— Craig Ringer

@CraigRinger 컨트롤러에는 배터리 지원 쓰기 캐시가 있으며 현재 활성화되어 있습니다. iostat에서 기다리려면 한 자리에서 두 자리 숫자까지 유지하십시오. 우리는 perf로 계속해서 프로파일 링을 시도 할 것입니다. 또한 두 번째 VMStat의 형식을 수정했습니다. 지적 해 주셔서 감사합니다.

— jcern

추가 진단 및 일부 인터넷 검색 후, 우리는 이 기사 에서 우리가 겪었던 것과 동일한 증상을 많이 설명했습니다. 문제의 근본 원인 (그리고 우리가 알 수있는 것)도 Transparent Huge Pages구현 과 관련이있었습니다 .

Transparent Huge Pages이 명령으로 비활성화 한 후 :

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

문제가 해결 된 것으로 보입니다. 지난 2 주 동안 증가 된 워크로드 하에서 실행되었으며 문제가 재 포장되지 않았습니다. 시스템의 컨텍스트와 인터럽트는 기존의 1/10 수준이며 평균 시스템 시간도 줄었습니다.

그것이 모든 사람을위한 해결책인지 확실하지 않지만 다른 사람이 비슷한 문제를 해결할 수 있도록 여기에 가능한 원인으로 게시합니다.

— ern 른
소스