★ FEATURED ARTICLE 接手 GaussDB 之后我翻了不少文档也踩过不少坑。说实话GaussDB 的内存参数设置是我见过最容易让 DBA 纠结的地方参数名字看起来都认识真到了要调的时候又不知道从哪个下手。这篇文章我就把自己在 GaussDB 重要内存参数设置上的一些实际经验和思考整理出来内容以集中式和主备形态的 GaussDB 为主核心参数在不同版本之间基本一致。如果你正准备给 GaussDB 做内存调优或者已经被内存问题折磨得够呛这篇文章应该能帮你少走一些弯路。我始终觉得内存参数设置不是一锤子买卖不是把某个参数调大、重启数据库就完事。它更像一场预算分配机器物理内存是固定的总预算数据库各个模块都在抢这笔钱怎么分配、怎么留余量、怎么防止某一个模块失控才是关键。所以这篇文章不会只丢给你一堆推荐值而是先把 GaussDB 的内存体系讲清楚再拆解核心参数背后的取舍逻辑最后给出可落地的设置流程和排查方法。1. 先搞懂 GaussDB 的内存全景参数再多别乱了体系GaussDB 的内存参数虽然多但它们服务的对象是固定的几个内存池。比如 shared_buffers 管数据页缓存cstore_buffers 管列存数据缓存work_mem 管查询执行期间的临时内存max_process_memory 给整个数据库进程画一条总的内存红线。如果你不清楚这些内存池之间的关系改参数就容易变成盲人摸象今天调大这个明天又调大那个最后内存冲突了都不知道问题出在哪。1.1 先搞清楚内存到底给谁用我习惯把一个 GaussDB 实例的内存看成一个公司的办公区域。shared_buffers 是公司的公用资料室大家要读的数据都先放这里不用每次跑到外面磁盘仓库去搬。work_mem 是每个员工工位上临时放文件的地方你正在处理的排序、哈希连接这些中间结果就摊在这里。maintenance_work_mem 是保洁人员用的工具间VACUUM、CREATE INDEX 这类维护操作推进时需要一些空间。而 max_process_memory是整个办公区域能租用的总面积总面积就这么多各部门怎么分就是这个参数体系需要回答的问题。这样类比下来你应该能理解为什么单纯把某一个参数调大往往没有用。你把资料室扩大员工工位就变小你把员工工位扩大到每人 2GB那 100 个并发连接就是 200GB总面积怎么可能装得下。所以看 GaussDB 内存问题一定要有全局视角。1.2 先看内存去哪儿了再动手调我会反复强调一个原则没有诊断就没有调优。改任何参数之前先搞清楚当前内存的使用分布。GaussDB 提供了内存视图我每次排查问题时第一个查的就是gs_total_memory_detail。SELECT * FROM gs_total_memory_detail;这个视图会列出 GaussDB 把物理内存分到了哪些区域比如共享内存、会话内存、上下文内存等。如果你看到某个区域的内存一直在涨那就说明问题大概率出在这边而不是上来就把 shared_buffers 调大。想进一步定位某个会话的内存占用可以查会话级别的内存上下文SELECT contextname, SUM(totalsize) AS total_size FROM gs_session_memory_context GROUP BY contextname ORDER BY total_size DESC;操作系统的内存监控也不能缺。我一般会用top和ps看进程的 RES 和共享内存变化观察趋势比观察瞬时值更有价值。如果进程 RES 持续上涨、回不到基线那就要小心了。先花十分钟看看内存分布再决定动哪个参数这个习惯能让你的调优方向靠谱很多。2. 核心内存参数逐个拆解每个参数背后的取舍逻辑下面这部分我把 GaussDB 日常配置里最常碰到的几个内存参数逐一拆开讲。不只是告诉你推荐值更重要的是让你明白每个参数调大调小背后的收益和风险。2.1 max_process_memory给数据库进程画一条总红线这个参数是 GaussDB 内存设置里的“总闸”。它限制了整个数据库实例所有进程可使用的最大内存。我见过不少环境的这个值用的是默认配置一旦业务并发一上来数据库进程内存就顶到天花板新的查询开始报内存不足。设置这个参数时最常见的两个极端是调太大操作系统整体内存被数据库吃光整台机器进入 swap 甚至触发系统层面的保护机制调太小数据库自己饿肚子高并发时查询频繁失败。我对这个参数的建议是结合物理机实际内存和机子上其他进程的占用情况来定。比如一台 64GB 内存的机器操作系统和基础监控服务大概需要 8GB 到 12GB如果这台机器上还跑着其他应用或数据库实例还要把它们的预算剔除。如果这台机器是 GaussDB 独占的那么 max_process_memory 设置在物理内存的 70% 到 80% 之间是一个比较稳的区间。这个参数修改后通常需要重启生效因为它属于 postmaster 级别的配置。注意max_process_memory 不是设得越大越好。数据库再重要也不能把整台机器的内存全拿走否则操作系统本身出现内存压力时数据库进程很容易被连带影响。2.2 shared_buffers数据页缓存的绝对主力shared_buffers 是 GaussDB 用来缓存表数据和索引数据页的共享内存区域。这个参数对读多写少的业务影响非常直接缓存命中率高磁盘 IO 就少查询延迟就稳。如果缓存命中率低再快的 CPU 也扛不住磁盘 IO 带来的延迟。GaussDB 的 shared_buffers 默认值偏保守生产环境一般都要调大。我的经验是它是物理内存的 15% 到 25% 是一个合理区间具体取决于可用内存和业务类型。比如 32GB 的内存shared_buffers 可以给到 6GB 左右。但我特别想提醒一点shared_buffers 不是越大越好。第一GaussDB 的 buffer 管理本身有额外开销区域过大管理成本会上升。第二操作系统本身也有 page cache数据库读数据时先查 shared_buffersmiss 了再从操作系统 page cache 读最后才落到磁盘。两层缓存要配合而不是完全替代。把 shared_buffers 调到物理内存的 60%你会看到它不仅没有提升性能反而因为过度占用内存让 work_mem 等执行内存捉襟见肘。我通常用下面的 SQL 来观察缓存命中率判断 shared_buffers 是否够用SELECT sum(blks_read) AS disk_reads, sum(blks_hit) AS buffer_hits, sum(blks_hit)::float / NULLIF((sum(blks_hit) sum(blks_read)), 0)::float AS hit_ratio FROM pg_stat_database;如果命中率长期低于 95%排除 SQL 本身的全表扫描问题后就应该考虑适当调大 shared_buffers。2.3 cstore_buffers列存查询的专属缓存cstore_buffers 是 GaussDB 为列存表准备的缓存区域。如果你的业务里有分析型查询用到了列存表这个参数就不能忽略。列存数据的读取模式跟行存差别很大它压缩比高、扫描数据量大对缓存的需求也更特殊。在很多默认配置里cstore_buffers 给得并不充裕。如果这个参数太小列存查询的磁盘 IO 会非常频繁表现为分析型 SQL 运行时间明显偏长。我遇到过一些客户row-store 查询都挺快唯独跑报表特别慢检查下来就是 cstore_buffers 明显不足。cstore_buffers 的大小建议主要看两点列存表的数据量和列存查询的并发程度。如果列存表有几十 GB 到上百 GB并且经常跑大范围分析查询cstore_buffers 可以给到物理内存的 10% 到 20%。如果业务以行存事务为主列存只是偶尔用给个 1GB 到 2GB 就足够了。注意cstore_buffers 和 shared_buffers 是独立的两个区域调大 cstore_buffers 不会直接影响 shared_buffers 的命中率但两者加在一起要记入 max_process_memory 的总盘子里。2.4 work_mem 与 maintenance_work_mem查询执行和维护操作的内存work_mem 是很多人容易调过头的参数。它的作用是控制单个排序、哈希连接、聚合等操作能使用的内存上限。注意是单个操作。一个复杂查询里可能有多个排序或哈希操作如果每个操作都堆到 work_mem 的上限那一个查询吃掉的 work_mem 就是好几倍。更关键的是work_mem 是按连接并发数放大的。100 个并发连接每个连接执行一个简单的排序如果 work_mem 设置了 2GB理论上这 100 个连接就可能想用掉 200GB。虽然实际上不会每个连接都用满但这种超分配机制决定了 work_mem 不能拍脑袋调大。我见过最典型的案例某个项目组把 work_mem 从默认值调到了 2GB结果高峰时段数据库内存暴涨最后触发 OOM。查询虽然快了数据库却崩了典型的因小失大。work_mem 的正确打开方式是“小步试探”先用一个相对保守的值比如 64MB 或 128MB然后观察排序落盘的情况。如果查询日志里频繁出现临时文件说明排序操作在往磁盘写这时再逐步调大 work_mem观察内存变化。GaussDB 有track_temp_files参数打开后可以在日志里记录临时文件的落盘情况这是判断 work_mem 是否需要调大的重要依据。maintenance_work_mem 则不一样它服务于 VACUUM、CREATE INDEX 这类维护操作。这些操作并发度通常不高但如果内存给得太小VACUUM 处理大量死元组或创建大索引时会频繁操作磁盘。所以这个参数可以给得比 work_mem 宽松。在 GaussDB 里做大表 CREATE INDEX 时给 maintenance_work_mem 足够的内存效果比调大 work_mem 明显得多。2.5 容易被忽略但会反噬内存的参数除了上面四个主角还有几个参数看起来不起眼但会在关键时刻反咬一口。第一个是 max_connections。每个数据库连接都要占用一定的进程内存和会话上下文内存。如果连接数设置得过高比如 2000但实际业务只需要 500那多出来的连接不会立刻占用大量内存但一旦有连接风暴或者会话堆积内存就会被快速拖垮。所以我建议 max_connections 不要随意设成超大值要根据实际应用连接池配置来定连接池一般也就几十到几百个连接。第二个是 temp_buffers。它控制每个会话中临时表使用的缓存大小。如果业务里频繁使用临时表可以适当调大反之保持默认就行。每个连接都会为 temp_buffers 预留这个内存所以同样不要设得过大。第三个是 log_buffer也就是事务日志缓冲区。它对内存总量的影响不算大但如果这个值设置太低日志频繁落盘也会间接拖慢事务处理性能。这个参数我一般保持默认或根据事务量微调。还有一类因素是操作系统层面的。GaussDB 对共享内存的使用依赖操作系统的共享内存上限设置。如果操作系统允许的共享内存上限低于数据库需要的值实例可能起不来或者运行中不稳定。比如 Linux 下的kernel.shmmax、kernel.shmall如果机器内存较大通常要调高这两个内核参数确保数据库能申请到足够的共享内存。具体的修改方法可以查对应操作系统版本的文档通常在/etc/sysctl.conf里配置。3. 参数设置实操从内存预算到落地验证的完整流程很多文档会直接给你一组推荐值但我觉得推荐值只是起点。真正靠谱的做法是先算清楚内存预算再按照预算分配然后通过实测验证和调整。下面这套流程是我在几个项目里反复用过的你可以直接照着走。3.1 第一步先给这台机器做内存预算我拿到一台新机器不会直接改参数而是先算账。假设一台 32GB 内存的数据库服务器操作系统和其他系统进程大概预留 4GB监控 agent、备份代理、运维跳板机之类的公共服务预留 2GB剩下约 26GB 就是 GaussDB 可以使用的总预算。这样 max_process_memory 可以定在 26GB 左右大约占物理内存的 80%。然后在这 26GB 里做细分。shared_buffers 我一般先按物理内存的 20% 估算也就是 6GB 左右。如果列存业务重cstore_buffers 给 4GB如果行存为主给 1GB。maintenance_work_mem 给 1GB 到 2GB。work_mem 保守一点从 64MB 开始。剩下的内存留给连接带来的会话内存、运行时上下文和操作系统 page cache 的余量。如果机器是 128GB 内存呢逻辑一样操作系统预留 8GB 到 12GB其他服务预留 4GB 到 8GB然后 GaussDB 拿总预算的 80% 左右。但这时候 shared_buffers 反而不会线性放大到非常大。原因我在前面说过数据库的 buffer 管理有开销操作系统 page cache 也有存在的必要。128GB 的机器shared_buffers 给到 24GB 到 32GB 就已经是很大的量级了继续调大收益会递减。省下来的内存优先保证足够的 work_mem 和并发余量。3.2 第二步了解修改参数的正确方式GaussDB 修改内存参数我常用的方式有三种。配置文件修改是最传统的方式直接改实例配置文件里对应的 GUC 参数重启后生效。ALTER SYSTEM SET方式更灵活不用手工编辑配置文件适合在线修改。会话级SET则适合临时验证只对当前会话有效不会影响其他连接。ALTER SYSTEM SET shared_buffers 8GB; ALTER SYSTEM SET work_mem 128MB;改完以后最常遇到的问题就是参数到底生没生效需不需要重启。我教你一个很实用的方法查pg_settings视图里的context字段SELECT name, setting, unit, context FROM pg_settings WHERE name IN (shared_buffers, cstore_buffers, work_mem, max_process_memory);输出里的context字段决定了参数的生效方式。如果是postmaster这个参数必须在数据库启动时就确定修改后需要重启实例如果是sighup可以在运行中重新加载配置文件生效如果是user在会话内可以随时调整。区分好这一点能避免很多修改了参数发现没生效的困惑。3.3 第三步不同硬件规格下的初始配置模板下面这组配置是我在实际项目中验证过的起点模板覆盖了从低配到高配几种常见规格。注意这只是初始值不是最终值务必结合业务实测调整。配置项2C4G4C8G8C16G16C32G32C64Gmax_process_memory3GB6GB12GB26GB52GBshared_buffers512MB1GB2GB6GB12GBcstore_buffers256MB512MB1GB2GB4GBwork_mem32MB64MB64MB64MB128MBmaintenance_work_mem512MB512MB1GB1GB2GBtemp_buffers16MB16MB32MB32MB64MBmax_connections2003005008001000细心的你应该能看出来work_mem 并没有随着总内存线性上涨。这是故意的。work_mem 的放大效应是按连接数和操作数相乘的在高并发场景下哪怕每个连接只用 128MB叠加起来也是相当可观的内存。宁可一部分排序落盘也要先保证数据库整体的稳定性。等到你通过日志观察到排序落盘真的成为瓶颈时再小幅度调高 work_mem配合监控观察几天确认内存稳定后再继续调整。3.4 第四步参数生效之后怎么验证效果修改参数不是终点验证才是。每次调整完内存参数我会做这几件事。先回到pg_settings确认新值已经生效。然后重启或 reload 后观察数据库的启动日志确认没有报内存相关错误。接下来跑一轮业务相关的压测或者等真实业务跑一段时间对比调整前后的指标。我重点看三个东西数据库内存整体使用率是否稳定shared_buffers 的缓存命中率有没有提升以及慢查询数量和延迟有没有变化。一个比较容易忽略的点是 swap。很多 DBA 只看内存使用率不看 swap。如果操作系统开始频繁使用 swap说明内存真的不够了这时候再去看哪个参数占了大头往往能发现问题。换句话说swap 是一个前兆指标看到它上涨就该警惕内存预算是否真的够用。4. 常见问题与排查技巧实录最后这部分我把自己在 GaussDB 内存问题上遇到过的典型场景整理成了问题实录每一条都是实际踩坑换来的经验。4.1 数据库进程内存持续上涨最后 OOM我第一次在一个生产环境遇到 GaussDB OOM 时第一反应是查代码、查驱动怀疑是不是连接泄漏。后来冷静下来先看内存分布才发现问题没那么玄学。当时数据库连接数接近峰值每个连接的 work_mem 设得偏大再加上几个分析型大查询同时执行每个查询内部有多次排序操作内存就被打满了。排查 OOM 问题时我建议按这条路线来先看操作系统日志里有没有 Out of Memory 的记录确认哪个进程被杀再用top看数据库进程的内存占用来确认现象然后查gs_total_memory_detail判断是共享内存区域爆了还是会话内存区域爆了。如果是会话内存爆了接下来就要看并发连接数和典型 SQL 的执行内存消耗重点排查 work_mem 相关配置。避免 OOM 的几个实用手段work_mem 保持保守max_connections 与实际并发匹配对高内存消耗的分析型任务做并发限制利用数据库的资源池机制给不同业务设置内存上限防止个别业务把整体内存吃光。落实到操作上就是给高风险业务单独设置内存资源控制参数比如资源池的mem_percent配置。4.2 明明改了参数内存却一点没变这是一个非常常见的困惑。修改了 shared_buffers查询pg_settings还是旧值或者内存占用曲线没有任何变化。我遇到过几次原因基本都是没有搞清楚参数的context。比如说 shared_buffers 和 max_process_memory它们的 context 是postmaster修改后必须重启整个数据库实例。如果你只是执行了 reload配置不会生效表现为pg_settings里还是旧值。而 work_mem 的 context 通常是user可以在会话内动态调整。还有一种可能是配置文件里参数拼写错误或者写了多个同名参数后面的覆盖了前面的。这种低级错误虽然不起眼但在高强度运维时特别容易犯。我的习惯是修改后用下面这条 SQL 统一检查一遍SELECT name, setting, unit, context, source FROM pg_settings WHERE name IN (shared_buffers, cstore_buffers, work_mem, max_process_memory, maintenance_work_mem);source字段会告诉你当前值来自配置文件、命令行参数还是会话级设置。看到default就要检查你的配置是否真的被加载了。4.3 work_mem 调大后慢查询反而变多了这个反直觉的现象背后是内存超分配的连锁反应。work_mem 调大后单个排序操作可以吃掉更多内存多个并发查询一起执行时总需求远超 max_process_memory 的限制。数据库内存不够用就开始向操作系统申请更多内存操作系统内存也不够就开始 swap。一旦进入 swap 状态所有查询都开始变慢反而比让排序少量落盘更糟糕。所以我的经验是work_mem 要调但一定要观察临时文件落盘情况再调。GaussDB 里打开track_temp_fileson然后跑一轮业务看日志里有没有临时文件记录。如果没有或者很少说明 work_mem 足够如果大量落盘说明确实需要调大。每次只调一个档位比如从 64MB 到 128MB观察一两天确认内存稳定后再继续。4.4 常见内存问题速查表问题现象排查思路处理方案OOM进程被杀查系统日志和 gs_total_memory_detail确认内存归属区域调低 work_mem限制连接数设置资源池内存上限启动失败报共享内存不足检查操作系统 kernel.shmmax、kernel.shmall 与 max_process_memory 是否匹配调高共享内存内核参数后重启系统或重新加载配置参数改了没生效查 pg_settings 的 context 和 source 字段postmaster 级别重启user 级别会话内 SET列存查询很慢确认列存表查询是否频繁走磁盘调大 cstore_buffers观察查询扫描性能缓存命中率低查 pg_stat_database 的 blks_hit 比例适当调大 shared_buffers 或优化 SQL 减少全表扫描swap 增长异常对比数据库整体内存趋势和 max_process_memory检查是否 work_mem 超分配调低并重启确认4.5 调整 GaussDB 内存参数的个人经验心得最后分享几个我在实际运维里总结出来的习惯不一定写在官方文档里但对排查问题很有帮助。第一每次只改一个参数。这句话看起来很简单但我见过太多人一次性把 shared_buffers、work_mem、cstore_buffers 全改了出了问题根本无法判断是哪个参数的锅。一次只改一个改完观察一段时间确认稳定再动下一个能让你快速定位问题也能减少生产环境变更风险。第二记录变更。我习惯把每次参数调整的原因、旧值、新值、调整时间、观察结论记在变更记录里。三个月后回头看这份记录能帮你找到性能问题和参数变更之间的因果关系比任何监控工具都直观。第三内存参数没有一劳永逸的配置。业务量变了、SQL 模型变了、实例规格变了都需要重新审视内存参数。每次业务大促前、年初容量规划时我都会重新做一次内存预算确认之前的分配方案是否还适用。第四别忽视操作系统层的内存参数。共享内存的内核参数如果设置不对GaussDB 实例是起不来的或者在运行中莫名其妙地报错。这是一个容易被忽略的底层前提。GaussDB 的内存参数体系说复杂也复杂毕竟参数多、层级多但说简单也简单只要你始终记得所有参数都在同一块物理内存里做预算分配很多冲突都能提前看出来。我自己的体会是内存调优不是比拼把某个参数调到多少 GB而是比拼对业务场景和参数体系的理解深度。能把预算算清楚能把每个调整的理由想明白再复杂的内存问题一步步排查总能找到方向。
阅读完成 · 觉得有帮助？
