Lightdb_大页配置(Huge Page)介绍

正如熟悉Oracle的，在部署的时候建议配置Huge Page,而不是使用默认的PageTable内存映射表，原因是Linux的内存管理采取的是分页存取机制：把较大的物理内存分为了一个个固定大小（4KB）的内存页进行管理。每块内存页通过PageTable中的一个元组来维护虚拟/物理内存之间的映射。CPU为了提高虚拟/物理内存之间的转换效率，也会在TLB中缓存一定量的Page Table元组。

对于Oracle这种多进程架构程序来说，当服务端使用的共享内存较大，且并发连接数较多时，由于操作系统对于每个进程都要维护单独的内存映射，PageTable中的元组数目将会变得非常多，所占用的内存大小也会特别大。Linux为了应对这种场景，降低多进程下PageTable的内存消耗。自从2.6及以上内核版本提供了内存页大小为2MB的管理方式，称为Huge Page。如果使用Huge Page的话，相同物理内存使用量的情况下内存页的数目变少，减少了PageTable元组的条目个数，从而降低了系统的内存占用。

Lightdb和Oracle一样，是多进程数据库，同样支持大页，如果服务器物理内存大于128GB，尤其是达到256GB甚至更高时，强烈建议开启Linux系统的hugepage，同时将大页内存设置为shared_buffers的1.1~1.2倍，关于shared_buffers的介绍可参考官方文档https://www.hs.net/lig
htdb/docs/html/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY。这不仅仅是因为大页的性能会高一些，也是为了避免页表过大，造成服务器资源紧张

Lightdb配置大页

当Lightdb使用大量连续的内存块时，使用大页面会减少开销，特别是在使用大shared_buffers时。要在使用此特性，您需要一个包含CONFIG_HUGETLBFS=y和CONFIG_HUGETLB_PAGE=y的内核。
还必须调整内核设置vm.nr_hugepages。要估计所需的大页面的数量，需要重启数据库

计算nr_hugepages数量

lightdb@postgres=# show shared_buffer%;
      name      | setting |                         description                          
----------------+---------+--------------------------------------------------------------
 shared_buffers | 304MB   | Sets the number of shared memory buffers used by the server.
(1 row)

lightdb@postgres=# exit
[lightdb@lightdb ~]$ grep ^Hugepagesize /proc/meminfo
Hugepagesize:       2048 kB

nr_hugepages=shared_buffers1.1/Hugepagesize=3041.1/2=167
因此在这个实例中至少需要167个大页面

配置/etc/sysctl.conf

此设置添加到/etc/sysctl.conf，以便在重启后重新应用它

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

配置参数huge_pages为try

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

然后重新启动Lightdb数据库

真实场景：

某环境将实例（shared_buffers=64GB）部署在一台内存为256GB的服务器上，业务繁忙时服务器内存使用率接近90%，PageTable占用内存40GB。而开启Huge Page后相同业务场景的内存使用率降低到50%以下，PageTable大小仅300M左右。

Huge Page使用建议

虽然Huge Page在一定场景下可以改善服务端内存使用过高的情况，但不是鼓励所有的Lightdb实例都使用大页，盲目的开启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写冲突的发生概率。