共享内存和信号量统称为“System V IPC”（连同消息队列，但消息队列与 PostgreSQL无关）。几乎所有现代操作系统都提供这些 特性，但并非所有系统都默认启用了它们或将其设置得足够大，尤其是 有 BSD 血统的系统。（对于 QNX 和 BeOS 移植，PostgreSQL 为这些设施提供了自己的替代实现。）

完全缺少这些功能时，通常会在服务器启动时出现 Illegal system call 错误。在这种情况下，除了重新配置 内核别无选择。没有它们，PostgreSQL 无法工作。

当PostgreSQL超出各种硬性IPC限制 之一时，服务器会拒绝启动，并应留下带有指导性的错误消息，说明所 遇到的问题以及应如何处理（另见第 16.3.1 节）。相关内核参数在不同系统上的 命名基本一致，表 16.2给出了概览。不过， 设置它们的方法却各不相同。下面给出一些平台上的建议。请注意，更改 这些设置通常需要重启机器，甚至可能需要重新编译内核。

最重要的共享内存参数是 SHMMAX，即以字节计的共享内存段的最大尺寸。如果 shmget返回像Invalid argument这样的错误 消息，可能是超出了这个限制。所需共享内存段的尺寸随请求的缓冲区 数量（-B 选项）和允许的连接数量（-N 选项） 而变化，尽管前者的影响最大。（作为临时解决办法，你可以调低这些 设置来消除失败。）粗略估计，你可以用缓冲区数量乘以块大小（默认 8 kB）再加上充足的额外开销（至少半兆字节）来估算所需的段尺寸。 你可能得到的任何错误消息都会包含失败分配请求的尺寸。

不太可能出问题的是共享内存段的最小尺寸（SHMMIN）， 对PostgreSQL来说应该最多大约是 256 kB（通常只是 1）。系统范围（SHMMNI）或每进程 （SHMSEG）的最大共享内存段数目不会导致问题，除非你的 系统把它们设成零。有些系统还对系统内共享内存的总量有限制；参见 下面的平台特定说明。

PostgreSQL为每个允许的连接（-N 选项） 使用一个信号量，每 16 个组成一组。每组还包含第 17 个信号量，其中 存放一个“魔数”，用来检测与其他应用程序使用的信号量集 的冲突。系统中的信号量最大数量由SEMMNS设置，因此它 必须至少等于max_connections再加上每 16 个允许连接一个 的额外信号量（见表 16.2中的公式）。 参数SEMMNI决定系统中同时可以存在的信号量集的数量上限， 因此它必须至少为ceil(max_connections / 16)。降低 允许的连接数是失败时的一种临时变通办法，这种失败通常表现为 semget函数返回措辞令人困惑的No space left on device。

在某些情况下，可能还需要增大SEMMAP，使其至少与 SEMMNS处于同一数量级。这个参数定义信号量资源映射的 大小，映射中每个连续的可用信号量块都需要占用一项。每当一个信号量 集合被释放时，它要么会并入与该释放块相邻的现有项，要么会登记为一 个新的映射项。如果映射已满，被释放的信号量就会丢失（直到重启）。 信号量空间的碎片化随时间推移可能导致可用信号量少于应有数量。

SEMMSL参数决定一个信号量集中可以包含多少个信号量， 对于PostgreSQL，它必须至少为 17。

与“信号量撤销”有关的其他各种设置，如SEMMNU 和SEMUME，对PostgreSQL无关紧要。

类 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配置参数来限制打开文件 的消耗。

在 Linux 2.4 及更高版本中，默认的虚拟内存行为对 PostgreSQL来说不是最优的。由于内核实现 内存过量分配的方式，如果其他进程的内存需求导致系统虚拟内存耗尽， 内核可能终止PostgreSQL服务器（即 postmaster进程）。

如果发生这种情况，你会看到类似这样的内核消息（该去哪里找这种 消息请查阅你的系统文档和配置）：

Out of Memory: Killed process 12345 (postmaster). 

这表明postmaster进程因内存压力而被终止。 虽然现有的数据库连接会继续正常工作，但不会接受新连接。要恢复， 需要重启PostgreSQL。

避免此问题的一种方法是把PostgreSQL 运行在这样一台机器上：你能确保其他进程不会把机器的内存耗尽。

在 Linux 2.6 及更高版本中，更好的解决方案是修改内核的行为，使其 不“过量分配”内存。这可以通过 sysctl 选择严格的过量分配 模式来完成：

sysctl -w vm.overcommit_memory=2

或者在/etc/sysctl.conf中加入等价的条目。你可能还想 修改相关的设置vm.overcommit_ratio。细节见内核文档文件 Documentation/vm/overcommit-accounting。

据报告，一些厂商的 Linux 2.4 内核带有 2.6 过量分配 sysctl 的早期 版本。然而，在没有相关代码的内核上把vm.overcommit_memory 设置为 2 会使情况变得更糟而不是更好。建议你在 2.4 安装上尝试此 操作之前，检查实际的内核源代码（见文件mm/mmap.c中的 函数vm_enough_memory）来验证你的副本支持什么。存在 overcommit-accounting文档文件并不能作为 该特性存在的证据。如有疑问，请咨询内核专家或你的内核供应商。