PostgreSQL은 공유 메모리에 대해 불평하지만 공유 메모리는 괜찮은 것 같습니다.


13

PostgreSQL 서버에서 일종의 집중적 인 스키마 삭제 및 생성을 수행했지만 이제는 불평합니다 .. :

WARNING:  out of shared memory
ERROR:  out of shared memory
HINT:  You might need to increase max_locks_per_transaction.

그러나 PostgreSQL을 방금 다시 시작하면 문제가 남아 있습니다 service postgresql restart.max_locks_per_transaction이 아무것도 조정하지 않을 것으로 생각합니다.

이 오류에 대한 문제 해결 목록이 작동하지 않기 때문에 조금 이상합니다.

추가 정보 1409291350 : 일부 세부 정보가 누락되었지만 핵심 SQL 결과를 유지합니다.

postgres=# SELECT version();
PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2,
 64-bit

과:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.1 LTS
Release:        14.04
Codename:       trusty

2
에서 PostgreSQL 버전은 SELECT version()? 흥미로운 문제 ...
Craig Ringer

2
"max_locks_per_transaction이 아무 것도 조정하지 않을 것으로 생각합니다." -어, 왜 그렇게 생각하십니까? 힌트의 제안을 실제로 따르려고 했습니까?
Josh Kupershmidt

힌트의 제안을 실제로 따르려고 했습니까? max_locks_per_transaction = 64 # min 10지금까지 /etc/postgresql/9.3/main/postgresql.conf에서 주석 처리를 제거 했습니다.
48347

1
기본 max_locks_per_transaction은 64로 시작합니다. 주석 처리를 해제해도 효과적으로 변경되지 않았습니다.
yieldsfalsehood

1
128으로 효과적으로 증가 하면 문제가 해결되어 실제로 작업을 계속할 수있었습니다.
48347

답변:


11

집중적 인 삭제 및 작성에 대한 의견과 max_locks_per_transaction 증가에 대한 알림 은 동일한 트랜잭션에서 많은 오브젝트 삭제 및 작성하고 있음을 암시 합니다 . 이들 각각은 잠금을 발생 시키며, 각 잠금에는 소량의 공유 메모리가 필요합니다. 이로 인해 max_locks_per_transaction은 트랜잭션 내에서 보유 할 수있는 잠금 수를 제한합니다 (한 트랜잭션이 모든 공유 메모리를 사용하지 못하도록).

당신은 그 한계를 조금 늘리거나 (임의로 설정하지 않는 것이 좋습니다. 또는 실제로 총 공유 메모리가 부족한 별도의 상황에 처할 것입니다) 드롭을 수행하고 트랜잭션을 일괄 처리하거나 한 방울로 만듭니다 트랜잭션 당 / create

편집 : 분명히 max_locks_per_transaction의 작동 방식이 잘못되었습니다. 문서에서 사용 가능한 총 잠금 수는 max_locks_per_transaction * (max_connections + max_prepared_transactions)입니다. 모든 곳에서 보유 된 잠금 수가이 총값보다 작은 한 트랜잭션은 max_locks_per_transaction 이상을 보유 할 수 있습니다.


내 워크 플로에는 (1) 스키마 X 덤프, (2) 다른 스키마 Y 삭제 및 (3) 스키마 이름 Y에서 X 복원이 포함되어 있습니다. 오늘까지, 저는이 활동을 수행하는 데 몇 주가 넘었습니다. 단계 (2)가 실패합니다. 단계 (2)는 주로으로 구성되며 DROP SCHEMA IF EXISTS public CASCADE; CREATE SCHEMA public, 경고, 오류 및 힌트를 던지는 문장입니다.
48347

최대 잠금을 64에서 128로 두 배로 늘리면 워크 플로를 계속할 수있었습니다. 나는 아직 모든 내부 요소를 얻지 못했지만 DROP SCHEMA와 CREATE SCHEMA 문장 사이의 커밋은 비슷한 완화 효과를 줄 것이라고 생각합니다.
48347

지금은 내가 작은 스키마 증가를 얻을 수 많은 일을 실현하고,이 문제는 완벽 그 중 하나와 일치하는 작은 스키마 증가 . 일반적인 전략으로 지금부터 HINT를 더 많이 고려할 것입니다.
48347
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.