PostgreSQL要求操作系统提供进程间通信（IPC）机制，特别是共享内存和信号量。Unix 派生系统通常提供“System V” IPC、“POSIX” IPC，或者两者兼有。Windows对这些特性有自己的实现，这里不作讨论。

默认情况下，PostgreSQL会分配极少量的 System V 共享内存，以及大量匿名的 mmap 共享内存。或者，也可以使用单个大型 System V 共享内存区域（见shared_memory_type）。此外，服务器启动时还会创建大量信号量，这些信号量可以是 System V 风格或 POSIX 风格。目前，Linux 和 FreeBSD 系统使用 POSIX 信号量，而其他平台使用 System V 信号量。

System V IPC 功能通常受系统范围的分配限制约束。当PostgreSQL超出这些限制之一时，服务器会拒绝启动，并留下带有指导性的错误消息，说明问题所在以及应如何处理（另见Section 18.3.1）。相关内核参数在不同系统上的命名基本一致，Table 18.1给出了概览；不过，设置它们的方法却各不相同。下面给出一些平台上的建议。

PostgreSQL要求少量字节的 System V 共享内存（在 64 位平台上通常是 48 字节）用于每一个服务器拷贝。在大多数现代操作系统上，这个量很容易得到。 但是，如果你运行了很多个服务器副本，或者显式配置服务器以使用大量 System V 共享内存(参见 shared_memory_type 和 dynamic_shared_memory_type)， 可能需要增加SHMALL（系统范围内 System V 共享内存的总量）。注意在很多系统上SHMALL是以页面而不是字节来度量。

不太可能出问题的是共享内存段的最小尺寸（SHMMIN），对PostgreSQL来说应该最多大约是 32 字节（通常只是1）。而系统范围（SHMMNI）或每个进程（SHMSEG）的最大共享内存段数目不太可能会导致问题，除非你的系统把它们设成零。

使用 System V 信号量时，PostgreSQL 为每个允许的连接（max_connections）、自动清理工作进程（autovacuum_max_workers）、WAL 发送进程（max_wal_senders）和后台进程（max_worker_processes）各使用一个信号量，每 16 个组成一组。每组还包含第 17 个信号量，其中存放一个“魔数”，用来检测与其他应用程序使用的信号量集的冲突。系统中的信号量最大数量由 SEMMNS 设置，因此它必须至少等于 max_connections、autovacuum_max_workers、max_wal_senders 和 max_worker_processes 之和，再为每 16 个允许的连接和工作进程额外增加一个信号量（参见 Table 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处于同一数量级。如果系统提供这个参数（很多系统没有），它定义的是信号量资源映射的大小；映射中每个连续的可用信号量块都需要占用一项。每当一个信号量集合被释放时，它要么会并入与该释放块相邻的现有项，要么会登记为一个新的映射项。如果映射已满，被释放的信号量就会丢失（直到重启）。因此，随着时间推移，信号量空间碎片化可能会导致可用信号量少于应有数量。

与“semaphore undo”有关的其他各种设置，如SEMMNU和SEMUME，不会影响PostgreSQL。

当使用 POSIX 信号量时，所需数量与 System V 相同，即每个允许连接（max_connections）、每个允许自动清理工作进程（autovacuum_max_workers）、每个允许 WAL 发送进程（max_wal_senders）、每个允许后台进程（max_worker_processes）等各需一个。在优先使用该实现的平台上，POSIX 信号量数量没有特定内核上限。

如果使用systemd，必须注意不要让操作系统过早移除 IPC 资源（包括共享内存）。这在从源码安装 PostgreSQL 时尤其值得关注。使用发行版软件包的用户较不容易受到影响，因为此时postgres用户通常会被创建为系统用户。

logind.conf 中的 RemoveIPC 设置控制当用户完全注销时是否移除 IPC 对象。系统用户不受此限制。原版 systemd 默认开启该设置，但某些操作系统发行版默认将其关闭。

当此设置开启时，一个常见现象是，用于并行查询执行的共享内存对象会在看似随机的时间被删除，导致在尝试打开或删除它们时出现错误和警告，例如

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

不同类型的 IPC 对象（共享内存与信号量、System V 与 POSIX）在 systemd 中的处理略有不同，因此你可能会发现某些 IPC 资源不会像其他资源那样被删除。但依赖这些细微差别并不可取。

“用户注销”可能会作为维护作业的一部分发生，也可能在管理员以postgres用户或类似名称登录时手工触发，因此通常很难彻底防止。

什么算作“系统用户”，是在编译 systemd 时依据 /etc/login.defs 中的 SYS_UID_MAX 设置确定的。

打包和部署脚本应当谨慎地使用useradd -r、adduser --system或其等价方式，把postgres用户创建为系统用户。

或者，如果该用户账户创建得不正确，或无法更改，建议在/etc/systemd/logind.conf或其他适当的配置文件中设置

RemoveIPC=no

类 Unix 操作系统会施加多种资源限制，这些限制可能干扰 PostgreSQL 服务器的运行。其中尤其重要的是：每个用户可用的进程数限制、每个进程可打开文件数限制，以及每个进程可用内存量限制。每一种限制都有“硬”限制和“软”限制。实际生效的是软限制，但用户可以自行把它调高到不超过硬限制；硬限制则只能由 root 用户修改。系统调用setrlimit负责设置这些参数。shell 的内置命令ulimit（Bourne shell）或limit（csh）可用于在命令行控制资源限制。在 BSD 派生系统上，/etc/login.conf文件控制登录时设置的各种资源限制。详细信息请参阅操作系统文档。相关参数有maxproc、openfiles和datasize。例如：

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

（-cur表示软限制；把它改为-max则表示设置硬限制。）

内核还可能对某些资源施加系统范围的限制。

PostgreSQL服务器为每个连接使用一个进程，因此你至少应提供与允许连接数相同数量的进程，再加上系统其他部分所需的进程数。通常这不是问题，但如果你在一台机器上运行多个服务器，资源可能就会变得紧张。

打开文件数的出厂默认限制通常被设为“对共享环境友好”的值，也就是允许许多用户在一台机器上共存，而不会占用不成比例的系统资源。如果你在一台机器上运行很多服务器，这也许正合适；但在专用服务器上，你可能会希望提高这个限制。

另一方面，有些系统允许单个进程打开非常多的文件；如果不止少数几个进程都这么做，就很容易超过系统范围的限制。如果你遇到这种情况，又不想修改系统范围的限制，可以设置PostgreSQL的max_files_per_process配置参数来限制其打开文件的消耗。

另一个在支持大量客户端连接时可能需要关注的内核限制，是套接字连接队列的最大长度。如果在很短时间内到达的连接请求超过了这个数量，那么其中一些请求可能会在主管服务器进程来得及处理之前就被拒绝，于是客户端会收到不太有帮助的连接失败错误，例如“Resource temporarily unavailable”或“Connection refused”。在许多平台上，默认队列长度限制是 128。要提高它，请通过sysctl调整相应的内核参数，然后重新启动主管服务器进程。该参数在不同系统上的名称不同：在 Linux 上是net.core.somaxconn，在较新的 FreeBSD 上是kern.ipc.soacceptqueue，在 macOS 和其他 BSD 变体上是kern.ipc.somaxconn。

Linux 上默认的虚拟内存行为对 PostgreSQL 并非最佳。由于内核实现内存过量分配的方式，如果 PostgreSQL 或其他进程的内存需求导致系统耗尽虚拟内存，内核可能会终止 PostgreSQL 的 postmaster（主管服务器进程）。

如果发生这种情况，你会看到类似下面的内核消息（至于应到哪里查看此类消息，请参阅你的系统文档和配置）：

Out of Memory: Killed process 12345 (postgres).

这表示 postgres 进程因内存压力而被终止。尽管现有数据库连接仍会继续正常运行，但新连接将不再被接受。要恢复服务，必须重启PostgreSQL。

避免该问题的一种办法，是让PostgreSQL运行在一台你能确定不会被其他进程耗尽内存的机器上。如果内存紧张，增加操作系统交换空间也有助于避免这个问题，因为内存不足（OOM）杀手只有在物理内存和交换空间都耗尽时才会被触发。

如果导致系统耗尽内存的正是PostgreSQL自身，那么你可以通过调整配置来避免该问题。在某些情况下，调低与内存相关的配置参数会有帮助，尤其是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，但也可与该设置的修改结合使用：将 postmaster 进程特有的OOM score adjustment值设为 -1000，从而保证它不会成为 OOM 杀手 的目标。最简单的方法是执行：

echo -1000 > /proc/self/oom_score_adj

执行位置是在 postmaster 的启动脚本中，紧接在调用 postmaster 之前。注意，必须以 root 身份执行此操作，否则不会生效；因此，在 root 所有的启动脚本中执行最方便。如果这样做，还应在启动脚本中调用 postmaster 之前设置以下环境变量：

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

这些设置会使 postmaster 子进程以正常的 OOM 分数调整值零运行，因此 OOM 杀手 仍可在需要时将它们作为目标。你可以为以下变量使用其他值：PG_OOM_ADJUST_VALUE，以使子进程采用其他 OOM 分数调整值。（PG_OOM_ADJUST_VALUE 也可以省略，此时默认为零。）如果不设置 PG_OOM_ADJUST_FILE，子进程将使用与 postmaster 相同的 OOM 分数调整值，这并不明智，因为这样设置的目的就是确保 postmaster 获得优先保护。

使用大块连续内存时，大页可以降低开销；PostgreSQL 就采用这种内存使用方式，尤其是将 shared_buffers 设为较大值时。要让 PostgreSQL 使用此功能，内核需要配置为 CONFIG_HUGETLBFS=y 和 CONFIG_HUGETLB_PAGE=y。还必须调整内核设置 vm.nr_hugepages。要估算所需的大页数量，请启动 PostgreSQL 时先禁用大页，然后检查 postmaster 的匿名共享内存段大小以及系统的大页大小，使用的接口是 /proc 文件系统。操作可能如下所示：

$ 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，因此本例至少需要 3170 个大页，可以这样设置：

$ sysctl -w vm.nr_hugepages=3170

如果机器上的其他程序也需要大页，应使用更大的设置值。不要忘记将此设置添加到 /etc/sysctl.conf，使其在重启后重新生效。

有时内核无法立即分配所需数量的大页，因此可能需要重复执行该命令或重启。（刚重启后，机器的大部分内存应该都可以转换为大页。）要确认大页分配情况，请使用：

$ grep Huge /proc/meminfo

你可能还需要授予数据库服务器的操作系统用户使用大页的权限，例如通过sysctl设置vm.hugetlb_shm_group，以及/或者授予其使用ulimit -l锁定内存的权限。

PostgreSQL 对大页的默认行为是：只要可能就使用它们；如果失败，则回退到普通页。要强制使用大页，可以在 postgresql.conf 中将 huge_pages 设为 on。请注意，在这种设置下，如果没有足够的大页可用，PostgreSQL 将无法启动。

关于Linux大页特性的详细说明，请参见https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt。