17.4.1. 共享内存和信号灯

共享内存和信号灯的正确叫法是"SystemV IPC"(还有消息队列，不过与PostgreSQL无关)。 尽管所有现代操作系统都提供这些特性，但并不是所有系统缺省都打开它或者有足够的资源， 尤其是可用的RAM和数据库应用的需求增长。 （对于Windows移植，PostgreSQL自己提供这套机制的替换实现， 所以大多数本条可以忽略不计。）

完全缺少这些机制的表现通常是在服务器启动时的Illegalsystemcall 错误。这时除了重新配置内核以外没什么可做的。PostgreSQL没它们不工作。 然而，在现代的操作系统,这种情况是罕见的。

如果PostgreSQL超出了这些IPC资源的硬限制之 一的时候就会拒绝启动，并且留下一条相当有提示的错误信息， 告诉你它碰到了什么问题以及需要为它做些什么(又见Section 17.3.1)。相关的内核参数在不同系统之间有着相对固定的术语 ；Table 17-1是一个概况。不过，设置它们的方法却多种多样。 不过要注意的是，你可能最好重新启动机器，或者还要重新编译内核来修改这些设置。

最重要的共享内存参数是SHMMAX(以字节记的共享内存段可拥有的最大尺寸)。 如果你收到来自shmget的类似"Inval idargument"这样的错误信息， 那么很有可能是你超过限制了。要求的共享内存段数量与若干个 PostgreSQL配置参数相关，如Table 17-2所示。 （任何错误消息，你可能会包括分配请求失败的确切大小。） 因此，作为一种临时的解决方法，你可以降低这些设置来绕过失败。 虽然它有可能获得PostgreSQL运行2MB的SHMMAX的， 你需要相当可接受的性能。可取设置在数百兆到几千兆字节。

有些系统对系统里面共享内存的总数(SHMALL)还有限制。 请注意这个数值必须足够大，大到PostgreSQL 加上其它使用共享内存段的应用的总和。注意：SHMALL 在很多系统上是用页面数，而不是字节数来计算的。

不太可能出问题的是共享内存段的最小尺寸(SHMMIN)， 对PostgreSQL来说大约是500kB左右(通常只是1)， 而系统范围(SHMMNI)或每进程(SHMSEG) 最大共享内存段数量不应该会产生问题，除非你的系统把它们设成零。

PostgreSQL每个允许的连接使用一个信号灯(max_connections)， 以16个为一套。每套信号灯还包含第17个信号灯， 它里面存储一个"magicnumber"，以检测和其它应用使用的信号灯集冲突。 系统里的最大信号灯数目是由SEMMNS设置的， 因此这个值应该至少和max_connections加autovacuum_max_workers设置一样大， 并且每16个连接还要另外加一个(参阅Table 17-1里面的公式)。参数SEMMNI 决定系统里一次可以存在的信号灯集的数目。因此这个参数至少应该 为ceil((max_connections+autovacuum_max_workers)/16)。 降低允许的连接数目是一个临时的绕开失败的方法，这个启动失败通常被 来自函数semget的错误响应"Nospaceleftondevice"搞得很让人迷惑。

有时候还可能有必要增大SEMMAP，使之至少按照SEMMNS配置。 这个参数定义信号灯资源映射的尺寸，可用的每个连续的信号灯块在这个映射中存放一条记录。 每当一套信号灯被释放，那么它要么会加入到该映射中一条相连的已释放块的入口中， 要么注册成一条新的入口。如果映射填满了碎片，那么被释放的信号灯就丢失了(除非重启)。 因此信号灯空间的碎片时间长了会导致可用的信号灯比应该有的信号灯少。

SEMMSL参数决定一套信号灯里可以有多少信号灯， 对于PostgreSQL而言应该至少是17。

许多设置与"semaphoreundo"(信号灯恢复)有关， 比如SEMMNU和SEMUME，这些不影响PostgreSQL。

17.4.2. 资源限制

Unix类系统强制了许多资源限制，这些限制可能干扰PostgreSQL 服务器的运行。这里尤其重要是对每个用户的进程数目的限制、每个进程打开文件数目、 以及每个进程可用的内存。这些限制中每个都有一个"硬"限制和 一个"软"限制。实际使用的是软限制，但用户可以自己修改成 最大为硬限制的数目。而硬限制是只能由root用户修改的限制。 系统调用setrlimit负责设置这些参数。 shell的内建命令ulimit(Bourneshells)或 limit(csh)就是用于在命令行上控制资源限制的。 在BSD衍生的系统上，/etc/login.conf 文件控制在登录时对各种资源设置什么样的限制数值。 参阅操作系统文档获取细节。相关的参数是maxproc， openfiles，datasize。比如：

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

（-cur是软限制，后面附加-max就可以设置硬限制。）

内核通常也有一些系统范围的资源限制。

• 在Linux上，/proc/sys/fs/file-max 决定内核可以支持的最大文件数。你可以通过往该文件写入一个不同的数值修改此值， 或者在/etc/sysctl.conf里增加一个赋值。 每个进程的最大打开文件限制是在编译内核的时候固定的； 参阅/usr/src/linux/Documentation/proc.txt获取更多信息。

PostgreSQL服务器每个连接都使用一个进程， 所以你应该至少允许和连接数相同的进程数，再加上系统其它部分所需要的数目。 通常这个并不是什么问题，但如果你在一台机器上运行多个服务器，资源使用可能就会紧张。

打开文件数目的出厂缺省设置通常设置为"社会友好"数值， 就是说允许许多用户共存一台机器，而不会导致系统资源使用的不当比例。 如果你在一台机器上运行许多服务器，这也许就是你想要的，但是在特殊的服务器上， 你可能需要提高这个限制。

问题的另外一边，一些系统允许独立的进程打开非常多的文件； 如果不止几个进程这么干，那系统范围的上限就很容易达到。如果你发现这样的现像， 并且不想修改系统范围的限制，你就可以设置PostgreSQL的 max_files_per_process配置参数来限制打开文件数的消耗。

17.4.3. Linux内存过量

在Linux2.4以及之后的版本里，缺省的虚拟内存的行为不是对 PostgreSQL最优的。原因在于内核实现内存 过量的方法，如果其它进程的内存请求导致系统用光虚拟内存，那么内核可能会终止 PostgreSQL服务器进程。

如果发生了这样的事情，你会看到像下面这样的内核信息 (参考你的系统文档和配置，看看在哪里能看到这样的信息)：

OutofMemory:Killedprocess12345(postgres).

这表明postgres因为内存压力而终止了。 尽管现有的数据连接将继续正常运转，但是新的连接将无法接受。 要想恢复，你应该重启PostgreSQL。

一个避免这个问题的方法是在一台你确信不会因为其它进程而耗 尽内存的机器上运行PostgreSQL。 如果内存资源紧张，增加交换空间的操作系统可以帮助避免这个问题，因为 内存不足（OOM）的杀手是只有当物理内存和调用交换空间用尽。

在Linux2.6及以后的版本里，一个更好的解决方法是修改内存的行为， 这样它就不会再"过量"内存。 虽然此设置不会阻止OOMkiller被调用 干脆，它会降低的机会显着，因此将导致更强大的系统行为。 这是通过用sysctl选取一个严格的过提交模式实现的：

sysctl-wvm.overcommit_memory=2

或者在/etc/sysctl.conf里放一个等效的条目。 你可能还希望修改相关的vm.overcommit_ratio设置。 详细信息请参阅内核文档的Documentation/vm/overcommit-accounting文件。

另一种方法，可以使用或不改变vm.overcommit_memory， 要将postmaster进程的特定进程的oom_adj值设置为-17，从而保证不会成为OOM杀手的目标。 最简单的方法这样来执行

echo-17>/proc/self/oom_adj

在postmaster的启动脚本之前调用postmaster。 请注意必须以root身份，完成此操作，或它将没有任何影响;所以一个拥有root权限的启动脚本最容易做这事。 如果这样做，你可能还要将-DLINUX_OOM_ADJ=0添加到CFLAGS编译PostgreSQL。 这样将导致postmaster子进程以通常oom_adj值为0的运行，所以OOM杀手在需要的时候以它们作为目标。