内存涨价这事做运维和数据库的朋友今年应该都深有感触。我年初接手的那个 Oracle EBS 系统,正好撞上这个节骨眼:64G 内存的应用服务器加 128G 的数据库服务器,业务一上来内存就顶到 90% 以上,有一次干脆被 OOM Killer 干掉了一个关键进程。老板的第一反应是加内存,可看到内存条报价单之后,脸色当场就变了。后来我们换了一条路:把一部分数据和临时负载搬到 NVMatrix 块存储 EBS 上,用高速持久层去分担内存的活儿。这套方案跑下来,数据库内存占用直接砍掉了将近一半,性能还稳得住。这篇文章我就把这个过程拆开讲清楚,包括思路、步骤和踩过的坑,给正在被数据库内存折磨的朋友一个参考。1. 内存去哪了先给数据库算一笔账1.1 两个服务器上的内存账单先说我接手那套 Oracle EBS 系统的实际配置。数据库服务器装的是 Oracle 19c,内存 128G。登录上去一看,SGA_TARGET 配了 60G,PGA_AGGREGATE_TARGET 配了 20G,这两块加起来 80G。剩下的 48G 里,操作系统的 page cache 要吃掉一大块,再加上后台进程、监听进程,以及连接池里常驻的几百个会话——每个会话都需要独立的排序区和 SQL 私有区,内存就这么一点一点被蚕食掉。应用服务器那边更夸张。Oracle EBS 的应用层是 WebLogic 域,里面跑着 4 个受管服务器,每个 JVM 的 -Xmx 都是 12G,四个加起来就是 48G,再加上 Metaspace、线程栈、JIT 编译缓存,64G 主机实际可用内存早就见底了。我打开 WebLogic 控制台看监控数据,每个 JVM 实例的堆使用率都稳定在 80% 左右。内存分配的大头就摆在那里:SGA 是老大,连接池和 JVM 堆排第二。想省内存,就必须从这三个方向下手。1.2 数据库为什么天生是内存怪兽数据库这么能吃内存,根本原因是它设计了多层缓冲机制来对抗磁盘延迟。拿 Oracle 来说,SGA 里有 Buffer Cache 负责缓存数据块,有 Library Cache 缓存 SQL 执行计划,还有 Result Cache 缓存查询结果。MySQL 的 InnoDB 引擎也一样,Buffer Pool 缓存数据页和索引页,默认配置甚至建议把它设到物理内存的 70%-80%。这一层层缓存的本质,都是在用内存换速度——磁盘 I/O 的延迟是内存的上万倍,数据库为了不让业务被慢盘拖死,宁可把热数据全部怼进内存。这套逻辑在“内存便宜、磁盘慢”的年代完全成立。但现在的局面变了:内存价格在涨,而 NVMe SSD 的成本在降,块存储的延迟已经被压缩到一百来微秒。原来必须靠内存扛的一部分工作,完全可以转交给底层存储去做。这时候还让数据库把半个主机的内存都押在 Buffer Cache 上,就是在花冤枉钱。1.3 能省的内存具体藏在哪我梳理过之后发现,数据库环境里可以压缩的内存主要就三块。第一块是 SGA 和 Buffer Pool。过去为了减少物理读,我们把缓存配得极大,恨不得所有热数据都驻留内存。但如果数据文件本身就放在高速块存储上,随机读延迟大幅降低,Buffer Cache 命中率的压力就小多了,此时把 SGA_TARGET 从 60G 降到 36G,业务几乎无感知。第二块是连接池与会话内存。Oracle EBS 的并发管理器会创建大量数据库会话,每个会话的 PGA 少则几 MB 多则几十 MB。五百个并发会话,光 PGA 就能吃掉好几个 G。把连接池参数调优,空闲会话及时回收,这块内存是实打实能省出来的。第三块是 JVM 堆内存。Oracle EBS 应用层本质是 Java 应用,堆配置就是内存大头。把一些大对象的中间产物——比如接口数据文件、批量导入导出的临时 Excel——挪到块存储上,让 JVM 堆里长期驻留的大对象失去存在意义,再配合 -Xms/-Xmx 合理配比,应用层能瘦身不少。这三块加起来砍一半,并不是天方夜谭。接下来要讲 NVMatrix 块存储凭什么能扛起这个任务。2. NVMatrix 块存储 EBS 的核心逻辑用高速存储换内存预算2.1 块存储和文件存储根本不是一回事很多应用开发的朋友对块存储的概念有点模糊,这里先解释清楚。块存储可以理解成一块裸设备,它没有目录、没有文件名,而是以固定大小的块为最小读写单位。数据库之所以偏爱块存储,是因为数据库自身就管理文件的物理布局——它知道文件的哪个块是索引、哪个块是表数据。直接对块设备读写,少了一层文件系统的抽象,效率自然更高。NVMatrix 块存储 EBS 就是一种云原生形态的块存储服务。它在底层用 NVMe SSD 构建存储池,通过多副本机制保证数据不丢,通过多路径和负载均衡把性能横向扩展起来。你把它挂载到服务器上,它就是一块高性能数据盘,该格式化格式化,该建文件系统建文件系统,用起来跟本地盘没有区别。2.2 NVMatrix 的性能到底什么水平我这里不吹参数,只说我实测过的感受。单块 NVMatrix EBS 卷的随机读 IOPS 可以到十万级别,时延在 100 微秒上下。这是什么概念?传统机械硬盘的随机 IOPS 大概一两百,普通 SATA SSD 几千到一万,而 NVMe 生态的块存储能到十万 IOPS,基本追平了单台服务器本地 NVMe 盘。关键是,块存储还能通过扩展卷组进一步提升性能。数据库把整个数据文件放在上面,所有 IO 都能吃到这块高速盘的红利。把性能数据放到数据库场景里看:以前为了抵消慢盘的 IO 等待,我们不得不用大 Buffer Cache 硬扛热数据;现在盘变快了,冷数据从磁盘重新读一遍,延迟也就是几百微秒,完全够用。2.3 存储变快如何传导为内存变少这里涉及一个很多人没想透的原理:数据库内存缓存和存储性能之间,存在一个跷跷板关系。以 MySQL 为例。假设一台 128G 的数据库服务器,以前把 innodb_buffer_pool_size 设成 90G,目的是让热数据尽可能留在内存。热数据可能只有 50G,为什么要设 90G?因为怕缓存命中率不够——一旦查询要读的数据页不在缓存里,就要触发磁盘 IO,而磁盘 IO 慢,查询就会卡顿。多出来的空间是拿来兜底的。现在把数据文件放到 NVMatrix 块存储上,磁盘读变快了。即使数据页不在缓存里,从盘上读出来也只要几百微秒,对大多数业务完全可接受。这时候 buffer pool 从 90G 砍到 45G 甚至更低,完全不是问题——因为“读盘”的代价变小了,不需要再用海量内存去硬扛命中率。Oracle 的 SGA 一个道理。Buffer Cache 从 40G 缩到 20G,命中率肯定下降,但得益于底层高速存储,多出来的物理读并不会引发性能灾难。这就是“内存省一半”的根本逻辑。说得再直白点:以前拿昂贵的 DRAM 当缓存,缓存的是数据页;现在底层那块 NVMe 块存储本身就是便宜的高速“缓存层”,内存自然可以退居二线。2.4 这套方案适合什么样的数据库这套思路不是所有库都能无脑照搬。我个人的经验,适合的场景有这么几类:Oracle EBS 这类典型的 OLTP 加批处理混合负载。数据库大、表多、并发高,以前靠大内存硬顶,现在让块存储分担,效果非常明显。MySQL/PostgreSQL 在线交易库。只要业务对延迟的敏感度不是极端到毫秒级以下,调小 buffer pool 完全可行。数据仓库和报表库。这类库天然就是大查询、大量扫描,块存储的高吞吐比内存缓存更有价值。向量数据库、Riak 这类 NoSQL 存储。底层存储的 IO 性能直接决定了扩容成本,块存储的快盘价值很大。反过来,如果业务是一个把延迟看得比天还大的高频交易系统,那还是老老实实堆大内存吧。存储优化再厉害,也不能完全替代内存,优化这事从来要因场景制宜。3. 实操把数据库内存砍掉一半的五个步骤3.1 存储准备与挂载第一步是把 NVMatrix 块存储准备好。在控制台创建好 EBS 卷之后,挂载到目标服务器上。Linux 环境下操作大概是这样的:# 查看块设备是否识别 lsblk # 创建分区(如果卷没有分区) fdisk /dev/vdb # 格式化为 xfs 文件系统,数据库大文件场景推荐 xfs mkfs.xfs /dev/vdb1 # 挂载到数据目录 mkdir -p /oradata mount /dev/vdb1 /oradata # 写入 fstab 保证重启后自动挂载 echo /dev/vdb1 /oradata xfs defaults 0 0 /etc/fstab这一步有几点要留意。第一,文件系统选型上,大文件、大并发场景 xfs 比 ext4 更稳,尤其遇到大表空间文件时,xfs 的表现更好。第二,挂载完成后用xfs_fsr做一次碎片整理,刚格式化完的卷把碎片清理干净,IO 性能还能再提一点。第三,多多关注 IO 调度器,确认用的是 none 或 noop 模式,而不是 cfq,后者在虚拟化场景下会白白增加延迟。3.2 把 Oracle 数据文件迁到新存储存储挂好后,就是最关键的迁移环节。Oracle EBS 的数据库文件迁到新盘,两个方案都可行。方案一,停机迁移,适合可维护窗口充裕的客户。停库之后把旧盘上的所有数据文件、控制文件、日志文件直接用cp或rsync拷贝到新盘,改好控制文件的路径,重新启动数据库。我一般用 rsync 加带宽限速,避免拷贝过程中把业务系统的其他 IO 打满:rsync -av --bwlimit200000 /old_oradata/ /oradata/方案二,在线迁移。如果窗口紧张,可以用 Oracle 的表空间移动功能,把一个个表空间的数据文件在线搬迁到新目录:-- 把 users 表空间置为只读 ALTER TABLESPACE users READ ONLY; -- 用操作系统命令把数据文件复制到新盘 -- !cp /old_oradata/users01.dbf /oradata/ -- 修改表空间数据文件路径 ALTER TABLESPACE users RENAME DATAFILE /old_oradata/users01.dbf TO /oradata/users01.dbf; -- 恢复读写 ALTER TABLESPACE users READ WRITE;迁移完之后,别急着改内存参数。先在数据库里跑几张核心业务表的大查询,验证新盘的 IO 性能没问题,再进入下一步。3.3 数据库层内存参数调整数据文件落位之后,就可以动 Oracle 的内存参数了。这套操作要在数据库维护窗口执行,改完重启实例。我当时是把 SGA_TARGET 从 60G 降到了 36G,PGA_AGGREGATE_TARGET 从 20G 降到了 12G。操作如下:ALTER SYSTEM SET SGA_TARGET36G SCOPESPFILE; ALTER SYSTEM SET PGA_AGGREGATE_TARGET12G SCOPESPFILE; SHUTDOWN IMMEDIATE; STARTUP;调这个参数时有个心得:SGA_TARGET 是动态调整的,但如果库是 RAC 环境,要记得所有节点都同步改。而且如果库里跑着非常复杂的批处理作业,PGA 不能一下砍太狠,可以先从 20G 降到 16G,让业务跑一个周期,观察是否有临时表空间膨胀或者排序落盘的告警,再决定要不要继续降到 12G。MySQL 场景的话,对应的就是 innodb_buffer_pool_size 的调整。比如之前是 90G,可以先降到 60G,观察一周,如果命中率还在 95% 以上,再降到 45G。注意改这个参数要预留足够的内存给操作系统和连接线程,不然 OOM 风险会上升。3.4 JVM 内存模型调优数据库层搞定后,回头收拾 Oracle EBS 应用服务器的 JVM 堆。WebLogic 的启动脚本里,原来的参数大概是:-Xms12g -Xmx12g -XX:MaxMetaspaceSize2048m我的调整方案是:-Xms6g -Xmx8g -XX:MaxMetaspaceSize1024m -XX:UseG1GC为什么要这样调?首先 -Xms 和 -Xmx 差距别拉太大,否则 JVM 扩容时会 STW;其次 Oracle EBS 是典型的 Java EE 应用,对象大多是朝生夕死,G1 比 ParallelOld 更适合这种场景;第三,如果有大量 Excel 文件处理(比如通过 XSSFWorkbook 做数据导入导出),不要把这些对象堆在 Java 堆里,而是把文件落到块存储上做流式处理,堆内存的压力会小很多。Metaspace 从 2G 砍到 1G,是因为 4 个受管服务器加起来,原来的元数据区明显超配了。当然,这个数字跟业务部署的应用数量直接相关,如果域里部署了大量自定义应用,元空间要适当放宽。改完之后重启受管服务器,观察一天,确保没有频繁 Full GC 再继续。3.5 数据库连接池瘦身连接池是内存消耗里最容易被忽略的一块。Oracle EBS 的并发管理器会频繁建立和释放连接,如果最大连接数设置过大,内存就会一直维持在一个高水平。如果你用的连接池是 HikariCP,建议按这个思路调:maximumPoolSize: 50 minimumIdle: 10 idleTimeout: 600000 maxLifetime: 1800000 connectionTimeout: 30000以前 maximumPoolSize 是 200,现在压到 50,配合连接的最大生命周期限制,空闲超过 10 分钟的连接会被回收。Java 线程栈默认 1MB,连接数从 200 降到 50,光线程就省出 150MB;再加上每个连接后台的网络缓冲和会话上下文,实际省得更多。Oracle 场景下如果用的是 UCP 连接池,可以通过setMaxPoolSize和setMinPoolSize控制。还有一点很多朋友会忽略:数据库端每建立一条会话,后端进程就要分配一块私有的 PGA 内存。连接数砍一半,数据库端的内存也跟着降,这个联动效应在 3.3 节的基础上还能再榨出一部分空间。3.6 监控与验证参数全部调完后,进入验证期。我的建议是用 AWR 快照加操作系统监控工具组合观察。Oracle 环境下,生成两份 AWR 报告做对比:-- 调参前和调参后各生成一份 SELECT * FROM TABLE(DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML(...));重点对比指标有三个:Buffer Cache 命中率、物理读次数、平均 IO 等待时间。命中率略有下降是可接受的,只要物理读的平均等待时间没有成倍增加,就说明新存储扛住了。主机层面,用free -h观察整体内存水位,用top看 java 和 oracle 进程的 RES 值。调参前我的环境里数据库服务器可用内存长期只剩下 4G,调完之后稳定在 40G 以上,这就是最直观的成果。数据库同步工具、运维监控脚本如果也在同一台机器上,记得把它们的资源占用也纳入观察范围。4. 常见问题与排查实录4.1 宝塔面板环境下的内存不足有不少朋友是在宝塔面板里跑数据库的,调优过程中最容易撞上的问题就是宝塔的“内存不足”提示。宝塔安装时要求至少 3700MB 内存,如果主机只有 4G,再跑一个数据库确实是极限操作。我遇到的一次情况是,宝塔面板显示内存使用率 99%,系统响应卡顿。排查后发现根本不是数据库吃内存,而是面板内置的监控服务采集频率太高,积累了大量历史数据在内存里。处理方案是在宝塔设置里降低监控周期,并清理面板缓存。还有一次是 Windows 服务器上,Antimalware Service Executable 进程占用了大量内存,那个进程是系统自带的杀毒软件组件,它在做后台全盘扫描时能轻松吃掉几个 G 内存,数据库再多优化也被它顶掉了。解决方式是设置扫描计划避开业务高峰期,并把数据库数据目录加入排除列表。这类内存问题往往不是数据库本身的锅,排查时要先把“非数据库进程”的内存占用情况摸清楚,否则你费劲调了半天,内存还是不够用。4.2 Oracle 内存泄漏排查poolmon 实战内存泄漏是数据库环境里最让人头疼的问题之一。Java 应用的内存泄漏可以通过 heap dump 分析,而 Windows 环境下驱动级的内存泄漏,我习惯用 poolmon 排查。有一次,一台跑着 Oracle 数据库的 Windows 服务器,可用内存以每小时 500MB 的速度往下掉,重启后恢复正常,过几天又复发。用 poolmon 抓池标签,发现Ntfx标签的 NonPaged Pool 占用持续增长。这个标签对应的是 NTFS 驱动相关的缓存结构。顺着这个线索查下去,发现是存储多路径软件的老版本在访问大文件时,会不断在非分页池里分配结构体却从不释放。升级多路径驱动后,内存曲线彻底平稳。这个案例说明,内存泄漏不一定在应用层,也有可能在驱动层,poolmon 这种底层工具关键时刻能救命。4.3 数据库同步工具和数据迁移的坑迁移数据文件的场景下,经常有人拿数据库同步工具来跑数据同步。Oracle 到 Oracle 的同步工具有很多,但只要涉及结构变更,同步工具的 DDL 兼容性常常掉链子。我在一次测试环境迁移时,用同步工具把 EBS 核心表数据从旧库同步到新库,结果几十张表的自增序列和触发器没同步过去,应用一启动就报主键冲突。后来学聪明了:结构对象用工具导 DDL,数据用同步工具跑,两者分开,别指望一把梭。另一个坑是,在同步过程中同步工具会建立大量数据库连接,如果这个时候连接池也调小了,两边一叠加,源库内存直接告急。建议在同步期间临时把连接池参数放宽,等同步结束后再调回优化值。4.4 XSSFWorkbook 内存溢出问题如果你的 Oracle EBS 环境里经常做 Excel 导入导出,恐怕对 XSSFWorkbook 内存溢出不陌生。它处理大 Excel 文件时会把整个工作簿加载到内存,一个几十 MB 的 Excel 能轻松把堆吃穿。我的经验是,把 Excel 处理改成 SAX 模式下的事件驱动解析:try (OPCPackage pkg OPCPackage.open(filePath)) { XSSFReader reader new XSSFReader(pkg); SharedStringsTable sst reader.getSharedStringsTable(); XMLReader parser XMLHelper.newXMLReader(); // 用 SheetHandler 逐行处理 }这套方案能把 Excel 解析的内存占用从几百 MB 压到几十 MB。再加上把临时文件放在块存储上,而不是 Java 临时目录,整个应用层内存压力都会小很多。这算是我在这次优化里额外收获的一个经验。5. 写在最后的一点体会内存优化这件事,我的感受是:先算账,再动手。不要一上来就想着把参数砍多少,而是先把内存账单算清楚——到底是 SGA 吃得多,还是连接池吃得多,还是 JVM 堆吃得多。账算明白了,方案自然就出来了。NVMatrix 块存储 EBS 在这次的定位,不是简单的把数据换个地方放,而是把整个性能模型里的一块重要成本——内存缓存——从昂贵的 DRAM 上挪到了便宜且高速的持久层上。数据库还是那个数据库,业务还是那个业务,但底层的成本结构变了。根据我这几个月的操作经验,这样一个优化动作做完之后,还能顺手做两件事:一是把数据库备份策略调整一下,把备份文件也放到块存储上,省下本地盘的占用;二是给监控告警加上内存增长趋势的预测,提前发现内存泄漏的苗头。这个思路后续扩展到 MySQL、PostgreSQL 甚至新的向量数据库场景,逻辑都是相通的——只要底层存储够快,内存就不必当冤大头。
