现象：swap占用超过70%
free -h
total used free shared buff/cache available
Mem: 78G 8.2G 22G 21G 48G 46G
Swap: 15G 11G 4.2G
查看swap里面都是postgresql的主要进程进程，且这台机器是个主库
45000 4146.14M
44955 4146M
44952 4145.98M
44951 4145.77M
13310 4145.76M
44950 4145.75M
44949 4145.74M
11381 4145.68M
10958 4145.61M
11213 4145.61M
[pg@xxx_pg04 ~]$ ps -ef|grep 45000
pg 45000 13310 0 Sep28 ? 00:06:19 postgres: walsender repl xx.xx.xx.xx(58232) streaming 264/3218A510
pg 49805 47614 0 08:09 pts/0 00:00:00 grep --color=auto 45000
[pg@xxx_pg04 ~]$ ps -ef|grep 44955
pg 44955 13310 0 Sep28 ? 00:00:01 postgres: logical replication launcher
pg 49972 47614 0 08:09 pts/0 00:00:00 grep --color=auto 44955
[pg@xxx_pg04 ~]$ ps -ef|grep 44952
pg 27646 4025 0 Oct28 ? 00:00:00 postgres: xxuser xxdb xx.xx.xx.xx(44952) idle
pg 44952 13310 0 Sep28 ? 00:01:11 postgres: autovacuum launcher
pg 50285 47614 0 08:10 pts/0 00:00:00 grep --color=auto 44952
处理：物理内存空闲空间大于11G，不停机关闭swap，把swap占用的刷进内存
swapoff -a、swapon -a
搭建环境模拟生产
1.安装软件，模拟控制使用内存占用：
yum install epel-release -y
[root@node_31 yum.repos.d]# yum install epel-release -y
已加载插件：fastestmirror
Loading mirror speeds from cached hostfile
正在解决依赖关系
--> 正在检查事务
---> 软件包 epel-release.noarch.0.7-11 将被 安装
--> 解决依赖关系完成
依赖关系解决
=========================================================================================================================================================================================================
Package 架构 版本 源 大小
=========================================================================================================================================================================================================
正在安装:
epel-release noarch 7-11 extras 15 k
事务概要
=========================================================================================================================================================================================================
安装 1 软件包
总下载量：15 k
安装大小：24 k
Downloading packages:
epel-release-7-11.noarch.rpm | 15 kB 00:00:10
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
正在安装 : epel-release-7-11.noarch 1/1
验证中 : epel-release-7-11.noarch 1/1
已安装:
epel-release.noarch 0:7-11
完毕！
yum install stress-ng -y
[root@node_31 yum.repos.d]# yum install stress-ng -y
已加载插件：fastestmirror
Loading mirror speeds from cached hostfile
epel/aarch64/metalink | 4.0 kB 00:00:00
* epel: d2lzkl7pfhq30w.cloudfront.net
base | 3.6 kB 00:00:00
epel | 5.4 kB 00:00:00
extras | 2.9 kB 00:00:00
updates | 2.9 kB 00:00:00
(1/3): epel/aarch64/updateinfo | 1.0 MB 00:00:09
(2/3): epel/aarch64/group_gz | 88 kB 00:00:20
(3/3): epel/aarch64/primary_db | 6.6 MB 00:01:22
正在解决依赖关系
--> 正在检查事务
---> 软件包 stress-ng.aarch64.0.0.07.29-2.el7 将被 安装
--> 正在处理依赖关系 libbsd.so.0(LIBBSD_0.0)(64bit)，它被软件包 stress-ng-0.07.29-2.el7.aarch64 需要
--> 正在处理依赖关系 libbsd.so.0(LIBBSD_0.3)(64bit)，它被软件包 stress-ng-0.07.29-2.el7.aarch64 需要
--> 正在处理依赖关系 libbsd.so.0(LIBBSD_0.5)(64bit)，它被软件包 stress-ng-0.07.29-2.el7.aarch64 需要
--> 正在处理依赖关系 libsctp.so.1(VERS_1)(64bit)，它被软件包 stress-ng-0.07.29-2.el7.aarch64 需要
--> 正在处理依赖关系 libbsd.so.0()(64bit)，它被软件包 stress-ng-0.07.29-2.el7.aarch64 需要
--> 正在处理依赖关系 libsctp.so.1()(64bit)，它被软件包 stress-ng-0.07.29-2.el7.aarch64 需要
--> 正在检查事务
---> 软件包 libbsd.aarch64.0.0.8.3-1.el7 将被 安装
---> 软件包 lksctp-tools.aarch64.0.1.0.17-2.el7 将被 安装
--> 解决依赖关系完成
依赖关系解决
=========================================================================================================================================================================================================
Package 架构 版本 源 大小
=========================================================================================================================================================================================================
正在安装:
stress-ng aarch64 0.07.29-2.el7 epel 255 k
为依赖而安装:
libbsd aarch64 0.8.3-1.el7 epel 85 k
lksctp-tools aarch64 1.0.17-2.el7 base 87 k
事务概要
=========================================================================================================================================================================================================
安装 1 软件包 (+2 依赖软件包)
总下载量：427 k
安装大小：1.5 M
Downloading packages:
(1/3): lksctp-tools-1.0.17-2.el7.aarch64.rpm | 87 kB 00:00:05
警告：/var/cache/yum/aarch64/7/epel/packages/stress-ng-0.07.29-2.el7.aarch64.rpm: 头V3 RSA/SHA256 Signature, 密钥 ID 352c64e5: NOKEY=================- ] 41 kB/s | 329 kB 00:00:02 ETA
stress-ng-0.07.29-2.el7.aarch64.rpm 的公钥尚未安装
(2/3): stress-ng-0.07.29-2.el7.aarch64.rpm | 255 kB 00:00:10
(3/3): libbsd-0.8.3-1.el7.aarch64.rpm | 85 kB 00:00:24
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
总计 18 kB/s | 427 kB 00:00:24
从 file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 检索密钥
导入 GPG key 0x352C64E5:
用户ID : "Fedora EPEL (7) <epel@fedoraproject.org>"
指纹 : 91e9 7d7c 4a5e 96f1 7f3e 888f 6a2f aea2 352c 64e5
软件包 : epel-release-7-11.noarch (@extras)
来自 : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
正在安装 : lksctp-tools-1.0.17-2.el7.aarch64 1/3
正在安装 : libbsd-0.8.3-1.el7.aarch64 2/3
正在安装 : stress-ng-0.07.29-2.el7.aarch64 3/3
验证中 : libbsd-0.8.3-1.el7.aarch64 1/3
验证中 : lksctp-tools-1.0.17-2.el7.aarch64 2/3
验证中 : stress-ng-0.07.29-2.el7.aarch64 3/3
已安装:
stress-ng.aarch64 0:0.07.29-2.el7
作为依赖被安装:
libbsd.aarch64 0:0.8.3-1.el7 lksctp-tools.aarch64 0:1.0.17-2.el7
完毕！
2.启动数据库
[postgres@node_31 ~]$ pg_ctl stop
waiting for server to shut down.... done
server stopped
[postgres@node_31 ~]$ pg_ctl start
waiting for server to start....2025-06-10 18:35:27.438 CST [3081] LOG: redirecting log output to logging collector process
2025-06-10 18:35:27.438 CST [3081] HINT: Future log output will appear in directory "../pg_log".
done
server started
3.把数据库的进程都冻结
[root@node_31 ~]# pgrep -u postgres | xargs -n1 kill -STOP
4.打开内存占用
[root@node_31 yum.repos.d]# stress-ng --vm 4 --vm-bytes 99% --timeout 6000s
stress-ng: info: [3292] dispatching hogs: 4 vm
5.解除冻结
[root@node_31 ~]# pgrep -u postgres | xargs -n1 kill -CONT
6.pg进程到swap里了
1090 10.5M
1093 9.00781M
706 8.16797M
863 7.36328M
3089 5.36328M
3087 5.22656M
3084 5.14062M
3086 5.12891M
3085 5.12109M
3081 5.10156M
[root@node_31 ~]# ps -ef|grep 3089
postgres 3089 3081 0 18:35 ? 00:00:00 postgres: logical replication launcher
root 3518 1814 0 18:38 pts/1 00:00:00 grep --color=auto 3089
7.此时swapoff -a
（前提是必须要保证内存空闲空间是够给swap挪过来的）
sync
echo 3 > /proc/sys/vm/drop_caches（这一步执行的话，对pg进程的影响，未测试）
再swapoff -a
物理空间不够放swap的情况下，要先腾出物理内存空间,给后面swapoff。
观察数据库查询
select * from my_table;
\watch 1
观察数据库一直正常的，不会出现进程挂掉。
往往在生产环境中，刷内存这一步操作的进展会非常之慢。
有方法是新建新的swap空间，关掉原先的，启用这个新的swap。（未验证）
8.swap腾出来了
可以再次swapon -a 打开。
ps：
如果实在swapoff太慢：尝试：
sudo ionice -c1 -n0 swapoff -a
sudo nice -n -10 ionice -c1 -n0 swapoff -a # 若 CPU 竞争严重，再叠加.
总结
设置vm.swappiness=1（尽量不使用swap），pg库的操作系统（红帽、centos系，国产操作系统要具体实验观察）建议设置一定的swap，防止偶然大访问导致OOM，但是尽量不使用swap空间。经验表明，这个设置不一定有效，经常还是会有pg的主要进程跑到swap里面，还是要定期手动处理swap大占用的情况。
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
