金牌6138香港服务器内存告警：64GB可用内存与缓存、交换分区如何联动排查

看到“内存使用率超过90%”或 free 只剩几 GB，并不能直接说明 64GB 物理内存已经耗尽。以常见的 Linux 输出为例，free 可能只有 1.2GiB，而 buff/cache 有 13GiB、available 仍有 11GiB；这更像是系统主动利用空闲内存做缓存，而不是应用已经无法继续分配内存。真正需要确认的是：available 是否持续下降，交换分区是否正在频繁换入换出，哪个进程的 RSS 持续增长，以及响应时间、错误率和 I/O 是否在同一时间恶化。

图示对应原文命令：available。

对 CPU：金牌 6138（20核40线程）、内存：64GB DDR4-2666、硬盘：960GB NVMe PCIE Gen4 SSD 这款香港服务器适合做什么业务，内存侧不能只看配置数字。它可以用于中等规模网站、接口服务、企业管理系统、受控并发的多服务应用，以及对本地磁盘响应有要求的业务；但能否稳定运行，取决于应用常驻内存、缓存上限、工作进程数量、批处理峰值和容器或服务组限制。排查内存告警时，应按“建立时间窗口—比较可用内存—联动交换与 I/O—定位进程—核对 OOM—修复后复测”的顺序进行。

1. 先建立正常时段与告警时段的观察窗口

不要在第一次看到告警时立即重启服务器、清空缓存或关闭交换分区。这样虽然可能暂时降低使用量，却会丢失内存增长、换页和进程退出的现场。

以下命令适用于常见 Linux 服务器，主要是读取状态。建议在告警发生时连续采样 5 至 10 分钟，并保留一个业务正常时段作为对照：

date '+%F %T %Z'
uptime
free -h
swapon --show
vmstat 1 10
ps -eo pid,ppid,comm,%mem,rss,vsz --sort=-rss | head -n 15

如果系统安装了 sysstat，可以补充磁盘 I/O：

iostat -xz 1 10

如果内核支持 PSI（Pressure Stall Information），可以查看内存压力：

test -r /proc/pressure/memory && cat /proc/pressure/memory

使用 systemd 的系统可以查看当前启动周期内的内核日志：

sudo journalctl -k -b --no-pager | tail -n 200

观察窗口内，最好同时记录以下业务指标：

• 请求量、响应时间，尤其是 P95、P99；
• 5xx 错误率、超时数量和请求队列长度；
• CPU 用户态、内核态和 iowait；
• 磁盘 await、利用率、读写量；
• 网络连接数、重传或连接建立失败情况。

这些指标必须放在同一时间线上比较。例如，只有当 available 下降的同时，vmstat 中的 si/so 增大、磁盘 await 上升、CPU iowait 增加、接口 P99 变长，才更接近“内存压力已经传导到业务”的证据链。单独一个内存百分比不足以完成判断。

2. 先看 available，再区分缓存和真实内存压力

free -h 的字段含义并不相同。64GB 内存通常会显示约 62GiB，这是 GB 与 GiB 的单位换算差异，不代表内存规格少了：

               total        used        free      shared  buff/cache   available
Mem:             62Gi        48Gi       1.2Gi       2.1Gi        13Gi        11Gi
Swap:             8Gi       512Mi       7.5Gi

如需查看更细的组成，可以执行：

grep -E 'MemTotal|MemFree|MemAvailable|Buffers|Cached|SReclaimable|Shmem|SwapTotal|SwapFree' /proc/meminfo

可以使用下面的参考范围辅助判断，但它们不是所有业务都适用的硬阈值：

• available 仍有总内存约 20% 或更多，且 si/so 长时间为 0，通常没有明显的实时内存压力；
• available 降到约 10% 至 20% 并持续下降，应开始定位进程、缓存和业务峰值；
• available 长时间低于约 10%，同时出现持续 si/so、I/O 等待升高或请求变慢，通常需要立即处理；
• free 很低，但 buff/cache 较高、available 稳定，通常更接近缓存占用，而不是内存泄漏。

数据库、缓存服务、容器集群和批处理任务的内存曲线可能不同，因此应优先比较正常时段的基线。判断“内存是否紧张”时，available 的趋势和业务表现比 free 的单点数值更重要。

缓存高时不要立即执行 drop_caches

Linux 会利用空闲内存缓存文件内容，以减少后续磁盘读取。只要 available 稳定、交换活动正常、业务延迟没有恶化，就不应因为 buff/cache 较高而手工清缓存。

以下命令会主动丢弃部分文件缓存、目录项和 inode 缓存，不应作为日常修复手段：

echo 3 | sudo tee /proc/sys/vm/drop_caches

它可能导致缓存命中率下降、后续磁盘读取增加和响应时间短时变差，也不能修复进程内存泄漏、应用缓存无上限或容器限制过小的问题。只有在明确的测试目的、已评估业务影响并准备好恢复观察时，才适合临时使用；测试结束后不需要反复执行该命令，缓存会由系统重新建立。

3. 把交换分区、磁盘 I/O 和业务延迟放在一起看

查看交换分区和换页活动：

swapon --show
free -h
vmstat 1 10

在 vmstat 中重点关注：

• si：每秒从交换空间读回内存的数据量；
• so：每秒从内存写入交换空间的数据量；
• free、buff、cache：内存与缓存变化；
• wa：CPU 等待 I/O 的比例。

Swap used 只是说明过去有页面被放入交换空间；即使它已经使用了几百 MB，只要当前 si/so 基本为 0、available 稳定，系统未必正在遭受严重换页。相比之下，持续的 si/so 更能说明实时内存压力。

NVMe SSD 的交换读写通常比机械盘更快，但交换空间仍不能替代物理内存。频繁换页会消耗磁盘 I/O 带宽，并可能与数据库、日志和文件读写争用。

没有交换空间时的处理边界

如果服务器没有交换空间，先确认磁盘余量、文件系统和当前配置：

df -hT
swapon --show
sysctl vm.swappiness

只有在根分区有足够空间、业务可以接受交换带来的延迟，并且确认需要为突发峰值增加缓冲时，才考虑创建交换文件。下面以 /swapfile 不存在为前提，示例大小为 16GiB，并不代表 64GB 内存服务器的固定要求：

sudo test -e /swapfile && echo "文件已存在，请勿直接覆盖" || echo "可以继续检查磁盘空间"
df -h /

确认文件不存在且空间充足后，再执行：

sudo fallocate -l 16G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show
free -h

这些操作会修改磁盘和交换配置。执行前应确认路径不会覆盖业务文件，并确保在内存压力期间不要直接运行 swapoff。swapoff 需要把交换页重新装回物理内存，可能瞬间增加内存压力并触发 OOM。

若要重启后自动挂载，应先备份 /etc/fstab，并确认其中没有重复的 /swapfile 配置：

sudo cp -a /etc/fstab /etc/fstab.bak.$(date +%Y%m%d%H%M%S)
printf '%s\n' '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
sudo mount -a
swapon --show

如果 mount -a 或 swapon 报错，应保留原有交换配置并先恢复备份，不要在故障处理中反复追加配置。以后需要回滚时，先确认物理内存有足够余量，再停用交换文件；从 /etc/fstab 移除对应配置后，确认文件已不再使用，才考虑删除交换文件。

4. 从系统现象定位到具体进程、容器或服务组

系统级的 free 只能说明整体状态，不能直接回答“哪个服务占用了内存”。先按 RSS 排序：

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

字段可以这样理解：

• RSS：进程当前驻留在物理内存中的大致规模；
• VSZ：进程申请或映射的虚拟地址空间，不等于实际物理内存占用；
• %MEM：进程占物理内存的比例；
• 多进程服务可能共享动态库，简单相加 RSS 会重复计算共享部分。

如果系统安装了 smem，可以进一步查看 PSS：

sudo smem -rtk

PSS 会按比例分摊共享内存，更适合分析多进程服务。不同工具对共享库、内存映射和内核页的统计口径可能不同，因此修复前后最好使用同一工具比较。

一次采样只能找到“当前最大”的进程，不能证明它是根因。可以每分钟采样一次，观察是否持续增长：

for i in $(seq 1 10); do
    date '+%F %T'
    ps -eo pid,comm,rss,%mem --sort=-rss | head -n 12
    sleep 60
done

如果某服务 RSS 从 8GiB、10GiB、13GiB 持续增长，且请求量下降后也不回落，同时 available 下降，就应重点检查：

• 对象、连接或请求上下文是否没有释放；
• 应用缓存是否没有大小或过期上限；
• worker、线程或并发连接数是否配置过大；
• 批量任务是否一次性加载过多数据；
• 堆外内存、共享内存或内存映射是否持续增长；
• 服务是否被 systemd、容器或其他 cgroup 设置了更低的内存上限。

如果使用 systemd 管理服务，可以查看服务组资源情况：

systemd-cgtop -m
systemctl status 服务名

其中“服务名”应替换为实际服务名称。如果服务器运行容器，还应查看容器级别的使用量和限制：

docker stats --no-stream

容器达到自身内存上限时，宿主机仍可能有较多 available，但容器内进程已经被终止。因此，不能只看宿主机的 64GB 总内存，还要同时核对容器限制、工作集和退出记录。

5. 区分全局 OOM、cgroup OOM 和应用自身保护

当进程突然消失或服务重启时，不要直接认定是整台服务器内存耗尽。至少需要区分以下情况：

1. Linux 全局 OOM：宿主机可回收内存不足，内核选择并终止进程；
2. cgroup OOM：容器或服务组达到自身内存上限，但宿主机可能仍有余量；
3. 应用自身限制：运行时堆上限、连接池、缓存或框架保护机制主动报错；
4. 服务管理器重启：健康检查、部署脚本或管理员操作触发了重启。

先检查当前启动周期内的内核记录：

sudo journalctl -k -b --no-pager | grep -Ei 'out of memory|oom|killed process|memory cgroup'

没有 journalctl 时，可以尝试：

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

类似下面的日志更接近全局 OOM：

Out of memory: Killed process 2481 (app-worker)
Killed process 2481 total-vm:...

如果日志中出现 memory cgroup、容器名称或服务组路径，则更偏向 cgroup 限制。此时应检查限制值，而不是盲目增加宿主机交换空间。

对于 systemd 服务，可以查看资源限制：

systemctl show 服务名 -p MemoryMax -p MemoryHigh -p MemoryCurrent

如果 MemoryMax 明显低于业务实际峰值，调整前需要确认宿主机还有足够余量，并评估同机其他服务的资源预算。直接放大限制可能把局部故障变成整机内存争用；修改前应保留原配置，修改后再通过业务高峰复测。

还要注意日志保留范围。journalctl -k -b 主要查看当前启动周期；如果服务器已经重启，之前的 OOM 记录是否还能查到，取决于日志持久化和保留策略。查不到日志不等于没有发生过 OOM，应结合服务退出时间、监控曲线和应用日志交叉确认。

6. 排除“看起来像内存问题”的其他解释

内存告警出现时，内存有可能只是伴随变化的指标。下面几种组合可以帮助排除替代解释。

缓存上升，但 available 稳定

如果磁盘读流量增加后 buff/cache 上升，而 available、交换活动和应用延迟都稳定，通常是正常文件缓存。此时不需要手工清理缓存，应观察任务结束后缓存是否可回收。

RSS 增长，交换和响应时间同步恶化

如果某进程 RSS 持续增加，available 下降，vmstat 的 si/so 连续出现，磁盘 await、CPU iowait、接口 P99 和超时数量一起上升，应优先怀疑内存泄漏、缓存无上限或并发量过高。

available 充足，但业务仍然超时

如果 available 充足、si/so 为 0，但网络连接数、请求队列、CPU 用户态或磁盘队列异常，问题可能来自线程池、连接池、I/O 阻塞或网络重传。此时单纯增加内存通常不能解决问题。

shared 或 tmpfs 占用明显

可以查看内存盘和共享内存：

df -hT /dev/shm
df -hT | grep -E 'tmpfs|shm'

临时文件、进程间共享内存或容器共享目录可能使 shared 增长。处理前必须确认文件用途，不能直接删除正在使用的文件或目录。

7. 修复时先降低峰值，再调整资源参数

确认根因后，建议按以下优先级处理：

1. 保留证据：保存 free -h、vmstat、进程 RSS、OOM 日志和业务响应指标。
2. 限制异常增长：为应用缓存设置上限，降低批量任务大小，控制 worker、线程、连接和并发请求数。
3. 错开高峰任务：将构建、报表、数据导入等高内存任务移出业务高峰，避免多个任务同时申请大块内存。
4. 谨慎重载或重启服务：确认服务可恢复、配置和数据已有必要备份，并接受短时连接影响后再操作；优先使用服务支持的优雅重载，避免直接强制终止。
5. 补充交换空间：交换只能作为突发峰值缓冲，不能替代物理内存，也不能掩盖持续泄漏。
6. 调整 cgroup 或服务限制：先核对整机余量，再决定是否放大限制，修改后确认同机其他服务没有受到影响。

对这套 CPU、64GB 内存和 NVMe 存储配置，业务容量估算不能用“最大连接数”直接替代每秒请求数。连接数表示同时保持的会话数量，QPS 或吞吐量表示单位时间内处理的请求数量，两者可能完全不同。内存峰值可以先用变量估算：

M_peak ≈ M_system + N_worker × M_worker + M_cache + M_batch + M_shared

其中 M_system 是系统及常驻服务占用，N_worker 是工作进程或线程对应的并发执行单元，M_worker 是单个执行单元的平均内存，M_cache 是应用缓存，M_batch 是批处理峰值，M_shared 是共享内存和其他无法简单归入进程 RSS 的部分。没有这些变量的实测或监控数据，不能给出确定的请求量或并发连接上限。

因此，“CPU：金牌 6138（20核40线程）内存：64GB DDR4-2666硬盘：960GB NVMe PCIE Gen4 SSD 这款香港服务器适合做什么业务”的内存侧答案，应限定为：适合常驻内存和峰值可预测、并发受控的中等规模业务；是否适合具体应用，要用业务基线、进程占用、缓存策略和高峰任务复测，而不能只凭 64GB 这个总量判断。

8. 修复后用同一组指标验证

修复后至少覆盖一个正常运行周期和一个历史高峰时段，连续记录：

date '+%F %T'
free -h
vmstat 1 5
swapon --show
ps -eo pid,comm,rss,%mem --sort=-rss | head -n 15

如果此前存在磁盘 I/O 告警，再执行：

iostat -xz 1 5

有效修复应同时体现为：

• available 在业务峰值期间不再持续单向下降；
• si/so 在正常业务期间基本为 0，或只在短时峰值出现；
• 交换空间使用量不再持续增长；
• 异常进程 RSS 在业务量稳定后趋于平稳；
• 磁盘 await、CPU iowait、请求 P99、超时和错误率回到原有基线；
• 内核日志中不再出现新的 OOM 或 memory cgroup 终止记录。

下一次出现告警时，应把 available + buff/cache、Swap 的 si/so、异常进程 RSS、CPU iowait、磁盘 await、网络连接或队列、接口 P99 和错误率放在同一时间线上。这样的指标组合，才能区分缓存回收、真实内存压力、进程泄漏、cgroup 限制，还是 I/O 与业务队列造成的表面内存异常。