많은 메모리를 차지하고있는 idle postgres 프로세스

Question

나는 정상적인 사용 후에 ~ 30 idle postgres 프로세스가 많은 프로세스 특정 메모리를 차지하는 이유를 알아 내려고하고 있습니다. Postgres 9.3.1 및 CentOS 릴리스 6.3 (최종)을 사용하고 있습니다. top를 사용 , 나는 비 공유 (RES - SHR)의 (평균 ~ 2백메가바이트) 300메가바이트까지 사용하는 포스트 그레스 연결의 많은 볼 수있는 메모리 :

PID USER  PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
3534 postgres 20 0 2330m 1.4g 1.1g S 0.0 20.4 1:06.99 postgres: deploy mtalcott 10.222.154.172(53495) idle 
9143 postgres 20 0 2221m 1.1g 983m S 0.0 16.9 0:14.75 postgres: deploy mtalcott 10.222.154.167(35811) idle 
6026 postgres 20 0 2341m 1.1g 864m S 0.0 16.4 0:46.56 postgres: deploy mtalcott 10.222.154.167(37110) idle 
18538 postgres 20 0 2327m 1.1g 865m S 0.0 16.1 2:06.59 postgres: deploy mtalcott 10.222.154.172(47796) idle 
1575 postgres 20 0 2358m 1.1g 858m S 0.0 15.9 1:41.76 postgres: deploy mtalcott 10.222.154.172(52560) idle 

을 약 29 총 유휴 연결이 있습니다. 이러한 유휴 연결은 머신이 스왑을 사용하기 시작할 때까지 메모리에서 계속 증가하고 성능은 멈 춥니 다. 예상대로 연결을 다시 설정하면 프로세스 관련 메모리가 지워집니다. 동일한 시스템에서 같은 수의 연결은 정기적으로 다시 연결할 때 메모리의 20 % 만 사용합니다 (스왑 공간이 0 인 경우). 이 프로세스들은 어떤 종류의 정보를 보유하고 있습니까? 장기간 유휴 상태의 포스트그레스 프로세스가 새로운 유휴 상태의 메모리와 비슷한 메모리 사용량을 가질 것으로 기대합니다.

주목할 가치 : 저는 스키마를 많이 사용하고 있습니다. 내 앱에 대한 모든 요청에서 search_path를 설정하고 다시 설정합니다.

Answer 1

이러한 프로세스는 어떤 종류의 정보를 보유하고 있습니까? 장기간 유휴 상태의 포스트그레스 프로세스가 새로운 유휴 상태의 메모리와 비슷한 메모리 사용량을 가질 것으로 기대합니다.

• relcache (관련 기술자)
• catcache (시스템 카탈로그 항목)
• 컴파일 :

는 그들을로드 된 후에 포스트 그레스가 로컬 메모리에 캐시 것을 실제로 꽤 몇 가지가 있습니다 plpgsql 기능을위한 트리

대부분의 사용 사례는이 모든 것이 합쳐져 무시할 정도입니다. 여기서 핵심은 스키마의 과도한 사용과 relcache에 대한 영향이었습니다. 이 데이터베이스에는 ~ 90 개의 테이블이있는 ~ 500 개의 스키마가 있습니다. Postgres에 스키마가 모두 같더라도이 테이블은 45,000 개의 테이블 (500 * 90)으로 작동합니다.

각 요청은 메모리에있는 테이블의 관계 설명자 (대부분 이전에 요청한 스키마와 다른 스키마)를 캐시하여 점차적으로 relcache를 채 웁니다. 불행히도, 오버 헤드가 아마 대부분의 유스 케이스에 비생산적이기 때문에 Postgres does not offer a way to limit the size of these caches입니다.

가능한 해결책 :

• 다시 연결 요청의 특정 숫자 후
• 는 pgpool-II 또는 PgBouncer

를 사용하여 포스트 그레스 연결 수에 천장을 넣어 더 많은 메모리를

연결 풀링 추가

Postgres mailing lists 이상의 도움으로 Tom Lane 및 Merlin Moncure에게 감사드립니다.