我在一次香港数据中心的大数据处理项目中，负责优化一台专用于Spark作业的物理服务器。作业运行过程中频繁出现 OutOfMemoryError 和 kill 日志提示，初步排查物理内存利用率虽然高，但尚未触顶，疑似与虚拟内存（swap）的使用策略有关。通过深入调试系统内核参数与NUMA策略后，我成功将作业吞吐量提升了将近30%，并稳定了整个任务队列的运行。这篇文章将还原这一过程，讲解我在香港服务器上如何通过精细化配置虚拟内存（Swap）来提升大数据任务性能。
一、背景环境与面临的问题
1.1 香港服务器基础配置（以A5数据为例）
- CPU：2×Intel Xeon Silver 4314（32核）
- 内存：256GB DDR4 ECC
- 存储：RAID10 NVMe SSD 4TB
- OS：Ubuntu 22.04 LTS
- 运行环境：Apache Spark + Hadoop 3.3.2 集群节点
1.2 问题现象
- Spark Executor 被频繁 OOM kill
- vmstat 显示 swap 在高负载场景中被频繁使用
- dmesg 日志出现内核内存回收与进程中断提示
二、虚拟内存与Swap机制的理解
Linux 内核使用 Swap 作为物理内存不足时的溢出空间，但在高性能场景下如果配置不当，Swap 反而可能拖慢任务响应，特别是内存随机读写密集型的 Hadoop/Spark 环境。
Swap 的性能瓶颈主要表现为：
- SSD I/O 瓶颈被占用
- NUMA 节点间访问效率低
- 内核的回收策略不符合业务期望（LRU回收 vs 应用主动释放）
三、核心优化目标
- 降低系统对Swap的依赖，但保留其安全缓冲能力
- 调整Swap优先级，确保必要时才使用
- 为Spark等服务组件分配合理内存比例，避免过度Page Cache占用
- 提高NUMA感知调度和内存亲和性（memory affinity）
四、实战配置与调优步骤
4.1 查看当前Swap使用情况
free -h
swapon --show
vmstat 1 5
4.2 临时调整 swappiness 参数（影响 Swap 使用倾向）
sysctl vm.swappiness=10
说明：默认值为 60，设置为 10 表示尽可能使用物理内存，只有在紧急时才启动 Swap。
永久生效：
echo 'vm.swappiness=10' >> /etc/sysctl.conf
sysctl -p
4.3 使用zswap或zram替代传统swap（降低I/O压力）
安装并启用 zram（内存压缩swap设备）
apt install zram-tools
编辑 /etc/default/zramswap，配置如下：
ALGO=lz4
PERCENT=50
PRIORITY=100
启用并查看：
systemctl enable --now zramswap
zramctl
优势：Zram使用内存压缩机制，相较SSD Swap，减少I/O延迟，对大数据场景特别有效。
4.4 调整透明大页（THP）策略，避免内存碎片对大数据处理造成干扰
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo 'never' > /sys/kernel/mm/transparent_hugepage/defrag
永久设置方法：
cat <<EOF >> /etc/rc.local
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
EOF
chmod +x /etc/rc.local
4.5 NUMA优化：绑定Spark任务到特定NUMA节点以优化内存访问
numactl --interleave=all /opt/spark/bin/spark-submit ...
或使用绑定方式强制节点亲和：
numactl --membind=0 --cpubind=0 ./start_spark_job.sh
4.6 优化Spark执行参数（防止堆外内存溢出）
spark.executor.memory=16g
spark.executor.memoryOverhead=4g
spark.memory.fraction=0.6
spark.memory.storageFraction=0.3
备注：合理预留堆外内存空间可以防止 shuffle spill 时Swap被频繁使用。
五、测试结果与性能收益
我分别在优化前后执行同样的Spark SQL批处理任务，记录如下：
| 项目 | 优化前 | 优化后 |
|---|---|---|
| 总任务时间（秒） | 325 | 241（下降26%） |
| 平均I/O等待时间（%wa） | 15.2% | 5.8% |
| swap使用量 | 2.4GB | 250MB |
| executor被kill次数 | 3次 | 0次 |
香港服务器在运行高内存压力的大数据任务时，虚拟内存配置往往被忽视。通过精细化控制Swap使用策略，引入zram替代、优化NUMA亲和性和调优Spark内存参数，可以显著降低I/O负担和作业失败率，提升整体吞吐能力。后续我还将结合cgroups与systemd进一步限制Swap用量，确保系统稳定性。
在香港这样网络和存储资源成本较高的环境下，这种基于内核层面和服务层并行调优的方式，已经成为我部署每一台大数据节点的标准流程。
