Linux服务器出现网站响应缓慢、程序启动失败、数据库异常退出等情况时，可以先检查内存使用情况。
判断是否缺少内存，需要结合可用内存、进程占用、交换活动和故障日志。只看到“内存使用率高”，还不能确定服务器需要扩容。
本文适用于通过SSH管理的常见Linux服务器。日志查询部分适用于使用systemd的系统，命令中的进程PID、容器名称需要替换为实际值。
1. 查看内存和Swap使用情况
登录服务器后，执行：
free -h重点查看以下字段：
| 字段 | 含义 | 查看重点 |
|---|---|---|
| total | 系统可使用的内存总量 | 确认系统识别到的容量 |
| used | 已使用或不可用的内存 | 不同版本的统计口径可能不同 |
| free | 完全空闲的内存 | 数值较低不一定代表内存不足 |
| buff/cache | 缓冲区和缓存占用 | 其中部分内存可以回收 |
| available | 无需交换即可供新程序使用的内存估算值 | 优先观察这一项 |
| Swap | 交换空间使用情况 | 结合交换活动判断影响 |
Linux会利用内存缓存文件和其他数据。因此，free较低、buff/cache较高，而available仍比较充足时，通常不需要专门清理缓存。
如果available持续偏低，同时出现页面变慢、进程退出或大量交换活动，就需要继续排查。
查看已启用的交换空间：
swapon --show没有输出时，通常表示当前没有启用Swap。Swap已经占用一部分，也不等于服务器此刻仍在频繁交换数据。
2. 定位占用内存较高的进程
执行以下命令，按常驻内存从高到低列出前5个进程：
ps -eo pid,user,pmem,rss,comm --sort=-rss | head -n 6输出字段说明：
| 字段 | 含义 |
|---|---|
| PID | 进程编号 |
| USER | 运行该进程的用户 |
| %MEM | 常驻内存占系统物理内存的比例 |
| RSS | 当前驻留在物理内存中的进程内存，单位为KiB |
| COMMAND | 进程名称 |
例如，RSS为1048576，约等于1GiB。
需要注意，多个进程可能共享部分内存，不能简单相加所有RSS来计算整台服务器的实际占用。
发现高占用进程后，查看启动参数和运行时间：
ps -p 2841 -o pid,ppid,user,etime,args继续观察该进程：
top -p 2841也可以直接运行top，按Shift + M按照内存占用排序，按q退出。
先确认进程属于哪个网站、数据库或后台任务，再判断占用是否符合预期。一次采样偏高，不能直接认定存在内存泄漏。
3. 判断是否正在频繁使用Swap
执行：
vmstat 1 6该命令每秒输出一次，共输出6次。
重点关注：
| 字段 | 含义 |
|---|---|
| swpd | 已使用的交换空间 |
| si | 每秒从交换空间读入内存的数据量 |
| so | 每秒从内存写入交换空间的数据量 |
| b | 等待I/O完成的阻塞进程数 |
| wa | CPU等待I/O的时间比例 |
第一行中的交换、I/O和CPU速率通常是开机以来的平均值，后续行才反映采样间隔内的变化；进程和内存数量则是当前值。
如果连续出现明显的si或so活动，同时可用内存偏低、业务响应变慢，说明交换活动可能正在影响性能。
如果没有启用Swap，即使si和so一直为0，也不能据此排除内存不足。
4. 检查进程是否因OOM被终止
OOM表示内存分配遇到不足。当系统或某个受限制的进程组无法满足内存需求时，内核可能终止进程以释放资源。
查询本次启动后、最近两小时的相关内核日志：
sudo journalctl -k -b --since "-2h" --no-pager | \
grep -Ei 'out of memory|killed process|oom-kill'发现类似Out of memory或Killed process的记录时，记下：
-
故障发生时间。
-
被终止进程的PID和名称。
-
当时的内存占用。
-
是否涉及容器或其他资源限制。
被终止的进程不一定是造成内存压力的最初原因，还需要结合其他进程和故障前的监控判断。
查看完整上下文时，执行：
sudo journalctl -k -b --since "-2h" --no-pager如果系统启用了systemd-oomd，还可以检查其日志：
sudo journalctl -b -u systemd-oomd --since "-2h" --no-pager它可能在内核OOM发生前，根据内存压力终止相关进程。
没有查到记录时，先确认故障时间是否在查询范围内。服务器重启过的，还需要检查上一次启动的日志；只有历史日志被保留下来时，才能查询到。
应用自身报告的内存错误，例如Java的OutOfMemoryError，也需要查看应用日志，不能全部归为内核OOM。
5. Docker容器内存不足怎么排查？
在宿主机上执行：
docker stats --no-stream重点查看MEM USAGE / LIMIT，确认容器当前占用和允许使用的内存上限。
持续观察某个容器：
docker stats web其中web需要替换为实际容器名称。
检查容器状态和配置：
docker inspect --format \
'OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}} Memory={{.HostConfig.Memory}}' web主要字段说明：
| 字段 | 含义 |
|---|---|
| OOMKilled | Docker记录的容器OOM终止状态 |
| ExitCode | 容器退出码 |
| Memory | 显式配置的内存硬限制，单位为字节 |
Memory=0通常表示没有通过该配置设置容器内存硬限制，但仍可能受到上级资源限制和宿主机容量影响。
宿主机还有可用内存，并不代表容器一定够用。例如，容器只允许使用512MiB，达到限制后仍可能发生OOM。
退出码137通常与被SIGKILL信号终止有关，不能单凭这个数字认定发生了OOM。应结合OOMKilled、内核日志和应用日志确认；容器自动重启后，当前状态也不能完整代替历史记录。
另外，Linux上的docker stats会对缓存占用作扣除处理，其数值不一定与其他监控工具完全一致。
6. 常见内存占用原因怎么处理？
| 常见情况 | 排查方向 | 处理思路 |
|---|---|---|
| PHP-FPM进程数量较多 | 并发请求、工作进程数量、单进程占用 | 根据单进程实际占用调整并发上限 |
| MySQL占用较大 | 缓冲池、连接数量、查询和临时数据 | 综合调整缓存及连接配置 |
| Java程序持续增长 | 堆设置、堆外内存、线程数量、对象增长 | 结合应用监控定位问题，并为堆外内存留出空间 |
| Python或Node.js批处理占用高 | 大文件读取、批量查询、队列堆积 | 分批处理，限制并发和队列长度 |
| 备份、压缩任务运行时突增 | 是否同时运行多个任务 | 错峰执行，减少并行任务 |
| 容器反复退出 | 容器限额、应用峰值、宿主机余量 | 同时核对限额与真实需求 |
| tmpfs占用较大 | 内存文件系统中的文件 | 确认文件用途后，由对应应用清理 |
如果占用在相近业务负载下持续增长，且长期不回落，应进一步分析应用对象、缓存策略或内存分配情况。
不要仅凭进程名称结束程序，也不要把全部内存都分配给单个数据库缓存或应用堆。
7. 是否需要手动清理系统缓存？
通常不需要。
Linux会在需要时回收可回收缓存。定时执行drop_caches不能解决应用内存泄漏、并发过高或容器限额不足等问题。
频繁丢弃缓存，还可能导致系统重新读取文件，增加磁盘I/O和CPU开销。
更有效的做法是查看available的变化，找到实际占用来源，再调整应用配置和任务安排。
8. 业务已经卡顿，应该先做什么？
建议按以下顺序处理：
-
保存当前内存、进程和故障日志，记录发生时间。
-
暂停已经确认可以暂停的备份、压缩、导入等非核心任务。
-
降低异常任务的并发，控制队列积压和重复重试。
-
对明确异常的应用，评估影响后通过服务管理工具正常重启。
-
继续观察内存和业务响应，确认是否再次增长。
数据库、缓存和关键业务进程需要先确认恢复方式，避免直接使用kill -9强行结束。
如果SSH已经难以响应，可以使用实例支持的控制台连接方式尝试登录。需要重启服务器时，应考虑当前写入任务和业务恢复流程。
重启能够暂时释放内存，但仍需要继续查明占用增长的原因。
9. 增加Swap还是升级内存？
Swap可以为部分短时内存峰值提供缓冲，但磁盘上的交换空间速度通常明显低于内存。
是否增加Swap，应结合磁盘剩余空间、存储性能和应用要求判断。持续依赖大量交换，通常会影响业务响应。
| 情况 | 优先处理方式 |
|---|---|
| 偶尔运行任务时短暂出现峰值 | 错峰执行、降低并发，评估Swap缓冲 |
| 日常业务长期缺少可用内存 | 优化配置并评估升级内存 |
| 单个应用持续增长 | 排查应用问题，扩容只能延缓再次耗尽 |
| 容器上限明显偏低 | 在宿主机资源允许时调整容器配置 |
| 主要是可回收缓存占用 | 结合available和业务表现判断，无需只为降低使用率而扩容 |
不要为了让Swap使用量归零，在内存紧张时直接关闭全部Swap。将交换数据搬回内存可能进一步增加压力。
升级莱卡云服务器配置前，应核对目标实例支持的变更方式，以及是否需要停机或重启。
10. 处理后如何确认恢复正常？
再次检查：
free -h
vmstat 1 6
ps -eo pid,user,pmem,rss,comm --sort=-rss | head -n 6同时确认：
-
可用内存是否恢复到能支撑当前业务的水平。
-
交换活动是否减少。
-
高占用进程是否停止异常增长。
-
网站、接口和数据库是否恢复正常响应。
-
是否还有新的OOM或进程异常退出记录。
应覆盖实际业务高峰继续观察，避免只检查空闲时段。
如需提交莱卡云技术支持工单，建议提供故障时间及服务器时区、系统与内存配置、相关命令输出、故障日志，以及近期部署或配置变更。提交前请遮盖密码、令牌和其他敏感信息。