在日本Softbank服务器上处理“可用内存持续下降”时，首要目标不是立即清理缓存或重启服务，而是确认这是否属于正常的文件缓存增长、交换分区压力，还是进程、容器或内核已经无法回收的真实内存占用。生产环境中的强制释放缓存、修改交换策略、重启进程，都可能造成延迟抖动、连接中断或数据风险，因此应先取证，再做低风险变更。

建议按以下顺序排查：先确认系统可用内存和趋势，再区分进程内存与缓存，随后检查Swap使用、内核回收压力和OOM日志，最后定位具体进程或服务。只有在确认原因后，才进行服务重启、限制进程内存或调整交换空间，并在变更后持续观察；如果延迟、Swap压力或OOM事件恶化，应按原配置回滚。

一、现状核对：先确认“可用内存”是否真的在减少

以下命令适用于常见Linux系统，执行前建议使用具备只读查看权限的运维账号。若服务器运行在容器或虚拟化环境中，还要注意宿主机看到的内存与容器内部统计可能不同。

1. 查看内存、缓存与Swap概况

free -h

重点关注以下字段：

• available：内核根据当前可回收页面估算出的可用内存，通常比单独看free更适合判断系统是否接近内存压力。
• used：不同版本的free计算方式可能包含缓存，不能直接等同于“进程已经占满的内存”。
• buff/cache：缓冲区和文件页缓存等内存，其中一部分可以在需要时回收。
• Swap：交换空间的总量、已用量和剩余量。

如果free很低，但available仍较充足，且Swap没有持续增长，通常更像是缓存被利用，而不是系统已经耗尽内存。反过来，如果available持续下降，同时Swap使用量不断增加、si/so持续出现，则应按真实内存压力处理。

2. 连续采样，不要只看一次结果

“持续下降”必须通过时间序列确认。可以间隔采集几次，不要在生产服务器上使用过短的间隔长期运行。

for i in $(seq 1 12); do
  date '+%F %T'
  free -m
  vmstat 1 2 | tail -1
  sleep 30
done

这段命令适合临时观察。vmstat最后一行中的：

• si表示从Swap读入内存的数据量；
• so表示从内存写入Swap的数据量；
• free是当前空闲内存；
• buff和cache反映部分内核缓冲与文件缓存；
• wa等字段还可辅助判断是否已经出现I/O等待。

如果只看到缓存增长，而available基本稳定、si/so长期为零，通常不应把“缓存占用”当作泄漏。若available逐步下降，并伴随Swap读写，说明可回收空间正在减少，需要继续定位进程和内核回收压力。

3. 检查内存统计中的可回收部分

grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SReclaimable|Shmem|SwapTotal|SwapFree|AnonPages|Unevictable):' /proc/meminfo

其中：

• Cached主要反映文件页缓存；
• SReclaimable表示部分可回收的Slab内存；
• AnonPages通常与进程匿名内存相关；
• Unevictable表示不容易被回收的内存；
• Shmem与共享内存、tmpfs等有关。

如果AnonPages持续上升，优先检查应用进程、线程、堆外内存或容器限制。如果SReclaimable异常增长，应进一步查看Slab分配；如果Shmem增长，则要检查共享内存、/dev/shm和tmpfs使用情况，而不能简单归因于普通文件缓存。

二、变更准备：在修改前保留可回滚依据

在生产环境进行任何服务重启、Swap调整或内存限制变更前，先记录当前状态。至少保存以下信息：

date
uname -a
free -h
swapon --show
ps -eo pid,ppid,user,comm,%mem,rss,vsz --sort=-rss | head -n 20
df -h
df -ih

同时确认：

• 当前是否有发布、备份、批处理或流量高峰；
• 哪些服务允许重启，哪些服务需要切换或摘流；
• 服务配置文件、systemd单元文件和容器编排文件是否已备份；
• 当前Swap设备或Swap文件的路径，避免后续操作误改其他挂载；
• 应用是否有连接池、队列、缓存预热或优雅退出机制。

若需要重启服务，应先确认服务管理方式，不要直接猜测服务名：

systemctl list-units --type=service --state=running

变更前可将关键输出保存到带时间戳的目录，但不要把可能包含敏感环境变量、令牌或业务数据的完整日志直接上传到公共位置。

三、分步定位：缓存、Swap与进程占用分别判断

1. 先判断是不是“正常缓存增长”

Linux会将空闲内存用于文件缓存，以减少磁盘访问。缓存变多本身不代表故障，关键是内核能否在应用需要内存时及时回收。

可以用以下命令查看进程层面的内存占用：

ps -eo pid,ppid,user,comm,%mem,rss,vsz,etime --sort=-rss | head -n 20

其中RSS是进程当前驻留在物理内存中的近似大小，VSZ是虚拟地址空间大小，不能用VSZ直接判断物理内存消耗。多个进程共享库文件时，各进程RSS相加也可能重复计算共享部分，因此该列表适合发现重点对象，不适合直接做精确总账。

对可疑进程进一步查看：

PID=进程号
grep -E '^(Name|VmPeak|VmSize|VmRSS|RssAnon|RssFile|RssShmem|VmSwap|Threads):' /proc/$PID/status

判断思路如下：

• RssAnon持续增长，常见于应用堆、匿名映射、线程栈或内存泄漏方向；
• RssFile较高，可能包含程序文件映射和共享库，不能直接认定为泄漏；
• RssShmem较高，应检查共享内存或tmpfs；
• VmSwap持续增加，说明该进程部分内存已经被换出，但不一定意味着它是唯一原因。

对于Java、数据库、缓存服务或带有自定义内存分配器的程序，还要结合其自身指标，例如堆使用量、连接数、缓存条目、工作队列和线程数量。操作系统RSS增长与应用内部“已分配但尚未使用”的统计不一定相同，二者需要同时观察。

2. 检查Swap是否正在放大性能问题

swapon --show --bytes
free -h
vmstat 1 5

Swap已经被使用，不一定立即代表故障。部分长期不活跃页面被换出后，系统仍可能运行正常。但以下组合需要优先处理：

• available持续下降；
• si和so反复出现；
• 应用响应时间变长；
• 磁盘I/O等待升高；
• OOM日志开始出现。

此时应先找出新增内存的进程，而不是直接执行swapoff -a。在物理内存紧张时关闭Swap，可能触发更快的回收或OOM，影响范围通常比保持现状更大。

如果需要增加Swap，只能在确认磁盘空间、文件系统、加密要求和运维规范后实施。创建Swap文件属于有风险的系统变更，必须先确认路径不是业务数据目录，并准备删除该文件和恢复原配置的回滚方案。示例仅说明操作形式，不代表所有发行版和安全策略都适用：

# 仅在已确认路径、磁盘空间和变更窗口后执行
sudo fallocate -l <大小> /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

部分文件系统不支持或不建议使用fallocate创建Swap文件，遇到报错时应先核对文件系统类型和发行版文档，不要反复覆盖执行。若要写入/etc/fstab，必须先备份文件并确认不会产生重复挂载；回滚时先执行swapoff /swapfile，再删除对应配置和文件，前提是系统仍有足够可用内存。

3. 检查进程是否在持续增长

一次ps结果只能说明当前排序，不能证明泄漏。对重点PID进行重复采样：

PID=进程号
for i in $(seq 1 10); do
  date '+%F %T'
  awk '/^(Name|VmRSS|RssAnon|RssFile|RssShmem|VmSwap|Threads):/ {print}' /proc/$PID/status
  sleep 60
done

若某进程的RssAnon、线程数或VmSwap与业务请求量无关地持续增加，应结合应用日志和运行时指标判断：

• 请求量增加、连接数增加、缓存条目增加，可能是业务负载增长；
• 请求量基本稳定但匿名内存不断上升，需排查内存泄漏、未释放对象或第三方库；
• 进程数量不断增加，可能是子进程回收失败、工作进程配置异常或任务堆积；
• 单个进程没有明显增长，但整体内存仍下降，应检查多个进程、容器、共享内存和内核内存。

不要仅凭%MEM决定重启对象。该字段受总内存和共享内存计算方式影响，最好同时记录PID、RSS、匿名内存、线程数、启动时间和业务角色。

四、定位OOM：确认系统是否已经执行过杀进程

内存不足时，Linux可能触发Out-Of-Memory Killer。OOM通常会在内核日志中留下受害进程、内存状态和评分信息。

优先使用以下命令：

journalctl -k --since "2 hours ago" | grep -iE 'oom|out of memory|killed process|memory cgroup'

也可以查看内核环形缓冲区：

dmesg -T | grep -iE 'oom|out of memory|killed process|memory cgroup'

如果权限不足、日志已轮转或系统使用其他日志方案，应根据发行版检查对应的内核日志位置。不要把“服务突然退出”直接等同于OOM，还要核对服务自身日志和systemd状态：

systemctl status <服务名> --no-pager
journalctl -u <服务名> --since "2 hours ago" --no-pager

OOM日志中的信息通常包括：

• 触发时全机内存和Swap状态；
• 被选择终止的进程；
• 进程当时的内存占用；
• 是否属于某个cgroup或容器；
• OOM评分及相关限制。

如果日志出现memory cgroup out of memory，可能是容器、服务单元或cgroup达到自身上限，即使宿主机还有可用内存，也可能终止该组内的进程。此时应检查服务的内存限制和容器配置，而不是只扩大宿主机Swap。

systemctl show <服务名> -p MemoryMax -p MemoryHigh -p OOMPolicy

容器环境还应查看容器的限制与当前用量，具体命令取决于所使用的运行时。变更内存上限前，应确认宿主机有足够余量，并评估多个服务同时争抢内存的风险。

五、按结果选择修复动作

情况一：缓存高，但可用内存稳定

此时通常不建议执行清理缓存命令。强制丢弃缓存可能增加后续磁盘读取，造成I/O抖动，而且不能解决进程匿名内存泄漏。应继续观察MemAvailable、Swap读写和业务延迟；只有出现明确回收异常并完成影响评估时，才考虑进一步处理。

情况二：单个进程匿名内存持续增长

先确认该进程是否支持优雅重载或滚动重启，并保留日志和进程采样。重启只能恢复内存水位，不能替代根因修复。变更时应：

1. 确认服务有冗余、摘流或可接受的短暂中断窗口。

2. 保存当前PID、日志时间范围和内存采样。

3. 按服务文档执行优雅重启，不要直接使用强制终止。

4. 观察新进程的RSS和业务指标是否重新出现增长。

5. 将增长曲线与发布版本、请求量和任务量关联起来。

如果重启后短时间内再次出现同样增长，应优先回滚最近的软件变更、降低触发该问题的任务量，或在应用层修复资源释放问题。

情况三：Swap持续读写并伴随响应变慢

先减少内存压力来源，例如暂停非必要批处理、降低并发或摘除异常实例。不要在内存紧张时盲目关闭Swap，也不要未经验证直接调高系统内存相关参数。若只是Swap容量不足但物理内存和磁盘条件允许，增加Swap可以作为缓冲手段，但它不能替代扩容或修复泄漏，且可能掩盖问题、延长故障暴露时间。

情况四：出现OOM或cgroup OOM

先确定被杀进程、所属服务和触发范围，再判断是全机内存不足还是单个cgroup达到上限。需要重点核对：

• 服务启动参数是否设置过高；
• 容器或systemd内存上限是否低于实际工作集；
• 同一主机是否新增了其他高占用服务；
• Swap是否可用以及是否正在发生频繁换入换出；
• OOM前是否有请求、任务或数据量突增。

提高内存限制或增加Swap前，必须确认系统整体余量和故障边界。否则，单个服务暂时不被杀，可能转化为整台日本Softbank服务器上的多个服务同时受压。

六、验证修复是否真正生效

修复后的验证不能只看free -h瞬时结果，至少要覆盖内存水位、Swap、OOM和业务服务四个方面。

free -h
vmstat 1 5
swapon --show
journalctl -k --since "变更时间" | grep -iE 'oom|out of memory|killed process|memory cgroup'
ps -eo pid,comm,%mem,rss,vsz,etime --sort=-rss | head -n 20

验证时重点观察：

• MemAvailable是否停止持续下降；
• si/so是否恢复到与业务负载相符的水平；
• Swap使用量是否继续增长；
• 可疑进程的RSS和匿名内存是否稳定；
• 是否产生新的OOM或服务重启记录；
• 应用响应时间、错误率、连接数和任务积压是否恢复；
• 重启后的进程是否因缓存预热而短暂升高，随后进入稳定区间。

观察窗口应覆盖一次正常业务高峰和主要定时任务。若无法覆盖完整业务周期，至少应明确记录当前负载条件，避免把低流量时的暂时稳定误判为问题已解决。

七、明确回滚条件，避免越改越严重

出现以下任一情况，应停止继续扩大变更，并优先恢复最近一次改动：

• si/so持续升高且业务延迟明显恶化；
• MemAvailable继续下降并接近系统回收压力状态；
• 新增OOM、服务异常退出或容器被驱逐；
• 重启后进程内存增长速度更快；
• 磁盘空间、Swap文件或I/O等待出现异常；
• 服务错误率、连接失败数或任务积压超出既定范围。

回滚前先记录异常时点和日志，避免丢失根因证据。对于服务配置、systemd限制或Swap配置，恢复备份文件后应执行配置校验，再按服务管理工具重新加载；对于已经发生的OOM，回滚只能恢复配置，不能恢复已被终止进程中的未持久化状态，因此业务数据和队列状态仍需按应用自身机制核对。

日本Softbank服务器的可用内存排查，最终要落到一条可验证的证据链：MemAvailable是否下降、缓存是否可回收、Swap是否活跃、哪个进程或cgroup占用增长、内核是否记录OOM，以及修复后这些指标是否在完整业务观察窗口内稳定。只有这条链条闭合，才能区分正常缓存利用、短时负载峰值和真正的内存泄漏或限制配置问题。