PostgreSQL운영 체제가 프로세스 간 통신을 제공해야 합니다(IPC) 기능, 특히 공유 메모리 및 세마포어. Unix 파생 시스템은 일반적으로 다음을 제공합니다.“시스템 V” IPC, “POSIX” IPC또는 둘 다.윈도우이러한 기능에 대한 자체 구현이 있으므로 여기서는 논의하지 않습니다.

기본적으로,PostgreSQL아주 적은 양의 System V 공유 메모리와 훨씬 더 많은 양의 익명 메모리를 할당합니다.mmap공유 메모리. 또는 단일 대형 System V 공유 메모리 영역을 사용할 수 있습니다(참조shared_memory_type). 또한 System V 또는 POSIX 스타일일 수 있는 상당수의 세마포어가 서버 시작 시 생성됩니다. 현재 POSIX 세마포어는 Linux 및 FreeBSD 시스템에서 사용되는 반면 다른 플랫폼에서는 System V 세마포어를 사용합니다.

시스템 VIPC기능은 일반적으로 시스템 전체 할당 제한에 의해 제한됩니다. 언제포스트그레SQL이 제한 중 하나를 초과하면 서버는 시작을 거부하고 문제와 이에 대해 수행할 작업을 설명하는 오류 메시지를 남겨야 합니다. (또한 참조섹션 18.3.1.) 관련 스포츠 토토 매개변수의 이름은 여러 시스템에서 일관되게 지정됩니다.표 18.1개요를 제공합니다. 그러나 설정 방법은 다양합니다. 일부 플랫폼에 대한 제안 사항은 아래와 같습니다.

PostgreSQL서버의 각 복사본에 대해 몇 바이트의 System V 공유 메모리(일반적으로 64비트 플랫폼의 경우 48바이트)가 필요합니다. 대부분의 최신 운영 체제에서는 이 양을 쉽게 할당할 수 있습니다. 그러나 서버의 여러 복사본을 실행 중이거나 많은 양의 System V 공유 메모리를 사용하도록 서버를 명시적으로 구성한 경우(참조shared_memory_type그리고dynamic_shared_memory_type), 증가가 필요할 수 있습니다.SHMALL은 시스템 전체의 System V 공유 메모리의 총량입니다. 참고하세요SHMALL많은 시스템에서 바이트가 아닌 페이지 단위로 측정됩니다.

공유 메모리 세그먼트의 최소 크기는 문제를 일으킬 가능성이 적습니다. (SHMMIN)(의 경우 최대 약 32바이트여야 함)PostgreSQL(보통 1입니다). 시스템 전체의 최대 세그먼트 수(SHMMNI) 또는 프로세스별(SHMSEG) 시스템에서 이를 0으로 설정하지 않는 한 문제가 발생할 가능성이 없습니다.

System V 세마포어를 사용할 때,PostgreSQL허용된 연결당 하나의 세마포어를 사용합니다(max_connections), 자동 진공 작업자 프로세스 허용(autovacuum_worker_slots), 허용된 WAL 발신자 프로세스(max_wal_senders), 백그라운드 프로세스 허용(max_worker_processes) 등 16개 세트. 런타임 계산 매개변수num_os_semaphores필요한 세마포어 수를 보고합니다. 이 매개변수는 a로 서버를 시작하기 전에 볼 수 있습니다.포스트그레스다음과 같은 명령:

$ postgres -D $PGDATA -C num_os_semaphores

16개의 세마포어 세트 각각에는 다음을 포함하는 17번째 세마포어도 포함됩니다.“매직넘버”, 다른 애플리케이션에서 사용하는 세마포어 세트와의 충돌을 감지합니다. 시스템의 최대 세마포어 수는 다음과 같이 설정됩니다.SEMMNS, 결과적으로 최소한만큼 높아야 합니다.num_os_semaphores16개의 필수 세마포어 세트당 하나의 추가(다음 공식 참조표 18.1). 매개변수SEMMNI시스템에 동시에 존재할 수 있는 세마포어 세트 수에 대한 제한을 결정합니다. 따라서 이 매개변수는 최소한ceil(num_os_semaphores / 16). 허용되는 연결 수를 낮추는 것은 일반적으로 혼란스럽게 표현되는 오류에 대한 임시 해결 방법입니다.“기기에 남은 공간이 없습니다.”, 함수에서semget.

어떤 경우에는 증가가 필요할 수도 있습니다SEMMAP적어도 다음 순서대로SEMMNS. 시스템에 이 매개변수가 있는 경우(많은 경우 그렇지 않음) 사용 가능한 세마포의 각 연속 블록에 항목이 필요한 세마포 리소스 맵의 크기를 정의합니다. 세마포어 세트가 해제되면 해제된 블록에 인접한 기존 항목에 추가되거나 새 맵 항목 아래에 등록됩니다. 맵이 꽉 차면 해제된 세마포어가 손실됩니다(재부팅할 때까지). 시간이 지남에 따라 세마포어 공간이 조각화되면 사용 가능한 세마포어가 있어야 할 것보다 적어질 수 있습니다.

기타 관련 설정“세마포 실행 취소”, 예를 들어SEMMNU그리고SEMUME, 영향을 주지 않습니다포스트그레SQL.

POSIX 세마포어를 사용할 때 필요한 세마포어 수는 System V와 동일합니다. 즉, 허용된 연결당 하나의 세마포어입니다. (max_connections), Autovacuum 작업자 프로세스 허용(autovacuum_worker_slots), 허용된 WAL 발신자 프로세스(max_wal_senders), 백그라운드 프로세스 허용(max_worker_processes) 등. 이 옵션이 선호되는 플랫폼에서는 POSIX 세마포어 수에 대한 특정 커널 제한이 없습니다.

만약시스템이 사용 중이면 운영 체제에서 IPC 리소스(공유 메모리 포함)를 조기에 제거하지 않도록 주의해야 합니다. 이는 소스에서 PostgreSQL을 설치할 때 특히 중요합니다. PostgreSQL 배포 패키지 사용자는 영향을 받을 가능성이 적습니다.포스트그레사용자는 일반적으로 시스템 사용자로 생성됩니다.

설정IPC 제거에logind.conf사용자가 완전히 로그아웃할 때 IPC 객체가 제거되는지 여부를 제어합니다. 시스템 사용자는 면제됩니다. 재고가 있는 경우 이 설정은 기본적으로 켜져 있습니다.시스템, 그러나 일부 운영 체제 배포판에서는 기본적으로 꺼져 있습니다.

이 설정이 켜져 있을 때 일반적으로 관찰되는 효과는 병렬 쿼리 실행에 사용되는 공유 메모리 개체가 임의의 시간에 제거되어 이를 열고 제거하려고 시도하는 동안 오류와 경고가 발생한다는 것입니다.

경고: 공유 메모리 세그먼트 "/PostgreSQL.1450751626"을 제거할 수 없습니다: 해당 파일이나 디렉터리가 없습니다

다양한 유형의 IPC 객체(공유 메모리 대 세마포어, 시스템 V 대 POSIX)는 다음과 같이 약간 다르게 처리됩니다.시스템화, 따라서 일부 IPC 리소스가 다른 리소스와 동일한 방식으로 제거되지 않는 것을 볼 수 있습니다. 그러나 이러한 미묘한 차이에 의존하는 것은 바람직하지 않습니다.

A “사용자 로그아웃”유지 관리 작업의 일부로 또는 관리자가 다음 계정으로 로그인할 때 수동으로 발생할 수 있습니다.포스트그레사용자 또는 이와 유사한 사용자이므로 일반적으로 예방하기 어렵습니다.

a이란 무엇입니까“시스템 사용자”다음에 결정됨시스템화컴파일 시간SYS_UID_MAX설정/etc/login.defs.

패키징 및 배포 스크립트는 다음을 생성할 때 주의해야 합니다.포스트그레스다음을 사용하여 시스템 사용자로 사용자useradd -r, adduser --system또는 이에 상응하는 것.

또는 사용자 계정이 잘못 생성되었거나 변경할 수 없는 경우 설정하는 것이 좋습니다

IPC 제거=아니요

in/etc/systemd/logind.conf또는 다른 적절한 구성 파일.

Unix 계열 운영 체제는 귀하의 작업을 방해할 수 있는 다양한 종류의 스포츠 토토 제한을 시행합니다.PostgreSQL서버. 특히 중요한 것은 사용자당 프로세스 수, 프로세스당 열려 있는 파일 수, 각 프로세스에서 사용할 수 있는 메모리 양에 대한 제한입니다. 이들 각각에는“하드”그리고“소프트”한계. 소프트 제한은 실제로 중요한 것이지만 사용자가 하드 제한까지 변경할 수 있습니다. 하드 제한은 루트 사용자만 변경할 수 있습니다. 시스템 호출setrlimit이 매개변수 설정을 담당합니다. 셸의 내장 명령ulimit(본 쉘) 또는한계 (csh)는 명령줄에서 리소스 제한을 제어하는 데 사용됩니다. BSD 파생 시스템에서는 파일/etc/login.conf로그인 중에 설정된 다양한 자원 제한을 제어합니다. 자세한 내용은 운영 체제 설명서를 참조하세요. 관련 매개변수는 다음과 같습니다.maxproc, 열린 파일및데이터 크기. 예를 들면:

기본값:\
...
        :datasize-cur=256M:\
        :maxproc-cur=256:\
        :openfiles-cur=256:\
...

(-현재소프트 한계입니다. 추가-최대하드 제한을 설정합니다.)

커널은 일부 리소스에 대해 시스템 전체에 대한 제한을 가질 수도 있습니다.

그PostgreSQL서버는 연결당 하나의 프로세스를 사용하므로 시스템의 나머지 부분에 필요한 것 외에도 최소한 허용된 연결 수만큼의 프로세스를 제공해야 합니다. 이는 일반적으로 문제가 되지 않지만 한 시스템에서 여러 서버를 실행하는 경우 문제가 발생할 수 있습니다.

열린 파일에 대한 공장 기본 제한은 종종 다음과 같이 설정됩니다.“사회적 친화적인”시스템 리소스의 부적절한 부분을 사용하지 않고도 많은 사용자가 시스템에서 공존할 수 있게 해주는 값입니다. 한 머신에서 많은 서버를 실행하는 경우 이것이 아마도 원하는 것일 수 있지만 전용 서버에서는 이 제한을 높이고 싶을 수도 있습니다.

반전적으로, 일부 시스템에서는 개별 프로세스가 많은 수의 파일을 열 수 있도록 허용합니다. 프로세스 수가 너무 많으면 시스템 전체 제한이 쉽게 초과될 수 있습니다. 이런 일이 발생하고 시스템 전체 제한을 변경하고 싶지 않은 경우 다음을 설정할 수 있습니다.PostgreSQL'smax_files_per_process열린 파일의 소비를 제한하는 구성 매개변수입니다.

많은 수의 클라이언트 연결을 지원할 때 문제가 될 수 있는 또 다른 커널 제한은 최대 소켓 연결 대기열 길이입니다. 매우 짧은 기간 내에 그보다 많은 연결 요청이 도착하는 경우 일부는 거부될 수 있습니다.PostgreSQL서버는 요청을 처리할 수 있으며 해당 클라이언트는 다음과 같은 도움이 되지 않는 연결 실패 오류를 수신합니다.“스포츠 토토를 일시적으로 사용할 수 없습니다.”또는“연결이 거부되었습니다.”. 많은 플랫폼에서 기본 대기열 길이 제한은 128입니다. 이를 높이려면 다음을 통해 적절한 커널 매개변수를 조정하십시오.sysctl, 그런 다음을 다시 시작하세요.PostgreSQL서버. 매개변수의 이름은 다양합니다.net.core.somaxconn리눅스의 경우,kern.ipc.soacceptqueue최신 FreeBSD 및kern.ipc.somaxconnmacOS 및 기타 BSD 변종에서.

Linux의 기본 가상 메모리 동작은 다음에 적합하지 않습니다.PostgreSQL. 스포츠 토토이 메모리 오버커밋을 구현하는 방식으로 인해 스포츠 토토은PostgreSQL포스트마스터(감독자 서버 프로세스) 중 하나의 메모리가 필요한 경우PostgreSQL또는 다른 프로세스로 인해 시스템의 가상 메모리가 부족해졌습니다.

이런 일이 발생하면 다음과 같은 커널 메시지가 표시됩니다(이러한 메시지를 찾을 수 있는 위치는 시스템 문서 및 구성을 참조하세요):

메모리 부족: 프로세스 12345(postgres)가 종료되었습니다.

이는 다음을 나타냅니다.포스트그레메모리 부족으로 인해 프로세스가 종료되었습니다. 기존 데이터베이스 연결은 계속 정상적으로 작동하지만 새 연결은 허용되지 않습니다. 회복하려면,포스트그레SQL다시 시작해야 합니다.

이 문제를 피하는 한 가지 방법은 다음을 실행하는 것입니다.포스트그레SQL다른 프로세스가 기계의 메모리 부족을 실행하지 않을 것이라고 확신할 수 있는 기계에서. 메모리가 부족한 경우 운영 체제의 스왑 공간을 늘리면 문제를 방지하는 데 도움이 될 수 있습니다. 메모리 부족(OOM) 킬러는 실제 메모리와 스왑 공간이 소진된 경우에만 호출되기 때문입니다.

만약포스트그레SQL자체가 시스템 메모리 부족의 원인이므로 구성을 변경하여 문제를 피할 수 있습니다. 어떤 경우에는 메모리 관련 구성 매개변수를 낮추는 것이 도움이 될 수 있습니다. 특히shared_buffers, work_mem및hash_mem_multiplier. 다른 경우에는 데이터베이스 서버 자체에 너무 많은 연결을 허용하여 문제가 발생할 수 있습니다. 많은 경우에는 줄이는 것이 더 나을 수도 있습니다.max_connections대신 외부 연결 풀링 소프트웨어를 사용하세요.

커널의 동작을 수정하여 다음과 같은 일이 발생하지 않도록 할 수 있습니다.“오버커밋”메모리. 이 설정으로 인해 다음이 방지되지는 않지만OOM 킬러모두 호출되면 가능성이 크게 낮아지므로 시스템 동작이 더욱 강력해집니다. 이는 다음을 통해 엄격한 오버커밋 모드를 선택하여 수행됩니다.sysctl:

sysctl -w vm.overcommit_memory=2

또는 동등한 항목 배치/etc/sysctl.conf. 관련 설정을 수정하고 싶을 수도 있습니다.vm.overcommit_ratio. 자세한 내용은 커널 문서 파일을 참조하세요.https://www.kernel.org/doc/Documentation/vm/overcommit-accounting.

변경 여부에 관계없이 사용할 수 있는 또 다른 접근 방식vm.overcommit_memory, 프로세스별 설정입니다OOM 점수 조정포스트마스터 프로세스 값-1000, 이를 통해 OOM 킬러의 표적이 되지 않도록 보장합니다. 이를 수행하는 가장 간단한 방법은 실행하는 것입니다.

에코 -1000  /proc/self/oom_score_adj

에서PostgreSQL호출 직전 시작 스크립트포스트그레. 이 작업은 루트로 수행해야 하며 그렇지 않으면 아무런 효과가 없습니다. 따라서 루트 소유 시작 스크립트를 사용하는 것이 가장 쉬운 방법입니다. 이렇게 하려면 호출하기 전에 시작 스크립트에서 이러한 환경 변수도 설정해야 합니다.포스트그레:

PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj 내보내기
PG_OOM_ADJUST_VALUE=0 내보내기

이러한 설정은 포스트마스터 하위 프로세스가 일반 OOM 점수 조정 0으로 실행되도록 하여 OOM 킬러가 여전히 필요할 때 이를 대상으로 삼을 수 있도록 합니다. 다른 값을 사용할 수 있습니다.PG_OOM_ADJUST_VALUE다른 OOM 점수 조정과 함께 하위 프로세스를 실행하려는 경우. (PG_OOM_ADJUST_VALUE생략할 수도 있으며, 이 경우 기본값은 0입니다.) 설정하지 않은 경우PG_OOM_ADJUST_FILE, 하위 프로세스는 포스트마스터와 동일한 OOM 점수 조정으로 실행됩니다. 이는 포스트마스터가 우선 설정을 갖도록 하는 것이기 때문에 이는 현명하지 않습니다.

대규모 페이지를 사용하면 대규모 연속 메모리 청크를 사용할 때 오버헤드가 줄어듭니다.PostgreSQL특히 큰 값을 사용할 때shared_buffers. 이 기능을 사용하려면PostgreSQL스포츠 토토이 필요합니다CONFIG_HUGETLBFS=y그리고CONFIG_HUGETLB_PAGE=y. 또한 원하는 크기의 대용량 페이지를 충분히 제공하도록 운영 체제를 구성해야 합니다. 런타임 계산 매개변수shared_memory_size_in_huge_pages필요한 대용량 페이지 수를 보고합니다. 이 매개변수는 a로 서버를 시작하기 전에 볼 수 있습니다.포스트그레다음과 같은 명령:

$ postgres -D $PGDATA -C shared_memory_size_in_huge_pages
3170
$ grep ^Hugepagesize /proc/meminfo대형 페이지 크기: 2048 kB
$ls /sys/kernel/mm/hugepageshugepages-1048576kB hugepages-2048kB

이 예에서 기본값은 2MB이지만 다음을 사용하여 명시적으로 2MB 또는 1GB를 요청할 수도 있습니다.huge_page_size다음으로 계산된 페이지 수를 조정합니다.shared_memory_size_in_huge_pages. 최소한 필요하지만3170이 예에서는 거대한 페이지가 있지만, 시스템의 다른 프로그램에도 거대한 페이지가 필요한 경우 더 큰 설정이 적절할 것입니다. 다음을 사용하여 이를 설정할 수 있습니다.

# sysctl -w vm.nr_hugepages=3170

이 설정을 다음에 추가하는 것을 잊지 마세요./etc/sysctl.conf재부팅 후 다시 적용되도록 합니다. 기본값이 아닌 거대한 페이지 크기의 경우 대신 다음을 사용할 수 있습니다.

# 에코 3170  /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

다음과 같은 커널 매개변수를 사용하여 부팅 시 이러한 설정을 제공하는 것도 가능합니다.hugepagesz=2M hugepages=3170.

때때로 커널은 조각화로 인해 원하는 수의 대용량 페이지를 즉시 할당할 수 없으므로 명령을 반복하거나 재부팅해야 할 수도 있습니다. (재부팅 직후 대부분의 머신 메모리를 huge 페이지로 변환하는 데 사용할 수 있어야 합니다.) 주어진 크기에 대한 huge 페이지 할당 상황을 확인하려면 다음을 사용하세요.

$ cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

또한 설정을 통해 대용량 페이지를 사용하려면 데이터베이스 서버의 운영 체제 사용자 권한을 부여해야 할 수도 있습니다.vm.hugetlb_shm_group경유sysctl및/또는 다음을 사용하여 메모리를 잠글 수 있는 권한을 부여합니다.ulimit -l.

거대한 페이지의 기본 동작PostgreSQL가능한 경우 시스템의 기본 거대 페이지 크기와 함께 이를 사용하고 실패 시 일반 페이지로 돌아가는 것입니다. 거대한 페이지의 사용을 강제하려면 다음을 설정할 수 있습니다.거대한_페이지에켜짐inpostgresql.conf. 이 설정을 사용하면 참고하세요.포스트그레SQL사용 가능한 대용량 페이지가 충분하지 않으면 시작되지 않습니다.

자세한 설명은리눅스대형 페이지 기능을 살펴보세요https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt.