开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,可以解决你的问题。加群请联系 liuaustin3 ,(共2720人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9)(1 2 3 4 5 6 7群均已爆满,开8群200 9群)
题目比较混乱,实际上这件事也让我认识到两点问题
1 官方的说明文档,你不能全信,官方文档说明的部分只能是一个大概或者大部分情况,你的情况是否属于这个部分,你的自行评估。
2 参数的调节,是一个漫长的过程,是不断踩坑的过程中总结的,实践是产出经验的地方
3 一些不能使用的命令,在关键时刻,必须使用,这也是我对PostgreSQL的数据库安全担心的地方。
具体案例:
最近遇到一则比较怪的问题,就是关于PostgreSQL大表添加索引,直接引起PostgreSQL crash的问题。故障的现象是,对这张2亿行表添加索引,系统会crash。




以上是当时的情况,从图中和对应日志,我们可以分析到一个问题在添加索引的情况下,且有大量的UPDATE ,在短时间内存使用率持续走高,我们看下面这张图

一开始在添加索引的时候,mem_size_cache持续走低,同时mem_size_rss持续走高。
mem_size_cache是指的操作系统缓存,这是用来缓存磁盘上的数据页的内存,随着添加内存的操作,系统开始检测到内存不足,在不断腾出更多的内存给正在运行的进程。
mem_size_rss 持续走高,RSS 是Resident set size ,这个量是指的在物理内存中实际占用的内存量。
这两个符合在添加索引中内存的消耗,在崩溃的前一刻,系统的mem_size_rss已经接近了20G 整体的内存才32G,shared buffer pool 设置为8G。
从这里分析系统崩溃的主要原因就是内存OOM,然后系统作出了 KILL -9 客户进程的操作,然后系统就开始触发了整体的进程的重启,最后系统进入了recovery_mode,整体进行recoery 的过程在2秒结束。 这说明一个问题,系统OOM 的时候操作系统KILL的是客户的添加索引的进程,而不是主进程。如果是重启一个11T的大库2秒是起不来的,尤其还是要进行recovery 的过程。
POSTGRESQL 数据库崩溃的原因搞清楚了,需要我们注意的有几个地方
1 maintenance_work_mem 的设置是否和官方说的是可以更大一点进行设置,到底应该多大,部分情况下设置的过大,会不会出现我们的问题,因为可能一次批量添加很多索引,那么每个进程都会开启使用maintenance_work_mem的模式,包含了一个添加过程中的多个子进程也都可以进行内存的单独分配,所以如果有批量干一些事情的情况下,maintenance_work_mem一定不要设置太大,否则就会和我们一样,操作系统直接发出KILL -9 的命令直接将客户的进程KILL ,而引发整体的进程的重启。
(下图为官方关于此参数的说明)
2 KILL -9 这个问题已经很明确了,在我们个人的操作中是不允许使用KILL-9 去KILL 客户或者系统的进程,这对PG来说是非常容易出现数据丢失,但是在系统层面,如果发现某个进程使用内存太多,他们会直接发起KILL -9 的工作来将这个进程杀死,好让整体系统进行工作。
这类就产生一个问题,到底要不要KILL -9 ,人工我们可以使用命令 pg_terminal_backend(PID)来操作,或者使用kill term 的方式来,但是操作系统在遇到真正的问题OOM 的情况下,是直接上来就KILL 的。所以POSTGRESQL 目前还避免不了系统级的KILL -9的发生。
总结:在POSTGRESQL 分配一些核心内存使用的时候,要注意大小和一次操作的命令的数量,INDEX 有的时候是批量添加,尤其大表容易发生参数设置不对,导致OOM的情况,同时会发生KILL -9 对相关进程的操作。
置顶
AI 祸国殃民必须铲除,AI国强民富必须支持
公众号给我两个数字 34.6万,65.5万--告别2024
云不云的,我不晕,从今天起云专栏的喇叭开始广播了。
没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛
ETL 行业也够卷,云化ETL,ETL 软件不过了
PostgreSQL 相关文章
PostgreSQL 的搅局者问世了,杀过来了!
PostgreSQL SQL优化用兵法,优化后提高 140倍速度
PostgreSQL 运维的难与“难” --上海PG大会主题记录
PostgreSQL 什么都能存,什么都能塞 --- 你能成熟一点吗?
PostgreSQL 迁移用户很简单 --- 我看你的好戏
PostgreSQL 用户胡作非为只能受着 --- 警告他
全世界都在“搞” PostgreSQL ,从Oracle 得到一个“馊主意”开始PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁
PostgreSQL “我怎么就连个数据库都不会建?” --- 你还真不会!
病毒攻击PostgreSQL暴力破解系统,防范加固系统方案(内附分析日志脚本)
PostgreSQL 远程管理越来越简单,6个自动化脚本开胃菜
PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆
PostgreSQL 如何通过工具来分析PG 内存泄露
PostgreSQL 分组查询可以不进行全表扫描吗?速度提高上千倍?
POSTGRESQL --Austindatabaes 历年文章整理
PostgreSQL 查询语句开发写不好是必然,不是PG的锅
PostgreSQL 字符集乌龙导致数据查询排序的问题,与 MySQL 稳定 "PG不稳定"
PostgreSQL Patroni 3.0 新功能规划 2023年 纽约PG 大会 (音译)
PostgreSQL 玩PG我们是认真的,vacuum 稳定性平台我们有了
PostgreSQL DBA硬扛 垃圾 “开发”,“架构师”,滥用PG 你们滚出 !(附送定期清理连接脚本)
DBA 失职导致 PostgreSQL 日志疯涨
MongoDB 相关文章
MongoDB 大俗大雅,上来问分片真三俗 -- 4 分什么分
MongoDB 大俗大雅,高端知识讲“庸俗” --3 奇葩数据更新方法
MongoDB 学习建模与设计思路--统计数据更新案例
MongoDB 大俗大雅,高端的知识讲“通俗” -- 2 嵌套和引用
MongoDB 大俗大雅,高端的知识讲“低俗” -- 1 什么叫多模
MongoDB 合作考试报销活动 贴附属,MongoDB基础知识速通
MongoDB 年底活动,免费考试名额 7个公众号获得
MongoDB 使用网上妙招,直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)
数据库 《三体》“二向箔” 思维限制 !8个公众号联合抽奖送书 建立数据库设计新思维
MongoDB 是外星人,水瓶座,怎么和不按套路出牌的他沟通?
17000多张MongoDB表的锅 自动分析删除表数据难题--从头到尾的处理过程(文尾有MongoDB开发规范)
MongoDB 插入更新数据慢,开发问哪的问题?附带解决方案和脚本
MongoDB 不是软柿子,想替换就替换
MongoDB 挑战传统数据库聚合查询,干不死他们的MongoDB 2023纽约 MongoDB 大会 -- 我们怎么做的新一代引擎 SBE Mongodb 7.0双擎力量(译)
MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模
MongoDB 双机热备那篇文章是 “毒”
MongoDB 会丢数据吗?在次补刀MongoDB 双机热备
MONGODB ---- Austindatabases 历年文章合集
MySQL相关文章
MySQL 怎么让自己更高级---从内存表说到了开发方式
MySQL timeout 参数可以让事务不完全回滚
"DBA 是个der" 吵出MySQL主键问题多种解决方案
MySQL 让你还用5.7 出事了吧,用着用着5.7崩了
MySQL 的SQL引擎很差吗?由一个同学提出问题引出的实验
用MySql不是MySQL, 不用MySQL都是MySQL 横批 哼哼哈哈啊啊
MYSQL --Austindatabases 历年文章合集
PolarDB 相关文章
PostgreSQL 的搅局者问世了,杀过来了!
在被厂商围剿的DBA 求生之路 --我是老油条
POLARDB 添加字段 “卡” 住---这锅Polar不背
PolarDB 版本差异分析--外人不知道的秘密(谁是绵羊,谁是怪兽)
在被厂商围剿的DBA 求生之路 --我是老油条
PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤,来自杭州的Package(活动结束了)
PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火星人
PolarDB-MySQL 并行技巧与内幕--(怎么薅羊毛)
PolarDB 并行黑科技--从百套MySQL撤下说起 (感谢8018个粉丝的支持)
PolarDB 杀疯了,Everywhere Everytime Everydatabase on Serverless
POLARDB 从一个使用者的角度来说说,POALRDB 怎么打败 MYSQL RDS
PolarDB 最近遇到加字段加不上的问题 与 使用PolarDB 三年感受与恳谈
PolarDB 从节点Down机后,引起的主从节点强一致的争论
PolarDB serverless 真敢搞,你出圈了你知道吗!!!!
PolarDB VS PostgreSQL "云上"性能与成本评测 -- PolarDB 比PostgreSQL 好?
临时工访谈:PolarDB Serverless 发现“大”问题了 之 灭妖记 续集
临时工访谈:庙小妖风大-PolarDB 组团镇妖 之 他们是第一
PolarDB for PostgreSQL 有意思吗?有意思呀
PolarDB Serverless POC测试中有没有坑与发现的疑问
临时工说:从人性的角度来分析为什么公司内MySQL 成为少数派,PolarDB 占领高处
POLARDB 到底打倒了谁 PPT 分享 (文字版)
POLARDB -- Ausitndatabases 历年的文章集合
PolarDB for PostgreSQL 有意思吗?有意思呀
PolarDB 搞那么多复杂磁盘计费的东西,抽筋了吗?
临时工访谈系列
Oracle 文化走后,你我只值9.9元
知人者智,自知者明,琼瑶一路走好
本地存储还有活路吗? 从上周一个供应商问我的问题开始
一年又一年,成了老梆子,别回头,往前看!
临时工说: 实际实例揭穿AI, 上云就不用DBA的谎言
临时工说:DBA 7*24H 给2万的工作,到底去不去?
国内最大IT服务公司-招聘DBA “招聘广告”的变化--分析与探讨
临时工说: 网友问35岁就淘汰,我刚入行DBA 怎么办?
OceanBase 相关文章
OceanBase 6大学习法--OB上手视频学习总结第一章
没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛
OceanBase 送祝福活动,礼物和幸运带给您
跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)
跟我学OceanBase4.0 --阅读白皮书 (4.0优化的核心点是什么)
跟我学OceanBase4.0 --阅读白皮书 (0.5-4.0的架构与之前架构特点)
跟我学OceanBase4.0 --阅读白皮书 (旧的概念害死人呀,更新知识和理念)
聚焦SaaS类企业数据库选型(技术、成本、合规、地缘政治)
OceanBase 学习记录-- 建立MySQL租户,像用MySQL一样使用OB
OceanBase 学习记录 -- 安装简易环境
OceanBase 学习记录 -- 开始入门
数据库最近第一比较多,OceanBase 定语加多了?
临时工访谈:OceanBase上海开大会,我们四个开小会 OB 国产数据库破局者
临时工说:OceanBase 到访,果然数据库的世界很卷,没边
数据库信息速递 阿里巴巴的分布式数据库OceanBase旨在进军中国以外的市场 (翻译)
SQL SERVER 系列
SQL SERVER维保AI化,从一段小故事开始
SQL SERVER 如何实现UNDO REDO 和PostgreSQL 有近亲关系吗
SQL SERVER 危险中,标题不让发,进入看详情(译)
SQL SERVER 我没有消失,SQL SERVER下一个版本是2025 (功能领先大多数数据库)
SQL SERVER 2022 针对缓存扫描和Query Store 的进步,可以考虑进行版本升级
阿里云系列
阿里云数据库产品权限设计缺陷 ,六个场景诠释问题,你可以做的更好?
阿里云数据库--市场营销聊胜于无--3年的使用感受与反馈系列
阿里云数据库产品 对内对外一样的卷 --3年阿里云数据库的使用感受与反馈系列
阿里云数据库使用感受--客户服务问题深入剖析与什么是廉价客户 --3年的使用感受与反馈系列
阿里云数据库使用感受--操作界面有点眼花缭乱 --3年的使用感受与反馈系列