대량의 램에 대한 postgresql 조정


29

하드웨어 측면에서 두 개의 동일한 서버가 있으며 최소 소프트웨어가 설치된 Windows Server 2008 r2의 표준 설치입니다 (기본적으로 내 코드 및 jvm 등의 필수 항목).

한 서버에서 두 번째 서버 postgresql 9.1에서 SQL Server 2005를 실행 중입니다. 이 두 서버의 성능 차이는 놀랍습니다. postgresql에서 너무 나빠서 초기 "SQL 서버 라이센스를 지불하는 대신 postgresql을 사용하십시오"라는 연설을 상사에게 후회하고 있습니다. 우리는 동일한 명령에 대해 30 초와 15 분의 차이를 이야기하고 있으며, 이것은 하나의 명령이 아니라 내가 던지는 쿼리 또는 명령입니다. 둘 다 거의 동일한 데이터를 가지고 있으며 (레코드는 다른 순서로 삽입되었습니다) 두 데이터베이스는 모두 동일한 구조 / 인덱스 등을 가지고 있습니다.

그러나 성능 조정의 문제 일뿐입니다. 문제는 SQL 서버가 서버에서 32GB의 램을 거의 사용하고 있지만 postgresl은 실제로 세부 사항을 파악하지 못했지만 공연보다 작지 않습니다.

postgresql에서 20 기가 이상의 램을 사용하려면 어떻게해야합니까? 이 서버는이 데이터베이스 용으로 특별히 제작되었으므로 데이터베이스 및 지원 프로세스에서 사용하지 않는 램은 제 생각에 낭비됩니다.


4
초기 튜닝으로 변경 한 것이 있습니까? 1 단계 : SET effective_cache_size=18G;(기본 설정은 매우 낮음) BTW : 64 비트 시스템이라고 가정 (PTE 없음)

1
당신은 우리에게 많은 도움을 줄만큼 충분히주지 않습니다. "느리게"이외는 데이터 세트, 액세스 방법, 일반적으로 느리게 실행되는 쿼리 유형, 서버를 조정 (및 잘못 조정)하기 위해 수행 한 작업에 대해 잘 모릅니다. 코어와 메모리 채널이 많은 리눅스 머신에서는 postgresql을 설치하기 훨씬 전에 성능이 떨어질 수 있습니다. CPU 또는 IO에 바인딩되어 있습니까? 기본이 아닌 설정은 무엇입니까? 어떤 종류의 쿼리가 느립니까?
Scott Marlowe

2
Postgres는 사용자가 말하는 방식을 "램"으로 사용하지 않습니다. 그것은 대부분의 캐싱을 위해 OS 파일 시스템 페이지 캐시에 의존하므로 postgres를 실행하는 시스템에서 램 사용량을 볼 때 일반적으로 OS 버퍼 / 캐시에서 많은 GB를 사용하고 몇 가지를 사용하는 개별 postgres 백엔드 프로세스를 볼 수 있습니다 각각 수십 MB.
dbenhur

1
다음 링크를 참조하십시오 : tekadempiere.blogspot.ae/2014/09/… 그리고 여기에서 리소스 기반 conf 값을 찾으십시오 : pgtune.leopard.in.ua
Sajeev

관련 질문, 아마도 관심이 : stackoverflow.com/questions/47311485/…
mountainclimber

답변:


41

를 통해 초기화되는 많은 조정 가능한 상수가 있습니다 postgres.conf. 가장 중요한 것은 :

  • max_connections: 동시 세션 수
  • work_mem : 해시 테이블과 같은 중간 결과 및 정렬에 사용되는 최대 메모리 양
  • shared_buffers '고정 된'버퍼 공간 전용 메모리 양
  • effective_cache_size OS의 LRU 버퍼가 사용한다고 가정 한 메모리 양
  • random_page_cost : 디스크 탐색의 상대 비용에 대한 추정치입니다.

max_connections필요 이상으로 설정하면 안되며, 유휴 상태 일 때도 연결에 리소스가 필요합니다. 대부분의 경우 연결은 외부 대기보다 내부 대기 시간이 더 오래 걸립니다. (동시성 가격으로) 좋은 규칙은 "스핀들 수 + 프로세서 수 + X"입니다.

work_mem까다 롭습니다 :은 모든 하위 쿼리에 적용될 수 있으므로 5 인 쿼리는 HASHJOINS5 * 비용이들 수 있습니다 work_mem. 최악의 시나리오의 경우 여러 세션이이 양을 소비한다고 생각해야합니다 ( max_connections낮게 유지해야하는 이유로 ).

shared_buffers(IMHO) 과대 평가되었습니다. 일반적으로 사용 가능한 모든 "사용 가능한"메모리의 약 1/4 ... 1/2로 설정하는 것이 좋지만 메모리를 낮게 유지하고 effective_cache_size사용 가능한 모든 "사용 가능한"메모리로 설정 하는 것이 좋습니다.

random_page_cost디스크에서 찾기 + 읽기 비용입니다. 이 값 sequential_disk_cost은 1과 관련이 있습니다. 1은 random_page_cost최신 컴퓨터 및 네트워크 저장소에 대해 너무 높게 설정되어 있으며 일반적으로 2에서 1.x 사이로 낮출 수 있습니다. SSD 디스크는 SSD에서 거의 무료로 검색 할 수 있기 때문에 1.0으로 설정하기도합니다.


우수한! 나는 effective_cache_size의 중요성을 결코 보지 못했습니다. 항상 shared_buffers로만 바보입니다. 이것은 정말 큰 차이를 만들었습니다. 나는 pgtune도 실행하고 shard_buffers에는 20GB의 96을 권장하지만 effective_cache_size에는 64GB를 권장합니다. 감사!

1
FWIW, 나는 Postgres 문서에서 제안 된 이러한 설정과 다른 설정을 살펴보고 서버에 대한 분석을 수행했습니다 .
mlissner 2014

답변 주셔서 감사합니다. 기본값이 100이고 서버 RAM이 32GB (전용 postgres 서버) 인 work_mem경우 권장 사항을 물어볼 수 있습니까 max_connections? 매일 쿼리를 기반으로 직접 조정해야한다는 것을 알았습니다. "하나의 크기가 모든 답에 맞는"값 (또는 시작점 값)을 말해 줄 수 있는지 궁금합니다. 50MB가 너무 큽니까? 고마워
sgon00

시스템의 일반적인 동시 활동에 따라 다릅니다. 각각 50M (10..20M 이상)을 원하는 100 개의 세션 이 적합 할 수 있습니다. 또는 그렇지 않을 수도 있습니다. 인상을 얻으려면 vmstat 또는 top을 모니터링하십시오. 플러스 : 쿼리 및 기타에 따라 다릅니다. 계획을 봐
wildplasser

@wildplasser 빠른 답변 주셔서 감사합니다. 흥미로운 웹 사이트 pgtune.leopard.in.ua를 발견했습니다 . 나는 40MB를 그 제안에 근거하여 출발점으로 사용할 것이라고 생각합니다. 건배.
sgon00

20

PostgreSQL 구성 조정에 도움이 되도록 pgtune 사용을 고려하십시오 . PgFoundry에서 :

pgtune은 기본 postgresql.conf를 사용하여 데이터베이스 서버를 배포 할 하드웨어만큼 강력하게 확장합니다.

PostgreSQL의 기본 구성은 매우 보수적이며 해당 도구는 이러한 정확한 상황을 돕기위한 것입니다. 설명서는 약간만 읽었으며 도구 사용은 매우 간단합니다.

pgtune의 정확한 제안을 사용할 필요는 없습니다. 설정을 변경하고 conf 파일의 변경 사항을 관찰하면 PostgreSQL의 구성과 수동 조정 방법을 더 잘 이해할 수 있습니다.


8
pgtune의 마지막 업데이트는 2009 년에 5 년 전에 이루어졌으며 여전히 세고 있습니다. 9.1-9.2-9.3 시리즈에 여전히 유효한지 궁금합니다.
sorin


3

모든 쿼리 또는 명령이 느리게 실행되면 다음을 의심합니다.

  • 실행하는 모든 쿼리마다 데이터베이스에 연결합니다.
  • 어떤 종류의 인증 방법을 구성했는데 작동하지 않으며이 특정 인증 방법이 시간 초과 될 때까지 쿼리가 중지됩니다.

쿼리를 실행하는 데 시간이 얼마나 걸리는지 말씀해 주 select version()시겠습니까? 즉각적이어야합니다 (워크 스테이션에서 0,16ms).


2

모든 쿼리가 그보다 훨씬 느린 경우 서버 또는 무언가에 심각한 문제가 있습니다. 내 경험상 각 db는 다른 db보다 나은 것이 몇 가지 있지만 성능면에서 pgsql은 mssql 서버와 동일한 영역에 쉽게 있습니다.

그렇다면 어떤 OS에서 pgsql을 실행하고 있습니까? 어떤 하드웨어? 어떤 설정을 이미 변경 했습니까? 데이터 세트가 얼마나 큽니까? 잘못된 쿼리와 Explain analysis의 출력 예는 다음과 같습니다.

설명 select select ... rest of query here ...;

출력을 http://explain.depesz.com/ 에 게시하고 여기에 링크를 게시하십시오.


1
예, 모든 쿼리 / 명령이 느리게 실행되고 있습니다. 예 "뭔가"가 잘못되어서 제 질문입니다. 문제는 mssql이 서버에서 사용 가능한 램을 완전히 사용하고 있기 때문에 psql은 그렇지 않습니다. 의견과 조언을 주셔서 감사하지만, 당신은 내 질문과 제목 줄 자체를 놓쳤을 것입니다 ... psql이 사용 가능한 램을 사용하도록하는 방법을 알고 싶습니다. 현재 다른 사람들에 의해 제시된 몇 가지 제안을 시도 중 ...
user85116

1
RAM 사용은 문제가되지 않습니다. Postgresql은 대부분의 캐싱을 수행하기 위해 OS에 의존합니다. 따라서 모든 RAM을 사용할 필요는 없습니다. 다시 말하지만, 당신은 내 요점을 많이 놓쳤다. 당신을 돕기 위해 귀중한 작은 선물을드립니다. 나는 생활을 위해 5000 TPS postgresql 클러스터를 구동합니다. 내 충고를 받거나 pgsql이 어떻게 작동하고 논쟁하는지 알고 계속 생각할 수 있습니다.
Scott Marlowe

@ user85116, Scott의 의견을 들어주십시오. 이미 대기 시간에 의존하는 MySQL의 워크 플로가 있으므로 현재 MySQL은 64GB 램을 사용하여 신속하게 쿼리를 수행하는 반면, 2G Postgres에서도 실현 된 뷰를 통해 동일한 결과를 얻을 수 있습니다. 모든 데이터베이스를 RAM으로 캐싱해도 문제가 해결되지 않고 가시성이 떨어집니다. DB 구조에서 동일한 문제가 발생하면 Postgres는이를 해결하거나 숨기려고 시도하지 않습니다.
kworr
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.