Configuring huge pages for your PostgreSQL instance, RedHat/CentOS version

Configuring huge pages for your PostgreSQL instance, RedHat/CentOS version

Almost every PostgreSQL I get in touch with is not configured to use huge pages, which is quite a surprise as it can give you a performance boost. Actually it is not the PostgreSQL instance you need to configure but the operating system to provide that. PostgreSQL will use huge pages by default when they are configured and will fall back to normal pages otherwise. The parameter which controls that in PostgreSQL is huge_pages which defaults to “try” leading to the behavior just described: Try to get them, otherwise use normal pages. Lets see how you can do that on RedHat and CentOS. I’ll write another post about how you do that for Debian based distributions shortly.

 

What you need to know is that RedHat as well as CentOS come with tuned profiles by default. This means kernel parameters and other settings are managed through profiles dynamically and not anymore by adjusting /etc/sysctl (although that works as well). When you are in virtualized environment (VirtualBox in my case) you probably will see something like this:

1

2

postgres@pgbox:/home/postgres/ [PG10] tuned-adm active

Current active profile: virtual-guest

Virtual guest is maybe not the best solution for database server as it comes with those settings (especially vm.dirty_ratio and vm.swappiness):

1

2

3

4

5

6

7

postgres@pgbox:/home/postgres/ [PG10] cat /usr/lib/tuned/virtual-guest/tuned.conf  | egrep -v "^$|^#"

[main]

summary=Optimize for running inside a virtual guest

include=throughput-performance

[sysctl]

vm.dirty_ratio = 30

vm.swappiness = 30

What we do at dbi services is to provide our own profile which adjusts the settings better suited for a database server.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

postgres@pgbox:/home/postgres/ [PG10]  cat /etc/tuned/dbi-postgres/tuned.conf | egrep -v "^$|^#"

[main]

summary=dbi services tuned profile for PostgreSQL servers

[cpu]

governor=performance

energy_perf_bias=performance

min_perf_pct=100

[disk]

readahead=>4096

[sysctl]

vm.overcommit_memory=2

vm.swappiness=0

vm.dirty_ratio=2

vm.dirty_background_ratio=1

What has all this to do with larges pages you might think. Well, tuning profiles can also be used to configure them and for us this is the preferred method because we can do it all in one file. But we before we do that lets look at the PostgreSQL instance:

1

2

3

4

5

6

7

8

9

10

11

postgres=# select version();

                                                          version                                                          

----------------------------------------------------------------------------------------------------------------------------

 PostgreSQL 10.0 build on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16), 64-bit

(1 row)

 

postgres=# show huge_pages;

 huge_pages

------------

 try

(1 row)

As said at the beginning of this post the default behavior of PostgreSQL is to use them if available. The question now is: How can you check if you have huge pages configured on the operating system level? The answer is in the virtual /proc/meminfo file:

1

2

3

4

5

6

7

postgres=# \! cat /proc/meminfo | grep -i huge

AnonHugePages:      6144 kB

HugePages_Total:       0

HugePages_Free:        0

HugePages_Rsvd:        0

HugePages_Surp:        0

Hugepagesize:       2048 kB

Alle “HugePages” statistics report a zero so this system definitely is not configured to provide huge pages to PostgreSQL. AnonHugePages is for Transparent Hugepage and it is common recommendation to disable them for database servers. So we have two tasks to complete:

  • Disable transparent huge pages
  • Configure the system to provide enough huge pages for our PostgreSQL instance

For disabling transparent huge pages we just need to add the following lines to our tuning profile:

1

2

postgres@pgbox:/home/postgres/ [PG10] sudo echo "[vm]

> transparent_hugepages=never" >> /etc/tuned/dbi-postgres/tuned.conf

When transparent huge pages are enabled you can see that in the following file:

1

2

postgres@pgbox:/home/postgres/ [PG10] cat /sys/kernel/mm/transparent_hugepage/enabled

[always] madvise never

Once we switch the profile to our own profile:

1

2

3

postgres@pgbox:/home/postgres/ [PG10] sudo tuned-adm profile dbi-postgres

postgres@pgbox:/home/postgres/ [PG10] sudo tuned-adm active

Current active profile: dbi-postgres

… you’ll notice that it is disabled from now on:

1

2

postgres@pgbox:/home/postgres/ [PG10] cat /sys/kernel/mm/transparent_hugepage/enabled

always madvise [never]

Task one completed. For configuring the operating system to provide huge pages for our PostgreSQL we need to know how many huge pages we require. How do we do that? The procedure is documented in the PostgreSQL documentation. Basically you start your instance and then check how many you would require. In my case, to get the PID of the postmaster process:

1

2

postgres@pgbox:/home/postgres/ [PG10] head -1 $PGDATA/postmaster.pid

1640

To get the VmPeak for that process:

1

2

postgres@pgbox:/home/postgres/ [PG10] grep ^VmPeak /proc/1640/status

VmPeak:   344340 kB

As the huge page size is 2MB on my system (which should be default for most systems):

1

2

postgres@pgbox:/home/postgres/ [PG10] grep ^Hugepagesize /proc/meminfo

Hugepagesize:       2048 kB

… we will require at least 344340/2048 huge pages for this PostgreSQL instance:

1

2

postgres@pgbox:/home/postgres/ [PG10] echo "344340/2048" | bc

168

All we need to do is to add this to our tuning profile in the “[sysctl]” section:

1

2

postgres@pgbox:/home/postgres/ [PG10] grep nr_hugepages /etc/tuned/dbi-postgres/tuned.conf

vm.nr_hugepages=170

Re-set the profile and we’re done:

1

2

3

4

5

6

7

8

postgres@pgbox:/home/postgres/ [PG10] sudo tuned-adm profile dbi-postgres

postgres@pgbox:/home/postgres/ [PG10] cat /proc/meminfo | grep -i huge

AnonHugePages:      4096 kB

HugePages_Total:     170

HugePages_Free:      170

HugePages_Rsvd:        0

HugePages_Surp:        0

Hugepagesize:       2048 kB

This confirms that we now have 170 huge pages of which all of them are free to consume. Now lets configure PostgreSQL to only start when it can get the amount of huge pages required by switching the “huge_pages” parameter to “on” and restart the instance:

1

2

3

4

5

6

7

8

9

10

11

12

13

postgres@pgbox:/home/postgres/ [PG10] psql -c "alter system set huge_pages=on" postgres

ALTER SYSTEM

Time: 0.719 ms

postgres@pgbox:/home/postgres/ [PG10] pg_ctl -D $PGDATA restart -m fast

waiting for server to shut down.... done

server stopped

waiting for server to start....2018-02-25 11:21:29.107 CET - 1 - 3170 -  - @ LOG:  listening on IPv4 address "0.0.0.0", port 5441

2018-02-25 11:21:29.107 CET - 2 - 3170 -  - @ LOG:  listening on IPv6 address "::", port 5441

2018-02-25 11:21:29.110 CET - 3 - 3170 -  - @ LOG:  listening on Unix socket "/tmp/.s.PGSQL.5441"

2018-02-25 11:21:29.118 CET - 4 - 3170 -  - @ LOG:  redirecting log output to logging collector process

2018-02-25 11:21:29.118 CET - 5 - 3170 -  - @ HINT:  Future log output will appear in directory "pg_log".

 done

server started

As the instance started all should be fine and we can confirm that by looking at the statistics in /proc/meminfo:

1

2

3

4

5

6

7

postgres@pgbox:/home/postgres/ [PG10] cat /proc/meminfo | grep -i huge

AnonHugePages:      4096 kB

HugePages_Total:     170

HugePages_Free:      162

HugePages_Rsvd:       64

HugePages_Surp:        0

Hugepagesize:       2048 kB

You might be surprised that not all (actually only 8) huge pages are used right now but this will change as soon as you put some load on the system:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

postgres=# create table t1 as select * from generate_series(1,1000000);

SELECT 1000000

postgres=# select count(*) from t1;

  count 

---------

 1000000

(1 row)

 

postgres=# \! cat /proc/meminfo | grep -i huge

AnonHugePages:      4096 kB

HugePages_Total:     170

HugePages_Free:      153

HugePages_Rsvd:       55

HugePages_Surp:        0

Hugepagesize:       2048 kB

postgres=#

Hope this helps …

内容概要:本文为《科技类企业品牌传播白皮书》,系统阐述了新闻媒体发稿、自媒体博主种草与短视频矩阵覆盖三大核心传播策略,并结合“传声港”平台的AI工具与资源整合能力,提出适配科技企业的品牌传播解决方案。文章深入分析科技企业传播的特殊性,包括受众圈层化、技术复杂性与传播通俗性的矛盾、产品生命周期影响及2024-2025年传播新趋势,强调从“技术输出”向“价值引领”的战略升级。针对三种传播方式,分别从适用场景、操作流程、效果评估、成本效益、风险防控等方面提供详尽指南,并通过平台AI能力实现资源智能匹配、内容精准投放与全链路效果追踪,最终构建“信任—种草—曝光”三位一体的传播闭环。; 适合人群:科技类企业品牌与市场负责人、公关传播从业者、数字营销管理者及初创科技公司创始人;具备一定品牌传播基础,关注效果可量化与AI工具赋能的专业人士。; 使用场景及目标:①制定科技产品全生命周期的品牌传播策略;②优化媒体发稿、KOL合作与短视频运营的资源配置与ROI;③借助AI平台实现传播内容的精准触达、效果监测与风险控制;④提升品牌在技术可信度、用户信任与市场影响力方面的综合竞争力。; 阅读建议:建议结合传声港平台的实际工具模块(如AI选媒、达人匹配、数据驾驶舱)进行对照阅读,重点关注各阶段的标准化流程与数据指标基准,将理论策略与平台实操深度融合,推动品牌传播从经验驱动转向数据与工具双驱动。
### 配置 Postgresql-common 的方法 在 Linux 上配置 `postgresql-common` 主要是为了简化多个版本 PostgreSQL 实例的管理。安装并配置此软件包可以确保系统上不同版本的数据库服务器能够共存和平稳运行。 #### 安装 postgresql-common 软件包 通常情况下,在基于 Debian 或 Ubuntu 的发行版中,可以通过 APT 包管理系统来安装: ```bash sudo apt-get update && sudo apt-get install postgresql-common ``` 这会自动处理依赖关系并将必要的文件放置到位[^1]。 #### 设置默认版本 为了指定哪个版本作为系统的默认 PostgreSQL 版本,可编辑 `/etc/postgresql-common/createcluster.conf` 文件中的 `PGVERSION` 参数。该参数定义了创建新集群时所使用的 PostgreSQL 版本号。 #### 创建新的 PostgreSQL 集群 一旦设置了期望的 PGVERSION 值之后,就可以通过命令行工具轻松地建立一个新的 PostgreSQL 数据库实例(即“集群”)。例如: ```bash sudo pg_createcluster <version> main --start ``` 这里的 `<version>` 应替换为你想要启动的具体 PostgreSQL 版本号码;而 `main` 则是指定数据目录名称,默认情况下它会被放在 `/var/lib/postgresql/<version>/main/` 下面。 #### 自动化初始化过程 对于希望进一步自动化这一流程的人来说,还可以利用 Ansible Playbooks 或其他配置管理工具来进行批量部署操作。这些工具可以帮助管理员更高效地管理和维护多台机器上的相同设置环境。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值