我在阿里云购买了云服务器，容量为2核2G。
自部署了多个应用服务之后，内存使用率达到了86%，自己的应用服务多次出现无法访问的情况。然后发现是被系统悄咪咪的杀掉了。
本来想关掉一些阿里云自带的监控服务。检查了一下，人家占用的资源并不太多，每个服务几十M，几M。总共大概不超过100M。
于是乎，还是试试虚拟内存吧。然后吭哧吭哧一顿操作。
使用部分磁盘空间创建Swap虚拟内存，这在Linux系统中是标准做法。
创建Swap文件步骤：
1. 检查当前内存和Swap状态
free -h
swapon --show
2. 创建Swap文件（以2GB为例）
# 创建空文件
sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress
# 或使用fallocate（更快）
sudo fallocate -l 2G /swapfile
3. 设置权限并格式化
sudo chmod 600 /swapfile
sudo mkswap /swapfile
4. 启用Swap文件
sudo swapon /swapfile
5. 永久生效（重启后保留）
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
Swap大小建议：
物理内存 ≤ 2GB：Swap建议为内存的2倍
物理内存 2GB~8GB：Swap等于内存大小
物理内存 ≥ 8GB：至少4GB
优化Swap性能
# 调整swappiness参数（默认60，值越小越倾向使用物理内存）
sudo sysctl vm.swappiness=10
# 永久生效
echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf
重要提醒：
Swap性能远低于物理内存（速度仅为内存的百分之一），只能作为临时解决方案
建议内存使用率保持在75%以下的安全阈值
扩容前务必备份重要数据
系统在什么时候会使用swap内存
系统使用Swap内存主要取决于内核的内存管理策略，核心触发时机是物理内存（RAM）不足时，但具体规则比简单的“内存耗尽”更精细和主动。
以下是系统开始使用Swap的主要场景：
1. 内存压力达到阈值时（最常见）
当空闲物理内存低于一个关键阈值（由内核参数 vm.swappiness影响，默认值通常为60，范围0-100），内核会主动将一部分不活跃的内存页（Inactive Pages）移动到Swap中，以释放RAM给当前活跃的程序使用。
swappiness=0：尽可能避免使用Swap，除非物理内存完全耗尽（OOM风险增高）。swappiness=100：内核会非常积极地使用Swap，即使内存压力不大。
2. 发生“内存回收”（Memory Reclaim）时
内核持续监控内存状态。当需要分配新内存但空闲内存不足时，会触发内存回收流程：
首先尝试回收页面缓存（Page Cache，用于缓存磁盘数据）。
如果仍不足，则开始查找并移出不活跃的匿名页（Anonymous Pages，即程序运行数据）到Swap。
3. 系统休眠到磁盘（Hibernation）
这是Swap的一个设计用途。当电脑休眠时，系统会将整个RAM的内容写入Swap分区/文件，然后关机。唤醒时再从Swap读回，恢复状态。
4. 进程进入睡眠状态时
如果一个进程长时间处于睡眠状态且其内存页不被访问，内核可能会将其部分内存交换到Swap，以优化物理内存的使用。
5. 大内存应用启动时
即使当前内存充足，如果系统预测到即将启动一个需要大量内存的程序，也可能会提前将一些后台进程的不常用内存交换出去，为新程序预留空间。
后续的操作和实践建议：
监控Swap使用：使用
free -h或cat /proc/meminfo查看SwapCached和SwapUsed。如果这些值在持续增长，说明系统正在频繁使用Swap。理解性能影响：Swap使用磁盘空间模拟内存，速度比物理内存慢成千上万倍。少量使用Swap是正常的系统优化；但频繁、大量的Swap交换（Swapping） 会导致硬盘IO飙升，系统响应变得极其缓慢，这种现象称为“颠簸”（Thrashing）。
应对策略：
短期：创建Swap可以防止系统在内存瞬间耗尽时直接崩溃（触发OOM Killer杀死进程）。
根本解决：正如之前建议，长期仍需通过优化应用程序或升级服务器配置来减少对Swap的依赖，因为Swap不能替代物理内存的性能。
简单来说：系统不会等到内存100%用完才用Swap，它会在内存变得紧张时（根据swappiness设置）就“未雨绸缪”，主动把最近不用的数据挪到Swap里，以保持物理内存有足够的空闲空间供当前任务快速使用。
