一个SAP HANA运维的同学十有八九都被内存问题折磨过。尤其是跑在SUSE上的HANA平时好好的一到月底报表期、大批量物料账运行的时候系统内存就被打满接着SAP应用直接卡死用户电话一个接一个。这个场景太典型了我在好几个项目上都碰到过而且每次根因还都不太一样。这篇文章就把我处理过的SUSE SAP HANA内存不足问题完整梳理一遍从现象、排查、调优到长期预防全部是生产环境验证过的方案。不管你是刚接手HANA的Linux运维还是被内存告警折腾的SAP Basis这篇文章都值得你收藏。1. 先讲清楚“内存不足”到底长什么样1.1 常见故障现象与用户体感很多人一听到“系统内存不足”第一反应就是free命令看到内存满了。实际上SUSE上的SAP HANA环境报内存不足通常分好几种情况用户体感也不一样。第一种是HANA数据库直接异常退出。这种情况最严重打开SAP应用会提示“数据库连接失败”或者登录时转圈半天然后报错。我遇到过凌晨三四点HANA进程直接消失的第二天早上整个公司都炸锅了所有依赖SAP的模块全部瘫痪。打开日志一看就是内存分配失败导致进程被系统或者自身杀掉。第二种是HANA服务还活着但响应极慢。用户操作事务代码的时候界面长时间无响应最后报超时。查看系统状态HANA进程CPU不高但是内存占用接近100%Swap空间也被吃满整个服务器处于“半死”状态。这种情况最折磨人因为数据库没挂但业务已经没法用了。第三种是部分业务模块受限。比如某个特定事务代码执行时报“No more memory available for row allocation”之类的错误但登录、看主数据这些简单操作还算正常。这种一般不是系统物理内存真的没有而是HANA内存管理层面出现了问题比如内存碎片、某个会话异常占用、或者SQL执行计划爆炸。无论是哪种情况用户体感都是“SAP应用不能用”但作为运维不能只看表面得把根因定位到是物理内存耗尽、HANA内存池超额、还是某个环节分配异常这样后续的处理手段才有针对性。1.2 为什么SAP HANA对内存如此敏感SAP HANA能跑得快靠的就是“数据尽量常驻内存”。列式存储、行式存储、Delta存储、结果集缓存、SQL执行计划……几乎所有性能关键数据都放在内存里。这就意味着HANA对内存的依赖是结构性的不像传统数据库那样大部分数据在磁盘、内存只是缓存少了还能继续跑。HANA一旦内存不够用不只是慢而是会直接报错或者挂掉。我之前给一个客户做性能分析生产库HANA分配了256GB内存实际表数据加上索引占掉大约180GB按理说还有70GB左右余量。结果一次特殊的资产折旧批量任务某一两张大表被反复全表扫描、加装排序操作瞬间多申请了60GB内存再加上系统其他进程最后内存直接报警告线紧接着HANA报内存不足几十个正在跑的会话全部回滚。这种情况就是典型的“平时够用峰值不够”。还有一个让运维头疼的点Linux系统本身也有内存开销包括页缓存Page Cache、文件系统缓存、内核模块等。HANA配置的global_allocation_limit如果设置成接近物理内存上限再加上系统层面的开销就很容易触发OOM Killer。HANA又是个吃内存大户被OOM Kill的概率极高。所以处理这个问题既要看HANA自身的分配也要兼顾Linux操作系统层面的内存管理策略。2. 排查从系统到HANA一级一级往下查2.1 系统层面先看物理内存和Swap处理内存不足第一步永远是先把现场看清楚。最基础的就是free命令我一般习惯用free -m或者free -h先确认物理内存总量、已用量、可用量、Swap空间大小和利用率。free -h total used free shared buff/cache available Mem: 251G 238G 1.2G 1.8G 12G 10G Swap: 16G 14G 2.0G这种状态就很危险了。available只剩10GSwap用了14G说明内存早就吃紧了而且Swap本身也不大。很多生产环境Swap建得比较小或者干脆没有这会让问题暴露得更直接。然后看更细的系统内存分布检查/proc/meminfo重点看MemFree、MemAvailable、CommitLimit和Committed_AS。cat /proc/meminfo | grep -E MemTotal|MemFree|MemAvailable|CommitLimit|Committed_ASCommitLimit是系统当前允许的虚拟内存总量Committed_AS是所有进程已经申请的内存总量。如果看到Committed_AS已经超过CommitLimit说明系统层面内存分配已经接近极限了。这个指标很多运维会忽略但在排查内存不足时非常关键。还要看是不是有内存泄漏。用top按内存排序shift m看看哪个进程占得多。正常情况下HANA进程占大头是合理的但如果有其他进程异常吃内存比如JAVA服务、数据库备份工具、或者某个诡异的中间件也要找出来。如果发现Swap空间不足看下swap使用情况和swap设备大小。有些SLES系统默认建了Swap分区但大小没按最佳实践走。SAP官方对不同版本HANA的Swap建议比例不一样一般建议至少是物理内存的1/2很多情况下干脆不建议启用大量Swap因为HANA进程Swap出去之后性能会急剧下降。这块后面详细说。2.2 HANA层面全局分配限制与各部分内存占用系统层面看完了再用HANA自己的视角去看。HANA的内存管理有一个核心概念全局分配限制Global Allocation Limit默认值是0表示HANA可以尽可能使用系统可用内存。生产环境一般会手动配置这个值比如物理内存256GB会设置全局分配限制为230GB左右给系统预留一部分。登录HANA数据库用HANA Studio或者hdbsql查询内存使用情况SELECT * FROM M_MEMORY;这个视图非常有用里面有各个内存池的使用情况包括Total Memory、Used Memory、Row Store Memory、Column Store Memory等。如果列存储内存Column Store占用特别大就需要去定位到底是哪张表吃的内存。进一步看HANA中所有表的内存占用按大小排序SELECT SCHEMA_NAME, TABLE_NAME, ESTIMATED_MEMORY_SIZE / 1024 / 1024 AS MEM_MB FROM M_TABLES ORDER BY ESTIMATED_MEMORY_SIZE DESC LIMIT 20;如果发现某张表内存占用增长异常很可能就是问题根源。比如我曾经遇到过一个情况一张流水表数据量半年涨了3倍但由于删除策略没生效历史数据一直留在Delta区没被合并清理内存占用直线上升最终导致全局内存不足。还有一种情况是大量并发SQL导致临时内存和结果集暴涨。查询HANA活动会话和占用内存高的语句SELECT SESSION_ID, USER_NAME, STATEMENT_HASH, MEMORY_SIZE, STATUS FROM M_ACTIVE_STATEMENTS ORDER BY MEMORY_SIZE DESC LIMIT 20;在内存即将不足的时候如果是因为某条失控的SQL导致的最快的办法就是找到会话ID和业务方确认后直接断开这个会话能够快速释放内存。不过这种方法只能救急根本没有解决根本问题。2.3 不要忽略内核参数与CGroup在SUSE Linux上跑SAP HANA内核参数的作用不容忽视。常见的内核参数比如vm.max_map_count如果这个值设置过低HANA进程映射内存区域时就会报错。SAP官方建议至少设置为1000000。检查方法sysctl vm.max_map_count还有vm.overcommit_memory这个参数它决定了系统允许进程申请内存的策略。如果设置为1表示允许所有内存申请直接通过即使系统已经没内存了也不会拒绝HANA就会以为内存够用继续分配最后触发OOM。如果设置为2表示系统使用严格模式超过CommitLimit就拒绝分配。在SAP HANA环境下一般建议按官方规范设置为0或者保持默认策略并警惕Committed_AS飙升。另外现在很多SLES系统服务是通过systemd管理的如果HANA作为服务启动可能存在cgroup的内存限制。检查一下systemctl status sapinit cat /sys/fs/cgroup/memory/memory.limit_in_bytes如果在容器或者虚拟化环境下跑HANA还要看宿主机的cgroup限制是否合适。曾经有一个客户用的云主机虚拟化层默认给某个目录做了内存限制结果HANA进程一申请内存就被cgroup杀掉查了老半天才发现根因。3. 治本SUSE系统参数调优实操3.1 关闭或调整Transparent Huge PagesTHPSAP HANA官方明确建议在SLES上关闭透明大页THP尤其是对内存访问模式以大量小页为主的数据库工作负载。THP开启时系统会把小页自动合并成大页短期看减少了页表项但HANA自身的页管理策略偏向按需分配小页THP反而容易导致内存分配延迟、甚至出现大页碎片内存不足时更明显。检查当前THP状态cat /sys/kernel/mm/transparent_hugepage/enabled cat /sys/kernel/mm/transparent_hugepage/defrag输出如果显示[always] madvise never说明THP是开启状态。临时关闭可以执行echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag但这里要特别提醒临时关闭只对当前启动有效重启后就失效了。要做永久生效需要修改grub配置。编辑/etc/default/grub在GRUB_CMDLINE_LINUX中添加参数transparent_hugepagenever然后重新生成grub.cfg。不同SLES版本引导方式有差异SLES 15用GRUB2的话执行grub2-mkconfig -o /boot/grub2/grub.cfg完成后重启服务器再确认THP状态。要注意在部分较新的SLES SP版本中即使内核参数加了never方案内部的策略也可能是madvise状态最好也把/etc/sysconfig/grub里对应的参数一起检查一遍。3.2 调整内存overcommit与swappinessvm.swappiness这个参数控制系统使用Swap的倾向程度默认值一般是60表示内存压力稍大时就会开始换页。但在HANA场景下我们希望尽量避免HANA进程的内存被换到磁盘上否则数据库性能会断崖式下降而且换页本身也会占用系统资源进一步加剧内存不足。建议把swappiness调低sysctl -w vm.swappiness10要永久生效就写入sysctl配置目录比如创建/etc/sysctl.d/99-hana.conf把相关参数都放进去然后执行sysctl -p或者重启生效。再来说overcommit。在实际操作中我建议检查一下当前值以及Committed_AS的变化趋势sysctl vm.overcommit_memorySAP官方在SLES 11/12/15的配置建议中对overcommit的主流要求是保持vm.overcommit_memory0也就是默认的启发式分配模式。千万不要为了“防止HANA申请过多内存”而设置成2因为有些HANA新版本的组件和依赖库在这种模式下会出现地址空间分配失败表现为数据库启动报错或者中途异常。也不要设置成1那就是完全放开风险更高。如果你发现系统确实有进程异常申请内存可以通过HANA自身的global_allocation_limit限制而不是粗暴地改Linux内核策略。这条经验我在项目吃过亏改完overcommit2之后HANA甚至起不来日志里报Cannot allocate memory排查了半天才意识到是内核参数影响了地址空间分配。还有vm.max_map_count建议直接提到1000000sysctl -w vm.max_map_count1000000写入/etc/sysctl.d/99-hana.confHANA对内存映射区域的处理会从容很多。3.3 限制系统日志与内存型临时文件内存不足的时候系统日志和临时文件也可能添乱。比如RSYSLOG服务在内存压力大时如果日志量暴涨会产生大量内存中的buffered日志/tmp目录如果挂载为tmpfs所有写到/tmp的文件都会占用内存。很多应用会把临时文件写到/tmp尤其是SAP相关的批量任务、报表导出、接口处理过程中临时文件一多内存瞬间就满了。检查/tmp是否为tmpfsdf -h /tmp如果输出显示tmpfs而且size很大比如物理内存的一半可以考虑把应用临时目录调整到磁盘目录比如/saptmp或者直接把tmpfs的size调小减少内存占用。但要注意改成磁盘目录后要确保磁盘空间充足。另外检查/var/log所在分区有没有被写满。如果根分区满很多服务也会报内存不足相关的错误。别笑这个坑我确实踩过当时明明看到内存还有剩余但SAP应用起不来报错提示内存不足实际后台一看是/var分区满了日志写不进去导致服务异常。4. HANA侧的关键配置与内存释放手段4.1 global.ini中内存管理参数怎么配HANA的很多内存相关配置都在/usr/sap/SID/SYS/global/hdb/custom/config/global.ini里修改之前最好先备份而且修改本身需要谨慎评估不要照抄网上的配置。比较关键的一个参数是global_allocation_limit在[memorymanager]段下配置。它限制HANA数据库所有服务可分配的内存总量。比如物理内存256GB系统预留大约20-30GB给Linux和监控工具剩余220GB左右可以分给HANA那么就设置[memorymanager] global_allocation_limit 230000注意单位是MB。设置这个值的好处是防止HANA把系统内存全部吃光系统层面还能留有余量万一真的内存压力很大至少还有空间让SSH、监控等管理工具运行。如果没有这个限制HANA会尽量申请内存直到系统彻底没有可用内存那时候SSH都登录不进去只能去机房或者靠虚拟化控制台抢救。还有一个asyno_reclaim参数控制HANA内存后台异步回收的开关。有些版本默认关闭或开启状态不一致如果你发现HANA占用内存持续增长、并且大量内存处于“unused but allocated”的状态可以检查这个参数。先查当前配置SELECT * FROM M_INIFILE_CONTENTS WHERE FILE_NAME global.ini AND SECTION memorymanager;如果看到asyno_reclaim off可以在确认不会对正常业务造成影响的前提下开启让HANA能够异步回收内存。但说实话大多数情况下我并不会直接依赖这个参数还是优先排查表和SQL层面的问题。4.2 内存回收与卸载列存储数据HANA数据库有一种机制是把列存储中的数据在内存中驻留、也可以根据LRU策略从内存中暂时卸载load/unload。如果内存不足可以考虑把不常用的表或者分区设置为unload状态从内存中移除释放空间。查询当前所有表的加载状态SELECT SCHEMA_NAME, TABLE_NAME, LOADED, MEMORY_SIZE_IN_TOTAL / 1024 / 1024 AS MEM_MB FROM M_CS_TABLES WHERE LOADED TRUE ORDER BY MEMORY_SIZE_IN_TOTAL DESC LIMIT 30;对于确实不需要常驻内存的表可以使用ALTER TABLE schema_name.table_name NOT LOADED;这个操作属于“只读但不常驻内存”查询的时候HANA会按需加载虽然第一次访问会慢一些但能有效释放内存。典型场景就是一些月结后就不怎么访问的历史分区表。另外一种释放手段是手动触发内存回收。HANA提供了SQL命令ALTER SYSTEM RECLAIM MEMORY;这个命令会触发HANA内部对未使用内存的回收。还有一些情况下列存储内存碎片严重可以使用ALTER SYSTEM RECLAIM COLUMN STORAGE;不过要注意这个命令的耗时和资源消耗都不小最好在业务低峰期执行。我一般在发生内存警报告警后先查活动会话和表内存占比然后再判断是否需要手动回收而不是一上来就执行各种命令避免在内存紧张时进一步增加负担。4.3 什么时候该重启HANA什么时候该重启Linux很多运维喜欢问题一出现就重启这是大忌。但在某些场景下重启又是不得不做的最后手段。我的判断标准是这样如果HANA进程还在、SQL还能执行查询语句优先尝试在线回收和会话清理。先找出内存消耗最大的会话SELECT SESSION_ID, USER_NAME, MEMORY_SIZE, STATUS FROM M_ACTIVE_STATEMENTS ORDER BY MEMORY_SIZE DESC;如果排查到是由于异常SQL导致的和业务方沟通后可以取消相关会话或者杀掉后台作业。如果内存占用依然居高不下但是在可以接受的范围可以先观察一段时间不要急于重启。如果HANA已经拒绝执行任何查询报内存分配失败或者OOM Killer已经可能会杀掉进程这时候就别犹豫了直接重启HANA实例。在SLES上使用sapcontrol重启HANA实例sapcontrol -nr 00 -function StopSystem sapcontrol -nr 00 -function StartSystem注意启动顺序先停全部系统再启动避免状态不一致。如果OOM已经影响到操作系统稳定性比如SSH都卡得不行那就只能在控制台重启整个Linux服务器了。重启前如果条件允许把HANA的目录文件、日志目录所在磁盘空间确认一下免得重启后因为磁盘满起不来。重启这个动作是“止损”不是“治病”。重启后如果不找出根因过几天内存还会再爆。所以每次重启后我都建议第一时间收集内存使用基线数据留存日志为后续分析根因做准备。5. 日常监控与告警的落地姿势5.1 收集基线数据内存问题最难的一点是“平时看着正常高峰期就爆”。所以日常收集基线数据非常关键。我建议至少保留以下指标的时间序列物理内存总量、可用量、缓冲区/缓存量Swap总量、使用量、换进换出速率HANA各服务内存占用nameserver、indexserver、statisticsserver等HANA全局内存分配限制和当前已用量列存储占用Top20的表及其变化趋势系统OOM Killer事件记录SAP HANA自带一些视图按时间变化不好查看通常需要外部监控。写一个简单的Shell脚本配合crontab定时采集状态到文件然后用Excel或现有监控平台绘图分析。这个习惯帮我定位过好几次问题比如某张表每周末会增长2GB内存持续一个月后触发问题。如果环境里有SAP HANA Cockpit或Solution Manager能用更图形化的方式看内存趋势那就更省力。没有这些工具Linux自带的sar也可以记录内存数据前提是确认sysstat服务运行正常sar -r 5 55.2 监控脚本与告警阈值参考我常用的监控脚本思路很简单每隔几分钟检查系统可用内存和HANA内存使用率超过阈值就告警。下面是一个简化版的参考思路#!/bin/bash MEM_TOTAL$(free -m | awk /^Mem:/{print $2}) MEM_AVAILABLE$(free -m | awk /^Mem:/{print $7}) AVAIL_PERCENT$((MEM_AVAILABLE * 100 / MEM_TOTAL)) HANA_USED_MB$(su - sidadm -c hdbsql -u SYSTEM -p password -j -x SELECT TOTAL_MEMORY_USED_SIZE FROM M_MEMORY | tr -d \n) HANA_LIMIT_MB$(su - sidadm -c hdbsql -u SYSTEM -p password -j -x SELECT TOTAL_MEMORY_LIMIT_SIZE FROM M_MEMORY | tr -d \n) if [[ $AVAIL_PERCENT -lt 10 ]]; then echo System memory below 10% | mail -s ALERT: HANA memory low opsexample.com fi if [[ $HANA_USED_MB -gt $((HANA_LIMIT_MB * 90 / 100)) ]]; then echo HANA memory usage above 90% | mail -s ALERT: HANA memory high opsexample.com fi阈值方面我个人习惯是监控项预警阈值告警阈值处理动作系统可用内存比例低于20%低于10%排查Top进程检查HANA内存HANA内存使用率超过80%超过90%查Top表、活动SQL必要时释放内存Swap使用比例超过50%超过80%优先判断HANA是否被换出磁盘分区使用率/usr/sap及日志盘超过80%超过90%清理告警日志、归档告警之后最关键的是要有“数据快照”也就是出现问题那一刻的内存状态。我的做法是告警脚本里同时把free输出、Top进程、HANA的M_MEMORY关键字段、Top表列表一起写入日志文件这样事后分析时不用绞尽脑汁回忆当时发生了什么。5.3 什么时候该扩容内存膨胀到一定程度后任何调优都只是缓兵之计扩容才是终极方案。当遇到以下几种情况时就别再纠结参数怎么调了直接考虑加内存列存储表的数据量持续增长因为数据量增长带来的内存需求是刚性的。全局分配限制已经调到接近物理内存上限但业务高峰期仍然频繁触发内存不足告警。HANA的CPU等待比较高同时Swap持续有换出说明内存已经是性能瓶颈。业务方明确有新的模块或报表功能上线预计会新增一批高内存消耗的查询。扩容之前要注意服务器是否支持加内存、SAP HANA许可证是否允许在更大内存硬件上使用以及系统版本和HANA版本是否匹配新硬件。这里多提一句内存扩容后global.ini里的global_allocation_limit要同步调整否则加了等于没加。如果预算或者硬件条件限制暂时不能扩容也可以考虑对历史数据做分层存储或者把一些非核心业务切换到单独的HANA实例减少生产实例的内存压力。不过这些都是过渡方案长期看还是得扩容。6. 常见问题与踩坑记录6.1 参数配置了但不生效这是最高频的问题。明明在/etc/sysctl.d/99-hana.conf里写了vm.max_map_count1000000执行sysctl -p后也能看到新值但重启服务器后参数又变回默认了。原因多半是SLES上还有其他配置文件的优先级更高或者配置文件的文件名排序顺序问题。/etc/sysctl.d/目录下多个文件同时存在时系统按字母顺序加载后加载的同名参数会覆盖先加载的。如果一个叫99-hana.conf另一个叫98-sap.conf那执行顺序就很关键。排查方法sysctl --system systemctl status systemd-sysctl如果确认文件没问题再看是不是云平台或虚拟化层有自定义内核参数注入。我遇到过云主机每次重启平台侧的初始化脚本会按模板重建部分内核参数导致手工配置被覆盖。这种就要在平台配置策略层面修改或者用systemd的服务在启动后强制刷新参数。另外THP的修改也有类似问题。只改了/sys/kernel/mm/transparent_hugepage/enabled但没改grub重启后一定是回滚的。这个大家记住一句话凡是跟内核启动相关的优化都必须落到grub或启动脚本层面不要只做运行时修改。6.2 Swap空间配置误区有的运维觉得把Swap空间配置得特别大比如2倍物理内存就能解决内存不足。在普通Linux服务器上这个想法有一定道理但在HANA环境下完全行不通。HANA的核心设计是所有数据尽量内存化它的行存、列存、Delta区都对内存访问延迟极其敏感。一旦HANA进程被换出到Swap数据库性能会立刻下降到磁盘水平而且HANA内部可能仍然认为内存存在、不断申请更多内存导致换页风暴。换页风暴又会让系统CPU飙升最终整个服务器假死。在一次事故分析里我见过一个SLES服务器物理内存128GBSwap配置了64GB内存不足时HANA进程有将近30GB被换到Swap结果系统的CPU us却高达80%而且做任何操作都卡顿。用vmstat看si和so非常夸张明显在持续换页。所以在HANA生产环境Swap的正确用法是应急用途而不是性能缓冲。SAP官方对SLES上HANA的Swap建议历来偏保守很多专家干脆建议关闭Swap或者配置为极小的兜底值。如果业务方确实担心OOM我更倾向于把系统预留内存调大一些、设置HANA的global_allocation_limit低一些这比增大Swap更有意义。检查HANA进程是否被Swap出去可以用for pid in $(pgrep -f hdb); do grep -E VmSwap|Name /proc/$pid/status; done看到某个进程的VmSwap数值持续增大说明该进程内存被换出了。正常情况下这个值应该接近0如果长期大于几十MB就要重点排查。6.3 高水位导致的内存不释放HANA有一种特别刁钻的情况内存使用率已经降下来了但系统可用内存还是没恢复。排查了半天发现是因为HANA内部的列存储内存有一种“高水位”现象。也就是说HANA动态分配的内存不会在使用下降后马上归还给操作系统而是保留在自身的内存池里以备后续再次使用。这种情况如果业务方经常跑内存密集型的批量任务就会表现为“Run一次大任务内存就涨一截即使任务结束也不下来”。长期累积后内存逐渐见顶。处理这类问题必要时可以设置HANA的memorymanager/global_allocation_limit给HANA一个明确的天花板。同时配合监控发现内存增长异常时手动执行ALTER SYSTEM RECLAIM MEMORY;但如果发现reclaim效果不明显还可以考虑对特定的大表执行MERGE DELTA OF schema_name.table_name;把Delta区的增量数据合并进主存储区某些情况下也能有效降低内存占用。总体能不能降到原来的水平取决于数据模型和HANA版本。如果环境允许HANA升级到最新支持版本内存管理的效率会更好一些。6.4 备份和日志任务加剧内存压力最后记录一个很容易被忽略的诱因备份任务和日志归档与内存不足同时发生。HANA备份时备份进程需要扫描大量数据并生成备份目录内容在内存里做校验和和缓冲内存占用明显上升。如果备份时间正好和业务高峰期重叠内存压力会瞬间拉满。另外如果HANA的日志模式是异步提交长时间不执行日志备份日志区域会膨胀。日志增长不仅占磁盘也会影响内存。检查日志备份状态SELECT * FROM M_BACKUP_STATUS; SELECT * FROM M_VOLUMES WHERE VOLUME_ID 0;如果发现日志备份很久没跑及时手工触发一次日志备份BACKUP DATA LOG USING FILE (manual_log_backup);同时检查备份策略尽量把全量备份安排在业务低峰日志备份频率要跟业务写入量匹配。写在最后的一些经验这篇文章写的这些方案说到底都不是什么高深的技术但每一条都是我在真实生产环境中验证过的。我个人的体会是SUSE SAP HANA的内存问题最忌讳的就是“头痛医头、脚痛医脚”。今天内存爆了重启明天Swap满了又清理永远在救火永远解决不了问题。真正稳妥的做法是把操作系统层面的参数、HANA自身的分配策略、业务数据的特点这三个维度放在一起通盘考虑再用监控和告警把风险提前暴露出来。最后分享一个小技巧每次处理完一次内存故障我都会把核心现场信息归档成一个单独文件包括free输出、sysctl参数、HANA M_MEMORY结果、当时的Top表列表、以及恢复操作步骤。等下一次再遇到类似问题时直接对照之前的记录能省掉大量排查时间。这套“复盘档案”的习惯比任何监控工具都管用。
