SUSE + SAP HANA内存不足全解析：从排查到调优实战

一个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只剩10G，Swap用了14G，说明内存早就吃紧了，而且Swap本身也不大。很多生产环境Swap建得比较小，或者干脆没有，这会让问题暴露得更直接。

然后看更细的系统内存分布，检查/proc/meminfo，重点看MemFree、MemAvailable、CommitLimit和Committed_AS。

cat /proc/meminfo | grep -E "MemTotal|MemFree|MemAvailable|CommitLimit|Committed_AS"

CommitLimit是系统当前允许的虚拟内存总量，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 Pages（THP）

SAP 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_hugepage=never，然后重新生成grub.cfg。

不同SLES版本引导方式有差异，SLES 15用GRUB2的话执行：

grub2-mkconfig -o /boot/grub2/grub.cfg

完成后重启服务器再确认THP状态。要注意，在部分较新的SLES SP版本中，即使内核参数加了never，方案内部的策略也可能是madvise状态，最好也把/etc/sysconfig/grub里对应的参数一起检查一遍。

3.2 调整内存overcommit与swappiness

vm.swappiness这个参数控制系统使用Swap的倾向程度，默认值一般是60，表示内存压力稍大时就会开始换页。但在HANA场景下，我们希望尽量避免HANA进程的内存被换到磁盘上，否则数据库性能会断崖式下降，而且换页本身也会占用系统资源，进一步加剧内存不足。

建议把swappiness调低：

sysctl -w vm.swappiness=10

要永久生效就写入sysctl配置目录，比如创建/etc/sysctl.d/99-hana.conf，把相关参数都放进去，然后执行sysctl -p或者重启生效。

再来说overcommit。在实际操作中，我建议检查一下当前值，以及Committed_AS的变化趋势：

sysctl vm.overcommit_memory

SAP官方在SLES 11/12/15的配置建议中对overcommit的主流要求是保持vm.overcommit_memory=0，也就是默认的启发式分配模式。千万不要为了“防止HANA申请过多内存”而设置成2，因为有些HANA新版本的组件和依赖库在这种模式下会出现地址空间分配失败，表现为数据库启动报错或者中途异常。也不要设置成1，那就是完全放开，风险更高。

如果你发现系统确实有进程异常申请内存，可以通过HANA自身的global_allocation_limit限制，而不是粗暴地改Linux内核策略。这条经验我在项目吃过亏，改完overcommit=2之后HANA甚至起不来，日志里报Cannot allocate memory，排查了半天才意识到是内核参数影响了地址空间分配。

还有vm.max_map_count，建议直接提到1000000：

sysctl -w vm.max_map_count=1000000

写入/etc/sysctl.d/99-hana.conf，HANA对内存映射区域的处理会从容很多。

3.3 限制系统日志与内存型临时文件

内存不足的时候，系统日志和临时文件也可能添乱。比如RSYSLOG服务在内存压力大时，如果日志量暴涨，会产生大量内存中的buffered日志；/tmp目录如果挂载为tmpfs，所有写到/tmp的文件都会占用内存。很多应用会把临时文件写到/tmp，尤其是SAP相关的批量任务、报表导出、接口处理过程中，临时文件一多，内存瞬间就满了。

检查/tmp是否为tmpfs：

df -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 5

5.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 - <sid>adm -c "hdbsql -u SYSTEM -p <password> -j -x 'SELECT TOTAL_MEMORY_USED_SIZE FROM M_MEMORY'" | tr -d '\n') HANA_LIMIT_MB=$(su - <sid>adm -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" ops@example.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" ops@example.com fi

阈值方面，我个人习惯是：

告警之后最关键的是要有“数据快照”，也就是出现问题那一刻的内存状态。我的做法是告警脚本里同时把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_count=1000000，执行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服务器物理内存128GB，Swap配置了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表列表、以及恢复操作步骤。等下一次再遇到类似问题时，直接对照之前的记录，能省掉大量排查时间。这套“复盘档案”的习惯，比任何监控工具都管用。