postgres OOM相关问题

最新推荐文章于 2024-08-27 15:49:30 发布
最新推荐文章于 2024-08-27 15:49:30 发布
阅读量428 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： postgres
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/yibei8811/article/details/46430005
在尝试调整 PostgreSQL 的 work_mem 至8GB以处理大量复制数据时遇到问题，连续多次失败并触发了 Linux 的 OOM 保护机制。理论上，设置为8GB应该能够分配足够的内存给15个表，但实际操作中出现了问题。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

测试一组copy数据

数据量比较大，调整work_mem为8G连续失败多次。查找原因log报出如下错误。





less -MN messages


想必是触发linux的OOM机制，具体触发条件测试，一会做SQL explain分析

大意上work_mem 8G理论上可以申请到8G*15 个表（120G）内存，虽然你可能并未使用，但是却触发了linux 内核安全机制。



【0065】 PostgreSQL日志报错提示：OOM Killer
Postgres 数据库内核开发工程师
11-01 378
文章目录1. 问题描述2. 解决方案 1. 问题描述 服务器设备上面运行这的PostgreSQL数据库收到日志报错提示信息： Out of memory: Kill process 2671(postmaster) score 890 or sacrifice child Killed process 2671, UID 31,(postmaster) total-vm: 24384689 kB, anon-rss:14376290kB, file-rss:138623kB 2. 解决方案 当没有足够的内
postgres执行计划 seqscan,indexscan,bitmapscan实验性分析
热门推荐
yibei8811的专栏
06-16 1万+
执行以下代码create table t1(c1 int4); insert into t1 select generate_series(1,10); explain analyze select * from t1 where c1 =4 显示为 "Seq Scan on t1 (cost=0.00..40.00 rows=12 width=4) (actual time=0.007.
PostgreSQL OOM最佳实践
Focus on PostgreSQL
07-21 5583
OOM是Linux中一个比较常见的情况，PostgreSQL数据库触发OOM现象就是数据库进程被KILL了。OOM发生的原因有很多，这里我们从OOM的产生以及如何在PostgreSQL中预防OOM发生来进行研究。 OOM介绍 什么是OOM？ OOM（out-of-memory），顾名思义就是内存溢出了，之所以会出现这种情况和内存分配的overcommit有关。 Linux为了保证在有限的内存中尽可能多的运行更多的进程，在内存分配策略中提出了overcommit的策略，即允许内存溢出。之所以可以这么做是因为我
postgres 引起oom问题的 explain 分析。
yibei8811的专栏
06-10 1007
work_mem设置为2G！ 一共16张表采用Merge join方式。 Sort Method: 一共使用到3种分别为 并分别统计他们的width！ Sort Method: quicksort  Memory:93，37，77，61，101，45，61，53 Sort Method: external sort  Disk: 117，125，125，117 Sort Method
【PostgreSQL】postgresql触发OOM解析
hdhdhdk的博客
03-28 920
注: 本文为云贝教育 刘峰 原创，请尊重知识产权，转发请注明出处，不接受任何抄袭、演绎和未经注明出处的转载。在一台运行着PostgreSQL数据库的Linux服务器上，如果数据库工作负载非常高，例如在短时间内执行了大量的复杂查询，或者一次性加载了很大的数据集进行处理，可能会导致数据库进程占用大量的内存。例如：1. 大规模排序操作或哈希聚合操作，这些操作会消耗参数指定的内存。2. 大量的临时表操作，这会占用参数所设定的内存区域。3. 如果进行了大规模的数据导入或索引重建，可能消耗参数设定的内存。
postgresql 发生 oom 的分析之一
一名数据库爱好者的专栏
08-21 3645
os:centos 7.4 postgresql:10.4 第一个窗口 创建表,向表中插入大量数据 $ psql psql (10.4) Type "help" for help. postgres=# create table test01(id integer, val char(1000)); CREATE TABLE postgres=# insert into test0...
如何解决 Compute 节点上的内存溢出（OOM）问题
https://risingwave.com/
08-27 800
内存溢出（Out-of-memory）是数据处理系统中常见的问题，本文将分析 OOM 的各种原因并提供有效的解决方法。
频繁GC导致OOM内存溢出的问题排查
没啥简介
08-28 2373
频繁GC导致OOM内存溢出的问题排查1.问题发现2. 导出内存dump3.用mat分析dump下载mat配置mat运行mat4. 分析5. 解决方案 1.问题发现 日志中打印如下，发现频繁GC并导致OOM [2021-08-25 15:14:33, 948] [ERROR] [] [] [DubboServerHandler-74.0.2.41:11306-thread-488]- org.apache.dubbo.rpc.filter.ExceptionFilter$ExceptionListener.o
Postgresql在ubuntu 22.04上遭遇OOM的处理方法
lusklusklusk的博客
11-23 2070
分析：物理32GB的情况下，OOM时捕获的postgresql最大所需内存居然达total-vm:37766764kB，检查发现postgresql数据库级别的内存参数设置都是合理的,并且postgresql的被OOM级别很低值为-900(-1000的话就不会被内核OOM)。SHR：SHR是share（共享）的缩写，表示进程占用的共享内存大小，共享内存就是被多个进程所共享的内存，比如动态库libc.so占用的内存就是共享内存，因为这个共享内存可能被很多不同会话使用，但是这些会话都会去调用libc.so。
PG遇到oom解决方案
HighGO
12-28 6542
postgres=# create table t1(id int,info text); CREATE TABLE postgres=# insert into t1 select generate_series(1,10000000),md5(random()::text); server closed the connection unexpectedly This probably
如何降低 postgresql 的 postgres 主进程被 oom killer 干掉的风险
一名数据库爱好者的专栏
06-20 1373
os: ubuntu 16.04 db: postgresql 9.6 前段时间碰到 postgres 主进程被 oom killer 杀掉的情况,初步研究了下. postgres 是 postgresql 的主进程,如果它被 oom killer 干掉了,那 postgresql 数据库就关闭了. 其他进程异常了就会进行 crash recovery,自动重启数据库. restart_after...
postgresql 发生 oom 的分析之二 cgroup
weixin_30596165的博客
08-24 466
os:centos 7.4 postgresql:10.4 接上一篇blog：postgresql 发生 oom 的分析之一 本 blog 使用 cgroup 控制 os 的 memory，先简单介绍下cgroups： CGroups 是一种对进程资源管理和控制的统一框架，它提供的是一种机制，而具体的策略（Policy）是通过子系统（subs...
为PostgreSQL配置work_mem
HighGO
11-16 3489
目录 环境 文档用途 详细信息 环境 系统平台：N/A 版本：9.4,9.6,10.0 文档用途 work_mem也许是Postgres中最令人困惑的参数。work_mem用于确定在某些操作期间可以使用多少内存。从表面上看，work_mem的设置似乎很简单，毕竟，work_mem只需指定将数据写入磁盘之前内部排序操作和哈希表可用的内存量。然而，如果不去配置work_mem可...
postgresql中position函数相关性能探究~
yibei8811的专栏
01-14 9213
起因：           postgresql中position函数提供，从头查找返回第一个匹配到字符串的下标。           而我需要返回从后向前查找第一个匹配到的坐标，但是postgressql并未提供相关函数，所以自己写了如下代码提供相关功能： CREATE OR REPLACE FUNCTION lastindexof(text, character) RETURNS i
mysql 实现 generate_series()
yibei8811的专栏
03-31 5305
我需要生成一个序列，postgresql的generate_series()非常方便。mysql却没有对应的函数。 检索相关资料，有篇文章引起了我的注意，老外们的思维还是很厉害的。 http://stackoverflow.com/questions/6870499/generate-series-equivalent-in-mysql 通过以上思路，改写了一下，生成了我需要的序列。
Centos7下systemctl status postgresql 命令相关研究
yibei8811的专栏
06-22 4554
postgres有源码安装，yum安装，或者下载包自己rpm，安装方法众多。 以前一台yum安装postgres的机器设置了  systemctl enable postgresql 这样postgresql就可以开机自启动了。 我测试了源码安装，并不支持这个命令。 可见，yum安装包偷偷的对systemctl命令进行了一些注册相关的操作？ 那么研究一下，执行 [root@db222
* service[postgres-exporter] action nothing (skipped due to action :nothing) * runit_service[postgres-exporter] action enable * ruby_block[restart_service] action nothing (skipped due to action :nothing) * ruby_block[restart_log_service] action nothing (skipped due to action :nothing) * ruby_block[reload_log_service] action nothing (skipped due to action :nothing) * directory[/opt/gitlab/sv/postgres-exporter] action create (up to date) * template[/opt/gitlab/sv/postgres-exporter/run] action create (up to date) * directory[/opt/gitlab/sv/postgres-exporter/log] action create (up to date) * directory[/opt/gitlab/sv/postgres-exporter/log/main] action create (up to date) * template[/opt/gitlab/sv/postgres-exporter/log/config] action create (up to date) * ruby_block[verify_chown_persisted_on_postgres-exporter] action nothing (skipped due to action :nothing) * link[/var/log/gitlab/postgres-exporter/config] action create (up to date) * template[/opt/gitlab/sv/postgres-exporter/log/run] action create (up to date) * directory[/opt/gitlab/sv/postgres-exporter/env] action create (up to date) * ruby_block[Delete unmanaged env files for postgres-exporter service] action run (skipped due to only_if) * template[/opt/gitlab/sv/postgres-exporter/check] action create (skipped due to only_if) * template[/opt/gitlab/sv/postgres-exporter/finish] action create (skipped due to only_if) * directory[/opt/gitlab/sv/postgres-exporter/control] action create (up to date) * link[/opt/gitlab/init/postgres-exporter] action create (up to date) * file[/opt/gitlab/sv/postgres-exporter/down] action nothing (skipped due to action :nothing) * directory[/opt/gitlab/service] action create (up to date) * link[/opt/gitlab/service/postgres-exporter] action create (up to date) * ruby_block[wait for postgres-exporter service socket] action run (skipped due to not_if) * file[/var/log/gitlab/postgres-exporter/current] action touch (skipped due to only_if) (up to date) * template[/var/opt/gitlab/postgres-exporter/queries.yaml] action create (up to date) * consul_service[postgres-exporter] action delete * file[/var/opt/gitlab/consul/config.d/postgres-exporter-service.json] action delete (up to date) (up to date) Recipe: gitlab::database_reindexing_disable * crond_job[database-reindexing] action delete * file[/var/opt/gitlab/crond/database-reindexing] action delete (up to date) (up to date) [2025-07-14T15:35:11+08:00] INFO: Cinc Client Run complete in 67.143192279 seconds Running handlers: [2025-07-14T15:35:11+08:00] INFO: Running report handlers Running handlers complete [2025-07-14T15:35:11+08:00] INFO: Report handlers complete Infra Phase complete, 0/821 resources updated in 01 minutes 10 seconds [2025-07-14T15:35:11+08:00] WARN: This release of Cinc Client became end of life (EOL) on May 1st 2024. Please update to a supported release to receive new features, bug fixes, and security updates. gitlab Reconfigured!
最新发布
07-15
<think>我们注意到用户提供的是GitLab配置过程中的日志片段。从日志中可以看出，最后显示的是成功完成配置，没有错误。 之前的错误日志（在用户之前的问题中）已经处理过，而这次提供的日志显示的是成功运行的部分。 具体分析： 1. 日志中运行了与postgres-exporter相关的runit_service启用操作，所有步骤都是“up to date”或“skipped”，说明已经是最新状态，无需更改。 2. 删除了consul_service中的postgres-exporter服务配置（因为可能不再需要）。 3. 删除了定时重新索引数据库的cron任务（database-reindexing）。 4. 最后显示“gitlab Reconfigured!”，表示整个配置过程成功完成。 因此，我们可以得出结论：这次`gitlab-ctl reconfigure`命令执行成功。 但是，用户可能关心的是之前失败的问题是否已经解决。从日志看，之前的错误（如数据库迁移失败）在此次日志中未出现，说明在解决了内存问题（如增加交换空间）后，重新运行配置成功。 回答重点： - 确认本次配置成功完成。 - 提醒用户之前的问题（OOM）已经通过增加交换空间等方式解决。 根据规则，我们还需要在最后提出3-5个相关问题。 注意：由于用户提供的日志是成功的，所以相关问题可以围绕成功后的验证、后续优化等。 回答结构： 1. 分析日志，指出成功完成。 2. 解释关键步骤（如postgres-exporter服务的处理、删除consul服务、删除cron任务等）。 3. 给出成功后的建议（如验证服务状态）。 4. 提出相关问题。 注意：必须用中文回答，且最后输出“§§相关问题§§”并列出3-5个问题。</think>根据提供的日志，GitLab 的 `reconfigure` 过程已**成功完成**。关键信息如下： ### 成功标志 1. **最终状态确认** ```bash Infra Phase complete, 0/821 resources updated in 01 minutes 10 seconds gitlab Reconfigured! ``` - 所有 821 个资源配置检查通过，零资源需要更新 - 总耗时 1 分 10 秒完成重配置 2. **关键组件状态** - **Postgres-Exporter 服务** ```bash runit_service[postgres-exporter] action enable (up to date) ``` 监控服务已启用且处于最新状态 - **定时任务清理** ```bash crond_job[database-reindexing] action delete (up to date) ``` 已移除数据库重索引定时任务 3. **无错误报告** ```bash Running handlers complete Report handlers complete ``` 未触发任何错误处理机制 ### 配置验证建议 ```bash # 检查核心服务状态 sudo gitlab-ctl status # 验证数据库连接 sudo gitlab-rake gitlab:db:check # 查看监控指标（Postgres-Exporter） curl http://localhost:9187/metrics ``` ### 注意事项 1. **日志末尾警告** ```bash [2025-07-14T15:35:11+08:00] WARN: This release of Cinc Client became end of life (EOL) on May 1st 2024 ``` - 需升级 Cinc Client（GitLab 的 Chef 组件）以获取安全更新 2. **初始密码安全** - 初始 root 密码仍存储在 `/etc/gitlab/initial_root_password` - 建议立即重置： ```bash sudo gitlab-rake "gitlab:password:reset[root]" ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值