交换内存SWAP使用率过高问题——天翼云环境下的深度剖析与优化策略-天翼云开发者社区

一、SWAP使用率过高的核心诱因

1.1 物理内存不足：直接触发条件

当系统剩余内存（MemFree + Buffers + Cached）低于内核设定的阈值（如pages_low）时，内核会启动直接回收（Direct Reclaim）或唤醒kswapd线程进行后台回收。若物理内存总量无法满足业务需求（例如Java应用未限制堆内存导致持续增长），SWAP将成为“最后的缓冲带”。

案例：某天翼云用户运行高并发Web服务，物理内存为8GB，但未对Nginx工作进程的内存占用进行限制。在流量峰值时，系统剩余内存降至200MB以下，SWAP使用率飙升至90%，导致页面加载延迟超过5秒。

1.2 Swappiness参数配置不当：加剧SWAP依赖

swappiness是内核控制SWAP使用倾向的参数（范围0-100），其值越高，内核越倾向于将匿名页（如进程堆栈）换出到SWAP。默认值60可能导致系统在物理内存仍有剩余时过早使用SWAP，引发不必要的磁盘I/O。

关键机制：

匿名页与文件页的回收优先级：高swappiness值会优先回收匿名页，而低值（如10）会优先回收文件页（如Page Cache）。
误区澄清：即使swappiness=0，当MemFree + Buffers + Cached < pages_high时，内核仍会触发SWAP换出。

1.3 内存泄漏与低效应用：隐蔽的内存杀手

应用程序未正确释放内存（如Java的Full GC未执行、数据库连接未关闭）会导致内存占用持续增长，最终挤占物理内存并触发SWAP。此类问题通常表现为：

内存占用随时间线性增长：通过top或htop观察进程的RES（常驻内存）持续上升。
SWAP使用率阶段性飙升：与业务负载周期相关（如每日定时任务触发内存泄漏）。

1.4 Swap空间配置不合理：容量与性能的平衡

Swap空间过小会快速耗尽并导致系统不稳定，而过大则可能掩盖内存瓶颈，延迟问题暴露。常见经验值：

物理内存≤2GB：Swap=2×物理内存
2GB<物理内存≤8GB：Swap≈物理内存
物理内存>8GB：Swap≥4GB且≤8GB

天翼云实践：某用户为16GB内存的服务器配置了32GB Swap文件，虽未出现SWAP耗尽问题，但高并发时磁盘I/O延迟增加30%，最终通过调整swappiness=10并优化应用内存使用解决了问题。

二、SWAP使用率过高的诊断流程

2.1 实时监控：快速定位问题

free -h：查看物理内存与SWAP的总量、已用量及可用量。

bash
```
total  used  free  shared  buff/cache  available
Mem:   15Gi  8.2Gi  1.2Gi  300Mi  5.6Gi  6.5Gi
Swap:  4.0Gi  2.8Gi  1.2Gi
```
若SwapUsed/SwapTotal接近100%，且Available内存较低，则需深入分析。

vmstat 1：监控SWAP活动（si/so列）及内存回收情况。

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
12  0 2867200 123456 87654 567890  120   80   150    200  1000 2000 10  5 80  5  0

持续高值的si（Swap In）和so（Swap Out）表明系统正在频繁交换内存页。

top/htop：按内存占用排序进程，定位高消耗应用。

PID  USER  PR  NI  VIRT  RES  SHR  S  %MEM  %CPU  COMMAND
1234 mysql  20   0  10.2g 5.2g  10m S  34.2  12.5  mysqld

2.2 深度分析：定位内存泄漏与回收策略

/proc/meminfo：查看详细内存分配情况。

AnonPages: 4567892 kB   # 匿名页占用
Mapped:    123456 kB    # 内存映射文件
Shmem:     78901 kB     # 共享内存

若AnonPages持续增长且无对应业务增长，可能存在内存泄漏。

sar -B：分析内存回收统计信息。

bash
```
pgscank/s pgscand/s pgsteal/s %vmeff
120.50    80.25     150.75    65.33
```
pgscank（kswapd扫描页）和pgscand（直接回收扫描页）的值持续较高，表明内存回收压力较大。
smem：可视化进程内存使用趋势。

bash
```
smem -s uss -k -p | head -10
```

三、天翼云环境下的优化方案

3.1 短期应急：快速缓解SWAP压力

刷新SWAP缓存（需确保物理内存足够）：

bash
```
sudo swapoff -a && sudo swapon -a
```
此操作会临时将SWAP中的数据转回内存，但若物理内存不足可能导致OOM Killer触发。
重启高内存占用进程：
通过top定位占用SWAP最多的进程（如Java应用），结合业务影响评估是否重启。

3.2 中期优化：调整系统参数与应用配置

降低swappiness值：

# 临时生效
echo 10 | sudo tee /proc/sys/vm/swappiness
# 永久生效
echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

推荐值10-30，可显著减少不必要的SWAP换出。

优化应用内存配置：
- Java应用：限制堆内存（-Xms/-Xmx），启用G1垃圾回收器。
- 数据库：调整innodb_buffer_pool_size（MySQL）或shared_buffers（PostgreSQL）。
- Web服务：限制Nginx工作进程内存（worker_rlimit_nofile）或使用连接池。

启用ZRAM压缩交换（适用于内存充足但需减少磁盘I/O的场景）：

sudo apt install zram-tools
echo "ENABLED=true" | sudo tee /etc/default/zramswap
echo "ZRAM_PERCENT=25" | sudo tee -a /etc/default/zramswap  # 使用25%内存创建压缩SWAP
sudo systemctl restart zramswap

3.3 长期解决方案：扩容与架构优化

增加物理内存：
根据业务增长预测，提前扩容天翼云服务器的内存（如从16GB升级至32GB）。
水平扩展：
对高并发服务（如Web、数据库）部署负载均衡，分散内存压力。例如，使用Nginx反向代理将请求分发至多台后端服务器。
使用分布式缓存：
引入Redis或Memcached缓存热点数据，减少应用对内存的直接占用。例如，将数据库查询结果缓存至Redis，降低数据库内存负担。

四、天翼云实践案例：某电商平台的SWAP优化

4.1 问题背景

某电商平台在天翼云部署了4台8GB内存的服务器，运行Java微服务与MySQL数据库。在促销活动期间，系统频繁出现卡顿，监控显示SWAP使用率长期高于80%，si/so值持续超过200KB/s。

4.2 诊断过程

内存分析：
- free -h显示物理内存剩余1.2GB，但Available仅600MB（因Page Cache占用）。
- top发现Java进程占用4.5GB内存，且RES随时间增长。
SWAP活动监控：
- vmstat 1显示so值持续高于150KB/s，表明系统正在频繁换出内存页。
应用日志：
- Java应用日志中出现OutOfMemoryError: Java heap space，表明堆内存配置不足。

4.3 优化措施

调整Java堆内存：
- 将-Xmx从3GB调整至5GB（确保不超过物理内存的70%），并启用G1回收器。
降低swappiness：
- 将vm.swappiness从60降至10，减少不必要的SWAP换出。
优化MySQL缓存：
- 将innodb_buffer_pool_size从2GB调整至3GB，减少磁盘I/O。
扩容与负载均衡：
- 增加2台16GB内存的服务器，并通过Nginx负载均衡分散流量。

4.4 优化效果

SWAP使用率降至20%以下，si/so值接近0。
系统响应时间从5秒降至200ms，促销活动期间无卡顿报告。

五、总结与展望

SWAP使用率过高是天翼云服务器性能优化的常见挑战，其根源涉及物理内存不足、系统参数配置、应用内存管理等多方面。通过系统性诊断（如free、vmstat、top）与针对性优化（调整swappiness、优化应用配置、扩容内存），可显著降低SWAP依赖，提升系统稳定性。未来，随着天翼云对容器化与Serverless的支持，内存管理将更加精细化，但SWAP作为“安全网”的角色仍不可替代。运维人员需持续监控内存使用趋势，结合业务特点制定动态优化策略，确保系统在高并发场景下稳定运行。

一、SWAP使用率过高的核心诱因

1.1 物理内存不足：直接触发条件

1.2 Swappiness参数配置不当：加剧SWAP依赖

关键机制：

匿名页与文件页的回收优先级：高swappiness值会优先回收匿名页，而低值（如10）会优先回收文件页（如Page Cache）。
误区澄清：即使swappiness=0，当MemFree + Buffers + Cached < pages_high时，内核仍会触发SWAP换出。

1.3 内存泄漏与低效应用：隐蔽的内存杀手

应用程序未正确释放内存（如Java的Full GC未执行、数据库连接未关闭）会导致内存占用持续增长，最终挤占物理内存并触发SWAP。此类问题通常表现为：

内存占用随时间线性增长：通过top或htop观察进程的RES（常驻内存）持续上升。
SWAP使用率阶段性飙升：与业务负载周期相关（如每日定时任务触发内存泄漏）。

1.4 Swap空间配置不合理：容量与性能的平衡

Swap空间过小会快速耗尽并导致系统不稳定，而过大则可能掩盖内存瓶颈，延迟问题暴露。常见经验值：

物理内存≤2GB：Swap=2×物理内存
2GB<物理内存≤8GB：Swap≈物理内存
物理内存>8GB：Swap≥4GB且≤8GB

二、SWAP使用率过高的诊断流程

2.1 实时监控：快速定位问题

free -h：查看物理内存与SWAP的总量、已用量及可用量。

bash
```
total  used  free  shared  buff/cache  available
Mem:   15Gi  8.2Gi  1.2Gi  300Mi  5.6Gi  6.5Gi
Swap:  4.0Gi  2.8Gi  1.2Gi
```
若SwapUsed/SwapTotal接近100%，且Available内存较低，则需深入分析。

vmstat 1：监控SWAP活动（si/so列）及内存回收情况。

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
12  0 2867200 123456 87654 567890  120   80   150    200  1000 2000 10  5 80  5  0

持续高值的si（Swap In）和so（Swap Out）表明系统正在频繁交换内存页。

top/htop：按内存占用排序进程，定位高消耗应用。

PID  USER  PR  NI  VIRT  RES  SHR  S  %MEM  %CPU  COMMAND
1234 mysql  20   0  10.2g 5.2g  10m S  34.2  12.5  mysqld

2.2 深度分析：定位内存泄漏与回收策略

/proc/meminfo：查看详细内存分配情况。

AnonPages: 4567892 kB   # 匿名页占用
Mapped:    123456 kB    # 内存映射文件
Shmem:     78901 kB     # 共享内存

若AnonPages持续增长且无对应业务增长，可能存在内存泄漏。

sar -B：分析内存回收统计信息。

bash
```
pgscank/s pgscand/s pgsteal/s %vmeff
120.50    80.25     150.75    65.33
```
pgscank（kswapd扫描页）和pgscand（直接回收扫描页）的值持续较高，表明内存回收压力较大。
smem：可视化进程内存使用趋势。

bash
```
smem -s uss -k -p | head -10
```

三、天翼云环境下的优化方案

3.1 短期应急：快速缓解SWAP压力

刷新SWAP缓存（需确保物理内存足够）：

bash
```
sudo swapoff -a && sudo swapon -a
```
此操作会临时将SWAP中的数据转回内存，但若物理内存不足可能导致OOM Killer触发。
重启高内存占用进程：
通过top定位占用SWAP最多的进程（如Java应用），结合业务影响评估是否重启。

3.2 中期优化：调整系统参数与应用配置

降低swappiness值：

# 临时生效
echo 10 | sudo tee /proc/sys/vm/swappiness
# 永久生效
echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

推荐值10-30，可显著减少不必要的SWAP换出。

优化应用内存配置：
- Java应用：限制堆内存（-Xms/-Xmx），启用G1垃圾回收器。
- 数据库：调整innodb_buffer_pool_size（MySQL）或shared_buffers（PostgreSQL）。
- Web服务：限制Nginx工作进程内存（worker_rlimit_nofile）或使用连接池。

启用ZRAM压缩交换（适用于内存充足但需减少磁盘I/O的场景）：

sudo apt install zram-tools
echo "ENABLED=true" | sudo tee /etc/default/zramswap
echo "ZRAM_PERCENT=25" | sudo tee -a /etc/default/zramswap  # 使用25%内存创建压缩SWAP
sudo systemctl restart zramswap

3.3 长期解决方案：扩容与架构优化

增加物理内存：
根据业务增长预测，提前扩容天翼云服务器的内存（如从16GB升级至32GB）。
水平扩展：
对高并发服务（如Web、数据库）部署负载均衡，分散内存压力。例如，使用Nginx反向代理将请求分发至多台后端服务器。
使用分布式缓存：
引入Redis或Memcached缓存热点数据，减少应用对内存的直接占用。例如，将数据库查询结果缓存至Redis，降低数据库内存负担。

四、天翼云实践案例：某电商平台的SWAP优化

4.1 问题背景

4.2 诊断过程

内存分析：
- free -h显示物理内存剩余1.2GB，但Available仅600MB（因Page Cache占用）。
- top发现Java进程占用4.5GB内存，且RES随时间增长。
SWAP活动监控：
- vmstat 1显示so值持续高于150KB/s，表明系统正在频繁换出内存页。
应用日志：
- Java应用日志中出现OutOfMemoryError: Java heap space，表明堆内存配置不足。

4.3 优化措施

调整Java堆内存：
- 将-Xmx从3GB调整至5GB（确保不超过物理内存的70%），并启用G1回收器。
降低swappiness：
- 将vm.swappiness从60降至10，减少不必要的SWAP换出。
优化MySQL缓存：
- 将innodb_buffer_pool_size从2GB调整至3GB，减少磁盘I/O。
扩容与负载均衡：
- 增加2台16GB内存的服务器，并通过Nginx负载均衡分散流量。

4.4 优化效果

SWAP使用率降至20%以下，si/so值接近0。
系统响应时间从5秒降至200ms，促销活动期间无卡顿报告。

活动

息壤智算

应用商城

定价

合作伙伴

开发者

支持与服务

了解天翼云

交换内存SWAP使用率过高问题——天翼云环境下的深度剖析与优化策略

一、SWAP使用率过高的核心诱因

1.1 物理内存不足：直接触发条件

1.2 Swappiness参数配置不当：加剧SWAP依赖

1.3 内存泄漏与低效应用：隐蔽的内存杀手

1.4 Swap空间配置不合理：容量与性能的平衡

二、SWAP使用率过高的诊断流程

2.1 实时监控：快速定位问题

2.2 深度分析：定位内存泄漏与回收策略

三、天翼云环境下的优化方案

3.1 短期应急：快速缓解SWAP压力

3.2 中期优化：调整系统参数与应用配置

3.3 长期解决方案：扩容与架构优化

四、天翼云实践案例：某电商平台的SWAP优化

4.1 问题背景

4.2 诊断过程

4.3 优化措施

4.4 优化效果

五、总结与展望

交换内存SWAP使用率过高问题——天翼云环境下的深度剖析与优化策略

一、SWAP使用率过高的核心诱因

1.1 物理内存不足：直接触发条件

1.2 Swappiness参数配置不当：加剧SWAP依赖

1.3 内存泄漏与低效应用：隐蔽的内存杀手

1.4 Swap空间配置不合理：容量与性能的平衡

二、SWAP使用率过高的诊断流程

2.1 实时监控：快速定位问题

2.2 深度分析：定位内存泄漏与回收策略

三、天翼云环境下的优化方案

3.1 短期应急：快速缓解SWAP压力

3.2 中期优化：调整系统参数与应用配置

3.3 长期解决方案：扩容与架构优化

四、天翼云实践案例：某电商平台的SWAP优化

4.1 问题背景

4.2 诊断过程

4.3 优化措施

4.4 优化效果

五、总结与展望