归根结底，麒麟系统内存泄漏的根源通常锁定在auditd服务或mate-indicators组件。例如，audit-3.0-5.se.06版本每建立一次SSH连接就会泄漏约122字节内存，三天内能吞噬90%的物理内存。确认后直接停用auditd或升级mate-indicators补丁包，同时务必给MySQL容器添加ulimit限制。
在麒麟系统上运行软件，突然弹出“内存溢出”提示、系统卡死、SSH连接中断甚至桌面假死——这种情况并不少见。不要急于归咎于程序编写不佳，真相往往隐藏在系统底层：某个后台进程持续吞噬物理内存，直到触发OOM Killer。关键是从根源入手，揪出那个偷偷消耗内存的进程，彻底切断泄漏源头。
确认是否为auditd服务泄漏
首先打开终端，执行命令 rpm -qa | grep audit，查看返回结果中是否包含 audit-3.0-5.se.06 或更早版本。该版本在Kylin V10 SP1/SP2上存在广泛的内存泄漏缺陷——每新建一个SSH连接，就会产生约122字节无法回收的堆内存，三天后可占用90%的可用RAM。
确认后，再运行 top -b -n1 | grep auditd，观察RES列数值。如果持续高于800MB，并且随着SSH登录次数明显增长，那么基本可以确认。此时果断执行：sudo systemctl stop auditd && sudo systemctl disable auditd，停用该服务。
【注意：禁用前必须先关闭所有SSH会话，否则auditd可能因正在记录而拒绝停止】
排查mate-indicators日历组件泄漏
方法一：快速验证进程占用
在终端中运行 watch -n 1 "ps aux | grep mate_indicators | grep -v grep"，同时连续点击桌面右下角的日历图标20次。如果RES值从50MB飙升至300MB以上且不回落，则泄漏已确认。
方法二：升级修复包
下载对应架构的补丁包——ARM架构选择 mate-indicators-20150918kord0ukui58-10.p08.ky10.aarch64.rpm，X86架构选择 ...x86_64.rpm。然后执行 sudo rpm -Uvh *.rpm 进行覆盖安装。装完后必须注销当前桌面会话或重启系统，否则旧进程残留的内存不会释放。
临时规避MySQL容器内存异常
第一步：进入容器内部，执行 cat /proc/sys/fs/file-max 和 ulimit -n，对比两个数值。Kylin V10默认将 open_files_limit 设定为十亿级别，结果MySQL直接预分配海量内存结构，导致内存瞬间膨胀。
第二步：修改Docker启动参数。在 docker run 命令末尾加上 --ulimit nofile=65536:65536，强制限制文件句柄上限。这样调整后，MySQL容器内存即可回落至正常水平（300–800MB），完全无需修改MySQL配置文件。
第三步：如果已部署为systemd服务，编辑 /etc/systemd/system/mysql-container.service，在ExecStart行末添加同样的ulimit参数，然后执行 sudo systemctl daemon-reload && sudo systemctl restart mysql-container 即可生效。
