类 Unix 操作系统强制执行各种可能会干扰您的 PostgreSQL 服务器操作的资源限制。特别重要的是对每个用户进程数、每个进程打开文件数以及每个进程可用内存大小的限制。这些限制中，每个都有一个 “硬” 限制和一个 “软” 限制。软限制就是实际算数的限制，但用户可以在硬限制内进行更改。只有 root 用户才能更改硬限制。系统调用 setrlimit 负责设置这些参数。外壳内置命令 ulimit（Bourne 外壳）或 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 配置参数以限制打开文件的消耗。

支持大量客户端连接时，可能涉及到的另一个内核限制是最大套接字连接队列长度。如果在很短的时间内到达的连接请求超过该限制，则部分请求可能会在 PostgreSQL 服务器处理请求之前遭到拒绝，客户端将收到无用的连接错误，例如 “资源暂时不可用” 或 “拒绝连接”。在许多平台上，默认队列长度限制为 128。要提高此限制，请通过 sysctl 调整相应的内核参数，然后重新启动 PostgreSQL 服务器。该参数在 Linux 上又称为 net.core.somaxconn，在较新的 FreeBSD 上称为 kern.ipc.soacceptqueue，在 macOS 和其他 BSD 变体上称为 kern.ipc.somaxconn。

Linux 上的默认虚拟内存行为对 PostgreSQL 并不理想。由于内核实现内存超量提交的方式，当 PostgreSQL 或其他进程对内存的需求导致系统耗尽虚拟内存时，内核可能会终止 PostgreSQL 后台进程（监视服务器进程）。

如果发生此情况，您会看到类似以下内容的内核消息（参阅系统文档和配置以了解在何处查找此类消息）

Out of Memory: Killed process 12345 (postgres).

这表明 postgres 进程由于内存压力而终止。虽然现有数据库连接将继续正常运行，但系统不再接受新连接。为了恢复正常运行，需要重新启动 PostgreSQL。

避免此问题的一个方法是在其他进程不会导致计算机耗尽内存的计算机上运行 PostgreSQL。如果内存紧缺，增大操作系统的交换空间可以帮助避免此问题，因为只有在物理内存和交换空间都耗尽时，才会启动内存不足 (OOM) 终结程序。

如果PostgreSQL本身导致系统内存耗尽，可以通过更改配置来避免这个问题。在某些情况下，降低与内存相关的配置参数可能会有所帮助，尤其是shared_buffers、work_mem和hash_mem_multiplier。在其他情况下，问题可能是允许太多连接到数据库服务器本身。在许多情况下，最好减少max_connections，并改用外部连接池软件。

可以修改内核的行为，使其不会“超量提交”内存。虽然此设置不会完全阻止调用OOM killer，但会大大降低其被调用的机会，因此会导致系统行为更稳健。这可以通过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 分数调整值设置为-1000，从而保证它不会成为 OOM killer 的目标。执行此操作最简单的方法是在PostgreSQL启动脚本中调用postgres之前执行

echo -1000 > /proc/self/oom_score_adj

请注意，此操作必须以root身份执行，否则将无效；因此，由root所有启动脚本是最容易执行此操作的地方。如果您执行此操作，还应该在调用postgres之前在启动脚本中设置以下环境变量

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

这些设置将导致postmaster子进程以零的正常OOM分数调整运行，以便OOM killer在需要时仍然可以将它们作为目标。如果希望子进程以其他OOM分数调整运行，可以使用其他PG_OOM_ADJUST_VALUE值。（也可以省略PG_OOM_ADJUST_VALUE，在这种情况下，它默认为零。）如果您没有设置PG_OOM_ADJUST_FILE，子进程将以与postmaster相同的OOM分数调整运行，这是不明智的，因为关键在于确保postmaster具有优先设置。

当使用大块连续内存块时，使用大页面可降低开销，如 PostgreSQL 所做，尤其是在使用 shared_buffers 的大值时。要在 PostgreSQL 中使用该功能，需要带 CONFIG_HUGETLBFS=y 和 CONFIG_HUGETLB_PAGE=y 的内核。还必须将操作系统配置为提供足够所需大小的大页面。运行时计算的参数 shared_memory_size_in_huge_pages 报告了所需的大页面数。使用如下的 postgres 命令，在启动服务器前可查看此参数

$ postgres -D $PGDATA -C shared_memory_size_in_huge_pages
3170
$ grep ^Hugepagesize /proc/meminfo
Hugepagesize:       2048 kB
$ ls /sys/kernel/mm/hugepages
hugepages-1048576kB  hugepages-2048kB

在此示例中，默认值是 2MB，但你还可以使用 huge_page_size 明确请求 2MB 或 1GB，从而调整 shared_memory_size_in_huge_pages 计算的页面数。虽然在此示例中至少需要 3170 个大页面，但如果机器上的其他程序也需要大页面，可以设置一个更大的值。我们可以使用以下方式来设置

# sysctl -w vm.nr_hugepages=3170

别忘了将此设置添加到 /etc/sysctl.conf，以便在重新启动后重新应用它。对于非默认大页面大小，我们可改用

# echo 3170 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

还可使用 kernel 参数（如 hugepagesz=2M hugepages=3170）在启动时提供这些设置。

有时，kernel 无法立即分配所需数量的大页面，原因是碎片化，因此可能需要重复该命令或重新启动。（在重新启动后，大部分机器内存都应可转换成大页面。）要验证给定大小的大页面分配情况，请使用

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

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

在 PostgreSQL 中，大页面的默认行为是在可能时使用它们，以及在失败时退回到正常页面，并使用系统默认大页面大小。要强制使用大页面，可以在 postgresql.conf 中将 huge_pages 设置为 on。请注意，使用此设置，如果没有足够的大页面可用，PostgreSQL 将无法启动。

有关 Linux 大页面功能的详细说明，请参阅 https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt。