PostgreSQL 서버는 내부-프로세스 통신(inter-process communication, IPC) - 구체적으로 공유 메모리와, 세마포어를 여러 프로세스가 함께 사용하는 것 - 을 제공하는 OS에서 실행된다. 유닉스 계열에서는 일반적으로 “System V” IPC, “POSIX” IPC 중 하나나, 둘 모두를 제공한다. Windows에서는 자체적인 방법으로 이 기능을 제공하며, 여기서는 언급하지 않는다.

PostgreSQL 서버는 아주 적은 System V 공유 메모리와, 서버에서 사용할 공용 메모리로 anonymous mmap 공유 메모리를 사용한다. 다른 방식으로, 하나의 큰 System V 공유 메모리 영역을 사용할 수도 있다(shared_memory_type 참조). 또한 OS 세마포어도 필요한데, 이 수량도 서버가 실행될 때 확보한다. 현재 리눅스나 FreeBSD 인 경우는 POSIX 세마포어를 사용하고, 나머지 OS에서는 System V 세마포어를 사용한다.

System V IPC를 사용하는 경우, 이들 자원(공유 메모리와 세마포어)은 OS 전역에서 공용으로 사용된다. PostgreSQL 서버를 실행 할 때, 필요한 만큼의 자원을 확보할 수 없다면, 서버 오류 메시지를 보이며 서버는 중지된다. ( 18.3.1절 참조). 이 OS 설정은 표 18.1 에서 대략적으로 설명한다. 하지만, 이들 설정은 OS 마다 서로 다르기 때문에, 사용하는 OS 설명서를 참조해야 한다. 몇몇 OS에 대해서는 아래에서 설명하고 있다.

PostgreSQL은 서버 인스턴스별로 System V 공유 메모리 수 바이트가 필요하다(64비트 플랫폼의 경우 보통 48바이트). 최신 운영 체제에서 이 정도 양은 손쉽게 할당 가능하다. 그러나, 서버 인스턴스를 다수 실행 중이거나 다른 어플리케이션도 System V 공유 메모리를 사용 중인 경우 (shared_memory_type 및 dynamic_shared_memory_type 참조) 시스템 차원(system-wide)의 System V 공유 메모리인 SHMALL를 늘려야 할 수 있다. SHMALL는 여러 시스템에서 바이트 단위가 아니라 페이지 단위로 처리된다는 점에 유의하라.

PostgreSQL의 경우 많아야 약 32바이트에 불과하기 때문에(대개 1) 문제의 원인이 공유 메모리 세그먼트의 최소 크기(SHMMIN)일 가능성은 낮다. 시스템 차원(system-wide)의 세그먼트 최대 수(SHMMNI) 또는 프로세스당 최대 수(SHMMNI) 또는 프로세스당 최대 수(SHMSEG)는 시스템이 영(0)으로 설정되지 않는 한 문제의 원인이 될 가능성은 낮다.

PostgreSQL은 16개 한 세트로, 허용된 연결(max_connections), autovacuum worker 프로세스(autovacuum_max_workers), 그리고 허용된 백그라운드 프로세스 (max_worker_processes) 각각 1개의 세마포어를 사용한다. 각각의 세트마다 다른 어플리케이션에서 사용되는 세마포어 세트와의 충돌을 감지하기 위한 “매직 넘버”가 17번째 세마포어에 포함되어 있다. 시스템에서 세마포어 최대 수는 SEMMNS에 의해 설정되며, 따라서 최소한 max_connections + autovacuum_max_workers + max_wal_senders + max_worker_processes 각각 허용된 16개 연결에 1 추가 + worker여야 한다(표 18.1 공식 참조). 파라미터 SEMMNI는 시스템에 동시에 존재할 수 있는 세마포어 세트 수에 대한 제한을 결정한다. 그러므로, 이 파라미터는 최소한 ceil((max_connections + autovacuum_max_workers + max_wal_senders + max_worker_processes + 5) / 16)여야 한다.허용 연결 수를 줄이면 실패를 임시 방편으로 해결할 수 있으며, semget 함수로부터 “No space left on device”라는 애매한 메시지를 받게 된다.

경우에 따라서는 SEMMAP를 적어도 SEMMNS와 유사하게 늘릴 필요가 있을 수 있다. 시스템에서 이 매개 변수가 있다면, (없을 수도 있다) 이 파라미터는 세마포어 리소스 맵의 크기를 정의하며, 이 맵에서는 사용 가능한 세마포어의 연속 블록마다 항목을 필요로 한다. 세마포어 세트가 해제되면, 해제된 블록에 인접한 기존 항목에 추가되거나 새로운 맵 항목 아래에 등록된다. 맵이 꽉 차면 해제된 세마포어는 분실된다(리부팅될 때까지). 세마포어 공간의 조각화는 시간이 흐를수록 원래 있어야 할 것보다 사용 가능한 세마포어 수가 작아진다.

SEMMNU 및 SEMUME 같은 “semaphore undo”와 관련된 다양한 기타 설정은 PostgreSQL에 영향을 미치지 않는다.

POSIX 세마포어를 쓰는 경우는 System V 경우와 같다. that is one semaphore per allowed connection (max_connections), allowed autovacuum worker process (autovacuum_max_workers) and allowed background process (max_worker_processes). On the platforms where this option is preferred, there is no specific kernel limit on the number of POSIX semaphores.

If systemd is in use, some care must be taken that IPC resources (including shared memory) are not prematurely removed by the operating system. This is especially of concern when installing PostgreSQL from source. Users of distribution packages of PostgreSQL are less likely to be affected, as the postgres user is then normally created as a system user.

The setting RemoveIPC in logind.conf controls whether IPC objects are removed when a user fully logs out. System users are exempt. This setting defaults to on in stock systemd, but some operating system distributions default it to off.

A typical observed effect when this setting is on is that shared memory objects used for parallel query execution are removed at apparently random times, leading to errors and warnings while attempting to open and remove them, like

WARNING:  could not remove shared memory segment "/PostgreSQL.1450751626": No such file or directory

Different types of IPC objects (shared memory vs. semaphores, System V vs. POSIX) are treated slightly differently by systemd, so one might observe that some IPC resources are not removed in the same way as others. But it is not advisable to rely on these subtle differences.

A “user logging out” might happen as part of a maintenance job or manually when an administrator logs in as the postgres user or something similar, so it is hard to prevent in general.

What is a “system user” is determined at systemd compile time from the SYS_UID_MAX setting in /etc/login.defs.

Packaging and deployment scripts should be careful to create the postgres user as a system user by using useradd -r, adduser --system, or equivalent.

Alternatively, if the user account was created incorrectly or cannot be changed, it is recommended to set

RemoveIPC=no

in /etc/systemd/logind.conf or another appropriate configuration file.

Unix계열의 운영 체제는 사용자의 PostgreSQL 서버에도 영향을 미칠 수 있는 리소스 제한 형태가 다양하다. 그 중에 사용자별 프로세스 수, 프로세스당 개방 파일 수, 각 프로세스에서 사용 가능한 메모리 양에 대한 제한이 특히 중요하다. 이러한 제한은 각각 “하드” 및 “소프트” 제한이 있다. 소프트 제한은 실제로 계산하는 것이지만, 사용자가 하드 제한까지 증가 시킬 수 있다. 하드 제한은 root 사용자만이 변경 가능하다.시스템 호출 setrlimit는 이러한 파라미터의 설정을 담당한다. 쉘의 빌트인 명령어 ulimit(Bourne 쉘) 또는 limit (csh)는 커맨드 라인에서 리소스 제한을 제어하는 데 사용된다. BSD 파생 시스템에서/etc/login.conf 파일은 로그인 동안 다양한 리소스 제한 설정을 제어한다. 자세한 내용은 운영 체제 문서를 참조 바란다. 관련 파라미터는 maxproc, openfiles 및 datasize들이 있다.예제는 아래와 같다.

default:\
...
:datasize-cur=256M:\
:maxproc-cur=256:\
:openfiles-cur=256:\
...

(-cur는 소프트 제한이다.하드 제한을 설정하려면 -max를 덧붙인다.)

커널은 일부 리소스에 대해 시스템 차원(system-wide)의 제한을 가질 수 있다.

PostgreSQL 서버는 연결당 프로세스 1개를 사용하므로 허용된 연결 수에 해당되는 프로세스는 최소한 제공한 다음에 사용자는 시스템에서 필요로 하는 나머지를 제공해야 한다. 이것은 일반적으로 문제가 되지 않지만 머신 1대에 몇 개의 서버를 실행하는 경우에는 쉽지 않을 수 있다.

개방 파일에 대한 기본 제한은 시스템 리소스를 부적절하게 분할하지 않고도 여러 사용자가 머신에 공존할 수 있는 값인 “사회적으로 용인되는” 값으로 설정된다. 사용자가 필요에 따라 머신 1대에서 여러 개의 서버를 실행하지만, 특정한 전용 서버의 제한만 올리고자 할 수도 있다.

다른 한편으로, 일부 시스템에서는 독립된 프로세스들이 많은 수의 파일들을 열 수 있게 한다.그러면 몇 개의 프로세스만 실행되더라도 시스템 차원(system-wide)의 제한이 손쉽게 초과된다. 이러한 상황이 발생되었지만 시스템 차원(system-wide)의 제한을 변경하고 싶지 않을 경우에는 PostgreSQL의 max_files_per_process 환경 설정 파라미터를 설정하여 개방 파일의 소비를 제한할 수 있다.

Linux 기본 가상 메모리 동작은 PostgreSQL의 경우 최적화 되어 있지 않다. 커널이 메모리 오버커밋을 이행하는 방식 때문에 PostgreSQL 또는 다른 프로세스의 사용 메모리가 시스템의 가상 메모리 소진의 원인이 되는 경우 커널은 PostgreSQL postmaster(서버 최상위 프로세스)를 강제 중시 시킬 것이다.

이런 경우가 발생하면 다음 같은 커널 메시지가 나타난다(해당 메시지를 찾아 보려면 시스템 문서 및 환경 설정 참조).

Out of Memory: Killed process 12345 (postgres).

이것은 postgres 프로세스가 메모리 압박 때문에 종료되었음을 나타낸다. 기존 데이터베이스 연결이 정상 작동되더라도 새로운 연결은 수락되지 않는다. 복구하려면 PostgreSQL을 재시작해야 한다.

이 문제를 방지하는 방법 중 하나는 다른 프로세스 때문에 머신의 메모리가 소진되지 않을 것이 확실한 머신에서 PostgreSQL을 실행하는 것이다. 실제 메모리와 swap 공간이 소진된 경우에만 메모리 부족(OOM) 킬러가 호출되기 때문에 메모리에 여유가 없는 경우에는 운영 체제의 swap 공간을 늘리면 문제를 방지하는 데 도움이 된다.

PostgreSQL 자체가 메모리 부족의 원인인 경우 환경 설정을 변경하면 문제를 방지할 수 있다. 경우에 따라 메모리 관련 환경 설정 파라미터, 특히 shared_buffers, work_mem, hash_mem_multiplier 설정값을 줄이는 것이 도움이 된다. 그 외에는 데이터베이스 서버 자체로의 연결을 너무 많이 허용하는 것이 문제의 원인일 수 있다. 대체로, max_connections를 줄이는 대신 외부 연결 풀링 소프트웨어를 이용하는 것이 좋다.

커널 환경 설정 매개 변수를 수정해서 메모리 “오버커밋”을 방지할 수 있다. 이 설정으로 OOM killer의 호출이 전적으로 방지되는 않지만 가능성은 확연히 줄어들며, 따라서 시스템 동작이 좀 더 견고해진다. sysctl을 통해 엄격한 오버커밋 모드를 선택함으로써 이것이 가능해진다.

sysctl -w vm.overcommit_memory=2

또는 동일한 항목을 /etc/sysctl.conf에 입력해도 된다. 사용자는 이와 관련된 설정인 vm.overcommit_ratio의 수정을 원할 수도 있다. 자세한 내용은 커널 문서 파일 https://www.kernel.org/doc/Documentation/vm/overcommit-accounting 을 참조 바란다.

Another approach, which can be used with or without altering vm.overcommit_memory, is to set the process-specific OOM score adjustment value for the postmaster process to -1000, thereby guaranteeing it will not be targeted by the OOM killer. The simplest way to do this is to execute

echo -1000 > /proc/self/oom_score_adj

in the postmaster's startup script just before invoking the postmaster. Note that this action must be done as root, or it will have no effect; so a root-owned startup script is the easiest place to do it. If you do this, you should also set these environment variables in the startup script before invoking the postmaster:

export PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
export PG_OOM_ADJUST_VALUE=0

These settings will cause postmaster child processes to run with the normal OOM score adjustment of zero, so that the OOM killer can still target them at need. You could use some other value for PG_OOM_ADJUST_VALUE if you want the child processes to run with some other OOM score adjustment. (PG_OOM_ADJUST_VALUE can also be omitted, in which case it defaults to zero.) If you do not set PG_OOM_ADJUST_FILE, the child processes will run with the same OOM score adjustment as the postmaster, which is unwise since the whole point is to ensure that the postmaster has a preferential setting.

huge pages를 사용하면 PostgreSQL 같이 shared_buffers 값이 크게 지정해 많은 메모리를 사용할 경우, 한번에 큰 메모리 영역을 작업 단위로 지정해, 메모리 읽기 쓰기 작업 비용을 줄일 수 있다. PostgreSQL에서 이 기능을 활성화하려면 커널 환경 설정값이 CONFIG_HUGETLB_PAGE=y 및 CONFIG_HUGETLBFS=y로 되어있어야 한다. 또한 vm.nr_hugepages 값도 적당히 조절되어야 한다. 필요한 huge page 수를 계산하는 방법은, huge page 설정을 끄고, PostgreSQL 서버를 실행한 뒤, /proc 파일 시스템을 이용하며 postmaster 프로세스의 익명 공유 메모리 크기 값을 보고, 그 값 정도를 huge page 크기로 산정하면 된다. 이 작업은 다음과 같다:

$ head -1 $PGDATA/postmaster.pid
4170
$ pmap 4170 | awk '/rw-s/ && /zero/ {print $2}'
6490428K
$ grep ^Hugepagesize /proc/meminfo
Hugepagesize:       2048 kB

6490428 / 2048는 대략 3169.154 huge pages이므로 최소 3170 huge pages가 필요해서, 다음과 같이 지정한다:

$ sysctl -w vm.nr_hugepages=3170

이 설정값은 다른 응용 프로그램에서도 huge page를 사용하다면, 이 보다 더 크게 잡을 필요도 있다. 리부팅 시에 이 설정을 유지하려면 /etc/sysctl.conf에 항목을 추가하는 것을 잊으면 안 된다.

가끔 커널이 원하는 만큼의 huge page 설정을 즉시 하지 못해 윗 명령을 여러번 해야할 경우도 있으며, 리부팅을 해야하는 경우도 있다. (리부팅 다음 즉시, 머신 메모리의 대부분은 huge page로 변환할 수 있기 때문에, 리부팅을 시도한다.) 시스템의 huge page 할당량은 다음 명령으로 확인한다:

$ grep Huge /proc/meminfo

이런 작업은 sysctl 명령으로 알 수 있는 vm.hugetlb_shm_group 설정값에 의한 huge page 설정 변경 권한을 가진 데이터베이스 서버가 운영되고 있는 운영체제 사용자가 필요하며, ulimit -l 명령으로 확인 하는 잠금 메모리 설정을 할 수 있는 사용자여야 한다.

PostgreSQL에서 huge pages의 기본 동작은 가능할 경우 사용하는 것이고 실패할 경우 일반 메모리 관리 방식으로 진행 된다. huge_pages를 on으로 설정하면 huge pages를 강제로 사용할 수 있다. 이 경우 사용 가능한 huge pages가 부족하면 PostgreSQL 서버가 실행되지 않는다.

Linux huge pages 기능에 대한 자세한 설명은 https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt 페이지를 읽어 보기 바란다.