PostgreSQL数据库配置大页

Posted 2021-09-11 PostgreSQLChina

作者：小麦苗

Linux标准大页和透明大页参考：https://www.xmmup.com/linux-biaozhundayehetoumingdaye.html

为了保证物理内存能得到充分的利用，避免内存空间浪费，Linux把进程当前使用的内存部分加载到物理内存里，而不使用的部分则暂不加载。PostMaster进程注册共享内存时，系统只是分配一个虚拟的地址空间，并不直接分配物理内存。当有实际的内存访问时，CPU才会将虚拟地址映射到物理内存的一个地址上。维护这个映射关系的就是PageTable，它负责将虚拟内存地址转换成物理内存地址。

Linux的内存管理采取的是分页存取机制：把较大的物理内存分为了一个个固定大小（4KB）的内存页进行管理。每块内存页通过PageTable中的一个元组来维护虚拟/物理内存之间的映射。CPU为了提高虚拟/物理内存之间的转换效率，也会在TLB中缓存一定量的Page Table元组。

对于PostgreSQL这种多进程架构程序来说，当服务端使用的共享内存较大，且并发连接数较多时，由于操作系统对于每个进程都要维护单独的内存映射，PageTable中的元组数目将会变得非常多，所占用的内存大小也会特别大。

Linux为了应对这种场景，降低多进程下PageTable的内存消耗。自从2.6及以上内核版本提供了内存页大小为2MB的管理方式，称为Huge Page。如果使用Huge Page的话，相同物理内存使用量的情况下内存页的数目变少，减少了PageTable元组的条目个数，从而降低了系统的内存占用。

真实应用场景：某PG用户将实例（shared_buffers=64GB）部署在一台内存为256GB的ECS上，业务繁忙时ECS内存使用率为85%，PageTable占用内存120GB。而开启Huge Page后相同业务场景的内存使用率降低到50%以下，PageTable大小仅300M！

PG从9.4版本开始支持大页，对一些连接数很大且内存较大的PostgreSQL数据库，强烈建议配置大页（Huge pages）。这不仅仅是因为大页的性能会高一些，也是为了避免页表过大。

PG配置大页

当PostgreSQL使用大量连续的内存块时，使用大页面会减少开销，特别是在使用大shared_buffers时。 要在PostgreSQL中使用此特性，您需要一个包含CONFIG_HUGETLBFS=y和CONFIG_HUGETLB_PAGE=y的内核。您还必须调整内核设置vm.nr_hugepages。要估计所需的大页面的数量，请启动PostgreSQL，而不启用大页面，并使用/proc文件系统来检查postmaster的匿名共享内存段大小以及系统的大页面大小。

计算nr_hugepages数量

例如：

$ 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

如果机器上的其他程序也需要大页面，则更大的设置将是合适的。

也可以基于如下脚本直接计算相应的HugePage的大小。

#!/bin/bash
PGDATA='/pg13/pgdata'
pid=`head -1 $PGDATA/postmaster.pid`
echo 'Pid:       $pid'
peak=`grep ^VmPeak /proc/$pid/status | awk '{ print $2 }'`
echo 'VmPeak:       $peak kB'
hps=`grep ^Hugepagesize /proc/meminfo | awk '{ print $2 }'`
echo 'Hugepagesize:  $hps kB'
hp=$((peak/hps))
echo Set Huge Pages:   $hp
sysctl -w vm.nr_hugepages=$hp

这种配置一般针对于数据库服务器，就是只跑了个PostgreSQL，如果还有其他应用程序也需要大页，则需要合理设置。

不要忘记将此设置添加到/etc/sysctl.conf，以便在重启后重新应用它。

echo 3170 > /proc/sys/vm/nr_hugepages
cat >> /etc/sysctl.conf <<'EOF'
vm.nr_hugepages=3170
EOF
sysctl -p

通过此脚本计算出大页的大小，然后添加到/etc/sysctl.conf里，sysctl -p生效。

配置参数huge_pages为try

PostgreSQL中大页面的默认行为是尽可能使用它们并且在失败时转回到正常页面。要强制使用大页面，你可以在postgresql.conf中把huge_pages设置成on。注意此设置下如果没有足够的大页面可用，PostgreSQL将会启动失败。一般建议默认值try即可。

postgres=# show huge_pages;
 huge_pages 
------------
 try
(1 row)

然后重新启动PG数据库。

查询

有时候内核会无法立即分配想要数量的大页面，所以可能有必要重复该命令或者重新启动。 在重新启动之后，会立即将大部分机器的内存转换为大页面。

要验证巨大的页面分配情况，请使用：

[pg13@lhrpg pgdata]$ cat /proc/meminfo | grep huge -i    
AnonHugePages:    243712 kB
HugePages_Total:     300
HugePages_Free:      144
HugePages_Rsvd:       73
HugePages_Surp:        0
Hugepagesize:       2048 kB

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

参数huge_pages

huge_pages (enum)

控制是否为主共享内存区域请求大页。有效值是try（默认）、on以及off。

• 如果huge_pages被设置为try，则服务器将尝试请求使用大页，但是如果请求失败则会退回到默认的方式。如果OS没有配置大页或者配置的大页小于PG所需要的大页内存，那么就会请求失败。
• 如果为on，请求大页失败将使得服务器无法启动。例如：

[pg13@lhrpg pgdata]$ pg_ctl start
waiting for server to start....2021-08-03 09:25:16.697 CST [11917] FATAL:  could not map anonymous shared memory: Cannot allocate memory
2021-08-03 09:25:16.697 CST [11917] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 150585344 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
2021-08-03 09:25:16.697 CST [11917] LOG:  database system is shut down
 stopped waiting
pg_ctl: could not start server
Examine the log output.

• 如果为off，则不会请求大页。

当前，只有Linux和Windows上支持这个设置。在其他系统上这个参数被设置为try时，它会被忽略。

大页面的使用会导致更小的页面表以及花费在内存管理上的CPU时间更少，从而提高性能。

大页在Windows上被称为大页面。要使用大页面，需要为运行PostgreSQL的Windows用户账号分配Lock Pages in Memory的用户权限。可以使用Windows的组策略工具（gpedit.msc）来分配用户权限Lock Pages in Memory。为了在命令窗口以单进程（而不是Windows服务）的方式启动数据库服务器，命令窗口必须以管理员身份运行或者禁用用户访问控制（UAC）。当UAC被启用时，普通的命令窗口会在启动时收回用户权限Lock Pages in Memory。

注意这种设置仅影响主共享内存区域。Linux、FreeBSD以及Illumos之类的操作系统也能为普通内存分配自动使用大页（也被称为“超级”页或者“大”页面），而不需要来自PostgreSQL的显式请求。在Linux上，这被称为“transparent huge pages”（THP，透明大页）。已知这种特性对某些Linux版本上的某些用户会导致PostgreSQL的性能退化，因此当前并不鼓励使用它（与huge_pages的显式使用不同）。

Huge Page使用建议

虽然Huge Page在一定场景下可以改善服务端内存使用过高的情况，但不是鼓励所有的PG实例都使用大页，盲目的开启Huge Page可能引起服务端的性能下降。下面我们根据Huge Page的优缺点来分析下使用场景。

Huge Page优势：
（1）CPU的TLB可以缓存的物理地址空间更大，从而提升TLB的命中率，降低CPU负载；
（2）Huge Page使用的内存是不可交换（swap）的，没有内存空间换入/换出的开销；
（3）极大的减少了系统维护PageTable的内存开销。

Huge Page劣势：
（1）Huge Page使用的内存需要预先分配；
（2）Huge Page使用固定大小的内存区域，不会被释放；
（3）对于写密集型的场景，Huge Page会加大Cache写冲突的发生概率。

所以强烈推荐PG实例开启Huge Page的场景：共享内存使用较大（>=8GB）且连接数较多（>= 500），并且热点数据分散。

不推荐PG实例开启Huge Page的场景：写业务密集，热点数据集中且内存使用较小。

PG开启Huge Page时的注意事项

（1）当配置参数huge_pages设置为on时，若PG启动时需要注册的共享内存大于操作系统提供的Huge Page大小时，数据库将无法启动。推荐将huge_pages参数设置为try，在此种场景下，PostMaster将会改为申请普通内存。
（2）修改shared_buffers/wal_buffers等共享内存相关的GUC参数时，需要重新计算操作系统所需的Huge Page数，以防服务端无法启动或者部分大页内存没有被使用且无法释放而造成浪费。

Linux大页面特性的详细描述可见：https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt