共享内存和信号量合称“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选项）而变化，尽管前者影响最大。（作为临时解决方案，你可以降低这些设置来消除故障。）作为粗略的近似，你可以按照表 16.2中的建议估计所需的段尺寸。你可能得到的任何错误消息都会包含失败分配请求的尺寸。

有些系统还对系统中共享内存的总量（SHMALL）有限制。请确保它足够容纳PostgreSQL以及使用共享内存段的其他任何应用程序。（注意：在许多系统上SHMALL以页而不是字节计量。）

较不容易引起问题的是共享内存段的最小尺寸（SHMMIN），对PostgreSQL来说它至多需要大约 256 kB（通常就是 1）。系统范围内（SHMMNI）或每进程（SHMSEG）的最大段数不太可能引起问题，除非你的系统把它们设置成了零。

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

在某些情况下，可能还需要把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 参数的早期实现。但是，在没有相关代码的 2.4 内核上将 vm.overcommit_memory 设为 2，会使情况更糟，而非更好。建议在 2.4 安装上尝试之前，检查实际内核源码（参见文件 mm/mmap.c 中的函数 vm_enough_memory），确认内核支持的功能。存在 overcommit-accounting 文档文件，不能作为该功能已存在的证据。如有任何疑问，请咨询内核专家或内核供应商。