Linux 内存管理深度解析：从虚拟内存到 OOM Killer 实战指南

前言：为什么你需要理解 Linux 内存管理

在 Linux 系统运维和开发中，内存问题是最常见也是最棘手的故障类型之一。应用突然被 OOM Killer 杀死、服务器 Swap 使用率飙升、内存泄漏导致的性能衰减——这些问题的根因往往隐藏在 Linux 内核的内存管理机制中。很多开发者对 Linux 内存的理解停留在”free -m 看还剩多少内存”的层面，一旦遇到”内存明明还有很多为什么 OOM 了”或者”Cache 占了几十个 G 要不要清掉”这类问题就束手无策。

本文将从内核源码和实际运维经验出发，深入剖析 Linux 内存管理的核心机制，包括虚拟内存架构、页表与多级页表、物理内存分配器、Slab 缓存、VMA 管理、Page Cache、Swap 机制、OOM Killer 决策逻辑，以及一套可落地的内存问题诊断方法论。文章会提供大量可以实际运行的命令和代码示例，帮助你在自己的服务器上验证和理解。

文中示例基于 Linux 5.15 LTS 内核（本文运行的服务器内核版本），但大部分内容适用于 4.x 至 6.x 系列内核。

Linux Server Memory Architecture

一、Linux 虚拟内存架构

1.1 虚拟地址空间布局

Linux 采用虚拟内存管理，每个进程拥有独立的 4GB（32位）或 128TB（64位）虚拟地址空间。在 x86_64 架构下，地址空间被划分为用户空间和内核空间两部分，以经典的分界线 0x00007fffffffffff 为界：

用户空间（0x0000000000000000 – 0x00007fffffffffff）：每个进程独立，包含代码段、数据段、堆、栈、共享库映射区域
内核空间（0xffff800000000000 – 0xffffffffffffffff）：所有进程共享，包含内核代码、模块、直接映射区（ZONE_NORMAL）、vmalloc 区域、固定映射区等

可以通过

1	/proc/<PID>/maps

查看任意进程的虚拟地址空间布局：


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# 查看当前 shell 进程的虚拟地址空间

cat /proc/$$/maps | head -20



# 输出示例：

# 55a8e3c00000-55a8e3e00000 r-xp 00000000 08:01 1234567  /usr/bin/bash

# 55a8e3e00000-55a8e3f00000 r--p 00000000 08:01 1234567  /usr/bin/bash

# 55a8e3f00000-55a8e4000000 rw-p 00000000 08:01 1234567  /usr/bin/bash

# 55a8e5800000-55a8e5a00000 rw-p 00000000 00:00 0        [heap]

# 7f0a00000000-7f0a00100000 rw-p 00000000 00:00 0

# 7f0a7c000000-7f0a7c100000 rw-p 00000000 00:00 0

# 7f0a7d000000-7f0a7d100000 ---p 00000000 00:00 0

# 7f0a7d100000-7f0a7d700000 rw-p 00000000 00:00 0

# 7f0a7e000000-7f0a7e100000 ---p 00000000 00:00 0

# 7f0a7e100000-7f0a7e700000 rw-p 00000000 00:00 0

# 7f0a7e700000-7f0a7e800000 ---p 00000000 00:00 0

# 7f0a7e800000-7f0a7ef00000 rw-p 00000000 00:00 0

# 7f0a7ef00000-7f0a7f000000 ---p 00000000 00:00 0

# 7f0a7f000000-7f0a7f700000 rw-p 00000000 00:00 0

# 7f0a7f700000-7f0a7f800000 ---p 00000000 00:00 0

# 7f0a7f800000-7f0a7ff00000 rw-p 00000000 00:00 0

# 7f0a7ff00000-7f0a80000000 ---p 00000000 00:00 0

# 7f0a80000000-7f0a81000000 rw-p 00000000 00:00 0 [stack]

每行格式为：

1	起始地址-结束地址权限偏移量主设备号:次设备号 inode 路径

。权限字段中 r=读、w=写、x=执行、p=私有（写时复制）、s=共享。

1.2 多级页表与地址转换

x86_64 架构使用 4 级页表（PGD、P4D、PUD、PMD、PTE）将虚拟地址转换为物理地址。随着 5-level paging 在较新内核中的引入，页表扩展到 5 级。每级页表将虚拟地址的一部分作为索引，逐级查找到最终的物理页帧号（PFN）。

Linux 内核中地址转换的核心数据结构是

1	struct page

，每个物理页框对应一个这样的结构体，定义在

1	include/linux/mm_types.h

中：


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// 简化后的 struct page 定义

struct page {

    unsigned long flags;        // 页状态标志（PG_locked, PG_dirty, PG_swapbacked 等）

    union {

        struct {

            struct list_head lru;   // LRU 链表节点

            struct address_space *mapping;  // 指向所属的 address_space

            pgoff_t index;          // 在文件中的偏移量

            unsigned long private;  // 私有数据

        };

        struct {        // 用于 slab 分配器

            struct slab *slab_page;

            unsigned int units;

        };

        struct {        // 用于页表

            unsigned long pt_mm;

            struct rcu_head pt_rcu_head;

        };

    };

    union {

        atomic_t _mapcount;     // 映射到此页的页表项数量

        unsigned int page_type;

    };

    atomic_t _refcount;         // 引用计数

    unsigned long memcg_data;   // 内存控制组数据

};

要查看系统当前的页表内存开销，可以运行：


1
2
3
4
5
# 查看页表占用的内存（单位：KB）

grep PageTables /proc/meminfo



# 查看某个进程的页表开销

grep PageTables /proc/$(pidof mysqld)/smaps | head -1

二、物理内存分配器

2.1 伙伴系统（Buddy System）

Linux 内核物理内存管理的基石是伙伴系统（Buddy Allocator）。它将物理内存按 2 的幂次划分为块（order = 0 对应 4KB，order = 1 对应 8KB，依此类推，最大 order = 10 对应 4MB），相同大小的连续块互为”伙伴”，可以合并为更大的块。这种设计有效解决了外部碎片问题。

伙伴系统的核心数据结构是

1	struct free_area

，每个 order 对应一个链表，链表中挂载着空闲的连续内存块：


1
2
3
4
5
6
7
8
9
10
11
12
// 简化版核心分配函数 __alloc_pages 的调用路径

// get_page_from_freelist → rmqueue → __rmqueue → expand



// 查看当前系统各 order 的空闲页数

cat /proc/buddyinfo



# 输出示例：

# Node 0, zone      DMA      1      0      0      1      2      1      1      0      1      1      3

# Node 0, zone    DMA32   3462   1398    478    185    105     62     35     19      9      5    174

# Node 0, zone   Normal  12345   6789   2345   1234    567    234    123     67     34     12    450



# 从左到右：order 0 (4K), order 1 (8K), ... order 10 (4M)

当系统内存碎片化严重时，即使有大量空闲内存，也可能无法分配一个连续的 order 较大的内存块。这是在内存压力下常见的”内存充足但分配失败”场景的根因。可以通过

1	/proc/pagetypeinfo

查看更详细的碎片信息。

2.2 SLAB 分配器

伙伴系统按页分配，但内核中大量需要小对象（如

1	task_struct

、

inode

、

dentry

等），直接使用伙伴系统会造成巨大的内部碎片。SLAB 分配器（以及后继的 SLUB 和 SLOB）正是为了解决这个问题——它从伙伴系统获取整页，然后将页面划分为特定大小的对象缓存。

当前主流内核默认使用 SLUB 分配器（CONFIG_SLUB=y），它相比 SLAB 更为简洁高效：


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 查看 SLUB 缓存统计

cat /proc/slabinfo | head -20



# 输出示例：

# slabinfo - version: 2.1

# # name            &lt;active_objs&gt; &lt;num_objs&gt; &lt;objsize&gt; &lt;objperslab&gt; &lt;pagesperslab&gt; ...

# dentry            123456  123456    192     21    1 : tunables  120   60    8 : slabdata 5879 5879      0

# inode_cache        45678   45678    640     12    2 : tunables   54   27    8 : slabdata 3806 3806      0

# task_struct         1234    1234   3840      8    8 : tunables   24   12    8 : slabdata  154  154      0

# kmalloc-256         56789   56789    256     16    1 : tunables  120   60    8 : slabdata 3549 3549      0

# kmalloc-192         23456   23456    192     21    1 : tunables  120   60    8 : slabdata 1117 1117      0



# 查看各 slab 缓存占用的总内存

# 注意：某些 slab 缓存（如 dentry、inode）在内存压力下可回收

echo "=== Top 10 SLAB Caches by Memory ==="

awk '{if(NR>1) printf "%-20s %8d KB\n", $1, $5*$7*4}' /proc/slabinfo | sort -rn -k2 | head -10

常见的 slab 缓存包括：

缓存名称	对象大小	用途	是否可回收
dentry	192-256 字节	目录项缓存	✅ 可回收
inode_cache	640-1024 字节	inode 缓存	✅ 可回收
task_struct	~3840 字节	进程描述符	❌ 不可回收
kmalloc-*	各种大小	通用内核内存分配	❌ 不可回收
radix_tree_node	576 字节	基数树节点（页缓存索引）	✅ 可回收

三、VMA（虚拟内存区域）管理

每个进程的虚拟地址空间被划分为多个 VMA（Virtual Memory Area），每个 VMA 描述一段连续的虚拟地址区间及其属性（权限、映射类型、文件映射等）。VMA 由内核中的

1	struct vm_area_struct

表示，组织在红黑树（RB tree）中以提高查找效率。


1
2
3
4
5
6
7
8
9
10
11
12
// VMA 核心结构（简化版）

struct vm_area_struct {

    unsigned long vm_start;    // 起始地址

    unsigned long vm_end;      // 结束地址（不包含）

    struct mm_struct *vm_mm;   // 所属进程的内存描述符

    unsigned long vm_flags;    // 标志位（VM_READ, VM_WRITE, VM_EXEC, VM_SHARED 等）

    struct rb_node vm_rb;      // 红黑树节点

    struct list_head anon_vma_chain; // 匿名页反向映射链

    struct vm_operations_struct *vm_ops; // VMA 操作函数指针

    struct file *vm_file;      // 映射的文件（NULL 表示匿名映射）

    unsigned long vm_pgoff;    // 文件映射的页偏移量

};


1
2
3
4
5
6
# 使用 pmap 查看进程的 VMA 详情

pmap -x $(pidof nginx) | head -30



# 或者查看 /proc/PID/smaps 获取更详细的每个 VMA 的内存使用统计

# 包括 RSS、PSS、脏页、Swap 等

cat /proc/$(pidof nginx)/smaps | head -80

VMA 的合并与分裂是内核内存管理的重要优化手段。当相邻的 VMA 具有相同的权限和映射属性时，内核会尝试合并它们以减少 VMA 数量。可以通过

1	/proc/<PID>/maps

的行数估算 VMA 数量：


1
2
3
4
5
6
7
8
9
# 统计某进程的 VMA 数量

echo "VMA count for PID 1:"

cat /proc/1/maps | wc -l



# 查看最大 VMA 数量限制

cat /proc/sys/vm/max_map_count



# 在内存压力大的应用（如 Elasticsearch、Chrome）中建议增大此值

# sysctl -w vm.max_map_count=262144

四、Page Cache 与回写机制

4.1 Page Cache 架构

Page Cache 是 Linux 文件系统性能的核心。当读取文件时，内核将文件内容缓存在物理内存中（页面缓存）。当再次读取同一文件时，直接从内存返回，避免了磁盘 I/O。Page Cache 使用基数树（radix tree，在较新内核中已替换为 xarray）进行索引，通过

1	struct address_space

管理。


1
2
3
4
5
6
7
8
9
# 查看当前系统 Page Cache 使用量

echo "=== Page Cache 统计 ==="

grep -E "^(Cached|Buffers|SwapCached|Active|Inactive)" /proc/meminfo



# 清理 Page Cache（不推荐在生产环境随意执行）

# sync && echo 3 > /proc/sys/vm/drop_caches



# 查看某个文件的缓存情况（使用 fincore 或 vmtouch）

# vmtouch /var/log/syslog

在 Linux 5.15 内核中，Page Cache 的管理引入了多项优化，包括：

Shadow 条目：当内存页被回收后，保留一个”影子”在基数树中，用于检测后续的页面访问模式
批量回收：在一次回收操作中回收多个页面，减少锁竞争
按需加载：通过 fadvise/madvise 系统调用，应用可以主动提示内核预取或释放缓存

4.2 脏页回写

当文件被写入时，数据先写入 Page Cache（标记为脏页），然后内核在后台异步将脏页写回磁盘。这种延迟写入机制显著提升了写入性能，但也带来了数据丢失风险。脏页回写由以下内核参数控制：


1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 查看脏页回写相关参数

sysctl -a | grep dirty



# 关键参数说明：

# vm.dirty_ratio = 20           # 脏页占可用内存的最大百分比（达到此值后同步写阻塞）

# vm.dirty_background_ratio = 10 # 脏页占比达到此值时后台内核线程开始回写

# vm.dirty_expire_centisecs = 3000  # 脏页超过此时间（0.01秒为单位）必须回写

# vm.dirty_writeback_centisecs = 500  # 回写线程唤醒间隔（0.01秒为单位）



# 推荐的生产环境配置（针对数据库服务器）

# 降低 dirty_ratio 以减少写入阻塞时的数据量

sysctl -w vm.dirty_ratio=10

sysctl -w vm.dirty_background_ratio=3

sysctl -w vm.dirty_expire_centisecs=3000

需要注意的是，Page Cache 和 Swap 是完全不同的概念。Page Cache 是文件内容的内存缓存，在内存压力下可以安全地丢弃（如果是脏页需要先回写）；而 Swap 是匿名页（如堆、栈）被换出到磁盘后的存储位置。

五、Swap 机制与交换策略

5.1 Swap 的工作方式

当物理内存不足时，内核的内存回收机制会尝试将不常用的内存页换出到 Swap 分区或 Swap 文件。Swap 操作涉及页面换出（swap out）和页面换入（swap in）两个过程，内核使用

1	swap_info_struct

管理每个 Swap 区域。


1
2
3
4
5
6
7
8
# 查看 Swap 使用情况

swapon --show

free -h



# 查看 Swap 详细统计

cat /proc/swaps

# 查看 Swap 换入/换出累计字节数

grep -E "pswpin|pswpout" /proc/vmstat

5.2 swappiness 参数的深入理解

1	vm.swappiness

是最容易被误解的内核参数之一。它并非”内存使用超过多少百分比就开始使用 Swap”，而是控制内核在内存回收时倾向于回收匿名页（换出到 Swap）还是文件页（丢弃 Page Cache）的权重：


1
2
3
4
5
6
7
8
9
10
11
12
13
# 查看当前 swappiness

cat /proc/sys/vm/swappiness



# swappiness 值的含义：

# 0   - 除非绝对必要（内存严重不足），否则不进行 Swap 换出

# 1   - 与 0 接近，但允许最小程度的 Swap（这是内核文档建议的最小值）

# 60  - 默认值，平衡的回收策略

# 100 - 积极换出匿名页



# 内核源码中的回收倾向计算（简化版）：

# anon_prio = swappiness

# file_prio = 200 - swappiness

# 回收时按优先级选择：anon_prio 越高，越倾向于回收匿名页（即换出到 Swap）

对于数据库服务器（MySQL、PostgreSQL），建议将 swappiness 设为 1-10，因为数据库通常有自己的 Buffer Pool 管理内存，不希望内核频繁换出数据库进程的匿名内存页。对于 Kubernetes 节点，建议根据 workload 特性调整。

5.3 实战：创建和使用 Swap 文件


1
2
3
4
5
6
7
8
9
10
11
# 创建 4GB Swap 文件（适用于没有 Swap 分区的场景）

dd if=/dev/zero of=/swapfile bs=1M count=4096 status=progress

chmod 600 /swapfile

mkswap /swapfile

swapon /swapfile



# 永久生效：写入 /etc/fstab

echo "/swapfile none swap sw 0 0" >> /etc/fstab



# 查看优先级 - 多个 Swap 设备时优先级高的优先使用

swapon -s

六、OOM Killer 深度解析

6.1 OOM Killer 触发与决策流程

当内核内存分配失败时，会调用

1	__alloc_pages_slowpath()

尝试各种回收手段（包括异步回收、同步回收、压缩等），如果仍然无法满足请求，最终调用

1	out_of_memory()

触发 OOM Killer。整个决策链路如下：

调用路径：alloc_pages → __alloc_pages_nodemask → __alloc_pages_slowpath → out_of_memory → select_bad_process
候选进程评分：由
1
oom_badness()

函数计算每个进程的 badness 分数
终止执行：内核向被选中的进程发送 SIGKILL 信号


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// OOM 评分函数的核心逻辑（简化版）

// 源码位置：mm/oom_kill.c

unsigned long oom_badness(struct task_struct *p, struct mem_cgroup *memcg,

                          const nodemask_t *nodemask, unsigned long totalpages)

{

    long points;

    long adj;



    // 基础分 = 进程的 RSS + 页表 + Swap 使用量

    points = get_mm_rss(p->mm) + get_mm_counter(p->mm, MM_SWAPENTS) +

             mm_pgtables_bytes(p->mm) / PAGE_SIZE;

    

    // 应用 oom_score_adj 调整

    adj = (long)p->signal->oom_score_adj;

    if (adj == OOM_SCORE_ADJ_MIN) {

        return 0;  // 完全免疫

    }

    

    // 计算最终分数，adj 为 [-1000, 1000] 范围

    points = (points * (1000 + adj)) / 1000;

    

    return points;

}

6.2 OOM 相关配置与调试


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 查看每个进程的 OOM 评分

for pid in $(ps -eo pid --no-headers | head -20); do

    score=$(cat /proc/$pid/oom_score 2>/dev/null)

    adj=$(cat /proc/$pid/oom_score_adj 2>/dev/null)

    name=$(ps -p $pid -o comm= 2>/dev/null)

    echo "PID $pid ($name): oom_score=$score, oom_score_adj=$adj"

done



# 保护关键进程不被 OOM Killer 杀死

# 设置 oom_score_adj = -1000 使进程对 OOM 免疫

echo -1000 > /proc/$(pidof sshd)/oom_score_adj



# 或者使用 systemd 保护服务

cat /etc/systemd/system/sshd.service.d/override.conf

# [Service]

# OOMScoreAdjust=-1000



# 查看系统 OOM 事件记录

dmesg | grep -i "killed process\|oom-killer\|Out of memory"

# 或者使用 journalctl

journalctl -k | grep -i oom

从 Linux 5.11 内核开始，引入了 cgroup v2 的 OOM 控制改进，支持在 cgroup 范围内进行 OOM 管理。Kubernetes 环境中的 Pod 级别 OOM 处理正是基于此机制。

七、内存问题诊断实战

7.1 快速诊断命令清单

以下是一套我在生产环境中长期使用的内存问题诊断命令序列：


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# === 1. 系统级内存概览 ===

echo "=== 1. 系统内存概览 ==="

free -h

echo ""

echo "=== 2. Meminfo 关键指标 ==="

grep -E "^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapCached|Active|Inactive|Dirty|Writeback|AnonPages|Mapped|Shmem|Slab|SReclaimable|SUnreclaim|KernelStack|PageTables|NFS_Unstable|Bounce|WritebackTmp|CommitLimit|Committed_AS|VmallocTotal|VmallocUsed|VmallocChunk|Percpu|HardwareCorrupted|AnonHugePages|ShmemHugePages|ShmemPmdMapped|CmaTotal|CmaFree|HugePages_Total|HugePages_Free|HugePages_Rsvd|HugePages_Surp|Hugepagesize|DirectMap4k|DirectMap2M|DirectMap1G)" /proc/meminfo



echo ""

echo "=== 3. 内存压力指标 ==="

vmstat 1 5



echo ""

echo "=== 4. 进程级内存 TOP 10 ==="

ps aux --sort=-%rss | head -11



echo ""

echo "=== 5. 内存碎片状况 ==="

cat /proc/buddyinfo

7.2 内存泄漏检测

内存泄漏是长期运行服务中最常见的稳定性问题。以下是几种实用的检测方法：


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 方法1：观察进程 RSS 随时间的变化

while true; do

    echo "$(date +%H:%M:%S) RSS=$(ps -o rss= -p $(pidof myapp) | awk '{print $1/1024 " MB"}')"

    sleep 60

done



# 方法2：使用 /proc/PID/status 监控

watch -n 60 'cat /proc/$(pidof myapp)/status | grep -E "VmRSS|VmSize|VmPeak|VmSwap"'



# 方法3：使用 valgrind 检测（适合开发环境）

valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./myapp



# 方法4：使用 bpftrace 动态跟踪 malloc/free（不需要重启应用）

# 跟踪所有 malloc 调用

bpftrace -e 'kprobe:__kmalloc { @[comm, kstack] = count(); }' -c 'sleep 5'



# 方法5：内核内存泄漏检测（kmemleak）

echo scan > /sys/kernel/debug/kmemleak

cat /sys/kernel/debug/kmemleak

7.3 大页（Huge Pages）配置

对于内存密集型应用（数据库、JVM、DPDK），使用大页可以减少 TLB 缺失，显著提升性能。Linux 支持两种大页机制：

特性	传统 Huge Pages（Hugetlbfs）	透明大页（THP）
管理方式	手动分配，需预先预留	内核自动管理，透明
页大小	2MB 或 1GB（可配置）	2MB（默认），支持 1GB
碎片风险	低（提前预留）	高（可能导致内存碎片）
适用场景	数据库、DPDK、基数排序	通用场景（内核默认开启）
配置方法	hugepages= 内核参数	/sys/kernel/mm/transparent_hugepage/enabled


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 配置传统 Huge Pages

# 在内核启动参数中预留 1024 个 2MB 大页

# 在 /etc/default/grub 中：

# GRUB_CMDLINE_LINUX="hugepages=1024"

# 然后 update-grub 并重启



# 运行时配置（需要系统有足够的连续内存）

echo 1024 > /proc/sys/vm/nr_hugepages

cat /proc/meminfo | grep Huge



# 配置透明大页

echo always > /sys/kernel/mm/transparent_hugepage/enabled  # 开启

echo never > /sys/kernel/mm/transparent_hugepage/enabled   # 关闭

echo madvise > /sys/kernel/mm/transparent_hugepage/enabled # 仅通过 madvise 启用



# 对于数据库服务器（如 MongoDB），建议关闭 THP

# 因为 THP 可能导致内存碎片和延迟抖动

# 在 /etc/rc.local 中添加：

# if test -f /sys/kernel/mm/transparent_hugepage/enabled; then

#    echo never > /sys/kernel/mm/transparent_hugepage/enabled

# fi

八、内存 Control Group（cgroup v2）

在现代容器化环境中，cgroup 是内存资源隔离的核心。cgroup v2 从 Linux 5.2 开始逐渐成为默认，相比 v1 提供了更统一和简洁的接口：


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 查看 cgroup v2 内存控制

# 在 systemd 系统上，每个 systemd 服务都处于独立的 cgroup 中

cat /sys/fs/cgroup/system.slice/sshd.service/memory.current

cat /sys/fs/cgroup/system.slice/sshd.service/memory.max

cat /sys/fs/cgroup/system.slice/sshd.service/memory.swap.current

cat /sys/fs/cgroup/system.slice/sshd.service/memory.zswap.current



# cgroup v2 关键内存接口文件：

# memory.current        - 当前内存使用量（字节）

# memory.min            - 最低内存保证

# memory.low            - 低优先级回收保护

# memory.high           - 内存使用上限（软限制，触发异步回收）

# memory.max            - 内存使用上限（硬限制，触发 OOM）

# memory.swap.current   - 当前 Swap 使用量

# memory.swap.max       - Swap 使用上限

# memory.oom.group      - 是否对整个 cgroup 进行 OOM 而非单个进程



# 设置容器内存限制（Docker 自动处理）

# docker run --memory=1g --memory-swap=1g --memory-swappiness=0 myapp

九、总结与最佳实践

Linux 内存管理是一个庞大而精密的系统，本文从虚拟内存架构、物理内存分配器、VMA 管理、Page Cache、Swap 机制、OOM Killer 到实战诊断，覆盖了内存管理的核心环节。以下是几个关键的最佳实践建议：

理解”可用内存”的概念：
1
free -h

中的 available 字段才是真正可用的内存，它考虑了 Page Cache 可回收的部分。不要看到 used 高就认为内存不足。
不要随意清理 Page Cache：
1
echo 3 > /proc/sys/vm/drop_caches

会强制释放缓存，但释放后应用重新读取文件时反而会变慢。Page Cache 本来就是用来提高性能的。
合理配置 swappiness：数据库服务器设 1-10，Kubernetes 节点建议 10-30，桌面系统可以保持默认 60。
监控 OOM 事件：
1
journalctl -k | grep oom

应该成为日常巡检的一部分。频繁的 OOM 事件说明内存配置需要调整。
为关键进程设置 OOM 保护：通过
1
oom_score_adj

保护 sshd、监控 agent 等关键进程。
使用 cgroup v2 进行资源隔离：在容器化环境中，合理设置
1
memory.max

和

1
memory.high

可以避免单个容器影响整个节点。
关注内存碎片化：定期检查
1
/proc/buddyinfo

，如果低 order 的空闲块持续减少，说明碎片化加剧，可能需要考虑调整内核参数或重启服务。
使用现代诊断工具：bpftrace、perf、eBPF 等工具可以深入内核层面分析内存行为，比传统的
1
free

和

1
top

提供更精确的信息。

理解 Linux 内存管理机制不仅能帮助你解决生产环境中的内存问题，更能让你在设计系统时做出更明智的架构决策。希望本文能为你的 Linux 运维之路提供有价值的参考。