★ FEATURED ARTICLE 简介这份资源面向银河麒麟V10服务器操作系统的运维人员与系统管理员聚焦内存不释放内存泄漏这一常见性能问题提供定时排查与释放的实用方案。资源包共3个文件包含2个sh脚本与1个txt说明文档压缩包仅2KB轻量易部署其中脚本可用于定时检测与释放内存说明文档则交代配置方法与使用要点。内容围绕内存监控、泄漏定位、日志分析、参数调优及服务重启等思路展开帮助读者在不影响业务的前提下逐步排查问题提升系统维护效率。目前已有781人学习下载适合需要快速落地内存治理方案、减少人工巡检成本的运维人员参考使用。1. 银河麒麟V10内存不释放一个让运维半夜爬起来的坑凌晨两点收到告警某台跑着银河麒麟V10的生产服务器内存使用率冲到 95%SSH 勉强能连上但敲个ls都要等三秒。第一反应是哪个进程内存泄漏了结果top一看排前面的进程 RSS 加起来还不到物理内存的一半。free -h却显示 available 只剩几百兆buff/cache 高得离谱。这种“内存不释放”的故障在银河麒麟V10上不算罕见尤其是长期运行的业务机、数据库中间件、日志采集节点。它折腾人的地方在于进程没崩、CPU 不高、磁盘也没满但系统就是越来越卡最后 OOM Killer 随机杀进程业务直接抖一下。这篇笔记面向正在被同类问题卡住的运维和开发把报错现象、根因定位、定时释放的落地脚本一次讲清楚照着命令走就能复现和解决。2. 先别急着重启内存不释放的三种典型现象与根因2.1 free 显示 available 很低但进程 RSS 正常这是最容易误判的一种。你登录上去执行free -h看到类似输出total used free shared buff/cache available Mem: 62Gi 18Gi 1.2Gi 356Mi 43Gi 40Gi Swap: 8.0Gi 512Mi 7.5Gi注意available其实还有 40Gi这种情况不是故障。Linux 会把空闲内存拿去做页缓存buff/cache需要时自动回收。真正要警惕的是available低于总内存 10%同时buff/cache居高不下且不下降。判断标准很简单连续观察 5 分钟如果available持续走低、buff/cache只增不减才进入下一步排查。常见做法是先用vmstat看回收行为vmstat 1 10重点看si、so两列。如果si/so长期为 0说明系统还没开始换页问题可能出在 slab 或者被某类内核对象占住如果si/so频繁非零说明物理内存真的不够已经在拿 Swap 硬撑。2.2 slab 占用异常内核对象没释放银河麒麟V10基于较新的内核slab分配器管理内核对象。某些驱动或文件系统模块在长期运行后会出现 slab 只增不减。执行slabtop -o | head -20如果看到dentry、inode_cache、kmalloc-*某一项占了几个 G基本可以锁定是内核缓存没回收。这类问题的根因通常是某个目录下有海量小文件被反复扫描dentry 缓存无法释放或者某个内核模块存在引用计数泄漏。解决方向不是重启而是先手动触发回收sync echo 3 /proc/sys/vm/drop_cachessync先把脏页刷盘避免丢数据echo 3表示同时回收 pagecache、dentries 和 inodes。执行后再看free -h如果 available 明显回升说明是缓存类占用可以纳入定时任务处理。注意drop_caches是即时操作生产环境执行前确认业务低峰虽然它本身安全但回收瞬间大量 IO 可能造成短时抖动。2.3 透明大页与内存碎片导致释放失败还有一种更隐蔽的情况free显示 free 内存不少但申请大块连续内存失败或者drop_caches执行后 available 几乎没变化。这往往和透明大页THP以及内存碎片有关。检查cat /sys/kernel/mm/transparent_hugepage/enabled cat /proc/buddyinfo如果 THP 是[always]且buddyinfo里高阶块order 8 以上几乎为 0说明内存碎片严重内核无法合并出连续大页导致部分内存“看着空闲却用不上”。对于数据库类应用常见做法是把 THP 调成madvise或neverecho madvise /sys/kernel/mm/transparent_hugepage/enabled这个设置重启会失效需要写进开机脚本或 systemd 服务。改完后配合定时drop_caches多数“内存不释放”的假象会消失。3. 定时释放怎么做从 crontab 到 systemd timer 的落地脚本3.1 用 crontab 写一个带日志的释放脚本最直接的方式是写一个 shell 脚本由 cron 定时触发。脚本不能只写echo 3 drop_caches那样出问题你连什么时候执行的都不知道。我一般会加上时间戳、执行前后内存快照和阈值判断#!/bin/bash # /usr/local/sbin/mem_release.sh # 银河麒麟V10 定时内存回收脚本 LOG/var/log/mem_release.log THRESHOLD15 # available 低于总内存 15% 才触发 TOTAL$(free -m | awk /Mem:/{print $2}) AVAIL$(free -m | awk /Mem:/{print $7}) PERCENT$((AVAIL * 100 / TOTAL)) echo $(date %F %T) total${TOTAL}M avail${AVAIL}M percent${PERCENT}% $LOG if [ $PERCENT -lt $THRESHOLD ]; then sync echo 3 /proc/sys/vm/drop_caches echo $(date %F %T) triggered drop_caches $LOG free -m $LOG fi逻辑说明free -m取 MB 为单位第 7 列是 availableTHRESHOLD15表示只有可用内存低于 15% 才动手避免无脑回收影响性能。sync保证脏页落盘drop_caches释放缓存。日志里记录触发前后的内存状态方便回溯。给脚本加执行权限chmod x /usr/local/sbin/mem_release.sh然后加入 crontab每 30 分钟检查一次crontab -e写入*/30 * * * * /usr/local/sbin/mem_release.sh参数怎么改如果业务对延迟敏感可以把阈值调到 10如果机器内存大、缓存命中率高调到 20 更积极。日志文件记得配 logrotate否则一年下来能撑满/var。3.2 systemd timer 替代 cron 的写法银河麒麟V10默认支持 systemd用 timer 比 cron 更好管理依赖和日志。先建 service# /etc/systemd/system/mem-release.service [Unit] DescriptionMemory release task for Kylin V10 Afternetwork.target [Service] Typeoneshot ExecStart/usr/local/sbin/mem_release.sh再建 timer# /etc/systemd/system/mem-release.timer [Unit] DescriptionRun memory release every 30 minutes [Timer] OnBootSec10min OnUnitActiveSec30min Unitmem-release.service [Install] WantedBytimers.target启用并启动systemctl daemon-reload systemctl enable --now mem-release.timer systemctl list-timers | grep mem-releaseOnBootSec10min表示开机 10 分钟后首次执行避开启动高峰OnUnitActiveSec30min是间隔。用journalctl -u mem-release.service看每次执行输出比翻日志文件更集中。两种方式选哪个临时救急用 cron长期规范运维用 timer。3.3 释放后仍不下降怎么办检查泄漏进程如果脚本按时执行、日志显示drop_caches也写了但 available 还是往下掉说明有进程在持续吃内存。用下面这条命令按 RSS 排序找嫌疑ps -eo pid,ppid,comm,rss --sort-rss | head -15找到可疑 PID 后观察它的 RSS 是否随时间单调递增pidstat -r -p PID 5 12pidstat每 5 秒采样一次共 12 次看RSS和%MEM列。如果持续上涨不回落基本是应用层内存泄漏定时drop_caches救不了得从代码或配置入手。常见做法是给该服务加MemoryMax限制systemd或配 OOM 优先级先保住整机再排应用。4. 避坑记录定时释放内存时最容易翻车的五件事4.1 无阈值无脑 drop_caches 导致业务抖动现象脚本每 5 分钟执行一次echo 3业务方反馈接口 P99 延迟周期性升高。原因频繁回收 pagecache热点文件每次都要重新从磁盘读IO 压力陡增。解决加 available 百分比阈值只在低于 15% 时触发并把间隔拉到 30 分钟以上。4.2 忘记 sync 导致脏页丢失现象某次释放后数据库报文件损坏。原因脚本直接写drop_caches没有先sync部分脏页还在内存就被丢弃。解决任何drop_caches前必须sync这是血泪经验别省这一行。4.3 THP 没关drop_caches 后 available 几乎不变现象执行脚本后free的 available 只涨了几百兆和 buff/cache 下降量对不上。原因透明大页占用的内存不计入常规缓存回收路径。解决把 THP 设为madvise并写进/etc/rc.local或 systemd unit重启后确认cat /sys/kernel/mm/transparent_hugepage/enabled生效。4.4 日志文件把 /var 撑满现象运行三个月后/var/log/mem_release.log超过 10G系统盘告警。原因脚本每次执行都追加free -m输出没有轮转。解决配 logrotate/var/log/mem_release.log { weekly rotate 4 compress missingok notifempty }4.5 在容器里执行宿主机命令无效现象在 Docker 容器内跑脚本提示/proc/sys/vm/drop_caches只读。原因容器默认没有权限修改宿主机内核参数。解决释放操作必须在宿主机执行容器内只做监控和告警。如果业务跑在容器里把脚本放到宿主机 cron通过docker stats或 cgroup 指标判断是否触发。5. 快速定位内存不释放一套五分钟排查路径遇到告警别慌按下面顺序走五分钟内能判断是缓存假象、内核占用还是真泄漏。第一步看全局free -h cat /proc/meminfo | grep -E MemAvailable|Cached|Slab|SReclaimableMemAvailable是内核估算的可用内存比free列更准。如果它还有总内存 20% 以上先不用动手。第二步看缓存构成slabtop -o | head -15SReclaimable高说明可回收SUnreclaim高说明不可回收后者要警惕内核模块问题。第三步看回收行为vmstat 1 5si/so非零说明在换页物理内存真紧张全零但 available 低回到 slab 和 THP。第四步看进程ps -eo pid,comm,rss --sort-rss | head -10RSS 总和远小于 used问题在内核侧接近 used问题在应用侧。第五步验证释放sync echo 3 /proc/sys/vm/drop_caches free -havailable 明显回升纳入定时任务不回升查 THP 和泄漏进程。现象优先检查常用命令available 低但 buff/cache 高是否缓存假象free -h、/proc/meminfoslab 某项占几个 G内核对象泄漏slabtop -odrop_caches 后无变化THP / 碎片cat /sys/kernel/mm/transparent_hugepage/enabled某进程 RSS 单调涨应用内存泄漏pidstat -r -p PID 5 12容器内执行失败权限隔离宿主机执行从那以后我每次上架银河麒麟V10的机器都会先把 THP 调好、把带阈值的释放脚本和 logrotate 一起配进去再挂上 available 低于 10% 的告警。这套习惯帮我省掉了至少三次半夜爬起来重启的折腾。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
