Linux Performance Architecture
很多人在分析 Linux 性能时，只关注 CPU 使用率或者磁盘 IO。
实际上，一次用户请求要经过 Linux 系统的多个层次，每一层都有可能成为性能瓶颈。
因此，在学习各种性能工具之前，更重要的是先建立一张完整的 Linux Performance Architecture（Linux 性能架构图）。
Linux Performance Stack
下面是一条典型的请求路径：
UserSpace
┌─────────────────────────────────────────────┐
│Application│
│Nginx / MySQL / Redis / Java / Go│
└─────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│glibc│
│malloc()printf()read()write()│
└─────────────────────────────────────────────┘
│
▼
════════════════ System Call ═══════════════════
read()write() open() epoll()
│
▼
══════════════ Kernel Space ════════════════════
┌────────────────────────────┐
│Scheduler│
│CFSRT Deadline│
└────────────────────────────┘
│
┌────────────────────────────┐
│MemoryManager│
│Page Cache Slab NUMA THP│
└────────────────────────────┘
│
┌────────────────────────────┐
│VirtualFilesystem│
│ext4 XFS OverlayFS│
└────────────────────────────┘
│
┌────────────────────────────┐
│DeviceDriver│
│NVMe NIC GPU Block Driver│
└────────────────────────────┘
│
▼
══════════════ Hardware ═══════════════════════
CPU
Memory
SSD/ NVMe
NetworkCard
GPU
整个调用链从应用开始，最终落到硬件执行。
任何一层出现瓶颈，都可能导致系统性能下降。
第一层：Application（应用程序）
性能分析通常从应用开始。
例如：
●Nginx
●MySQL
●Redis
●Kafka
●Java
●Go
●Python
需要关注：
●请求数量（QPS）
●响应时间（Latency）
●错误率（Error Rate）
●并发连接数
●锁竞争
●GC（Java）
如果应用本身存在逻辑问题，再优化内核也无法解决。
第二层：glibc
大多数应用不会直接调用系统调用，而是先经过 glibc。
例如：
read()
write()
malloc()
free()
pthread_create()
这些 API 会进一步封装 Linux Kernel 的 System Call。
例如：
malloc()
│
├──brk()
└──mmap()
又例如：
printf()
↓
write()
↓
sys_write()
因此，很多性能问题实际上发生在库函数与系统调用之间。
第三层：System Call
这是 User Space 与 Kernel Space 的分界线。
典型系统调用包括：
read()
write()
open()
close()
accept()
connect()
epoll_wait()
futex()
系统调用意味着：
●用户态切换到内核态
●保存 CPU 上下文
●执行内核代码
●返回用户态
如果系统调用过于频繁，例如大量小包网络通信或频繁磁盘读写，就会带来明显的上下文切换开销。
第四层：Kernel
进入内核后，请求会根据类型进入不同的子系统。
Linux Kernel 并不是一个整体，而是由多个核心模块组成。
最重要的几个模块包括：
●Scheduler
●Memory Manager
●Virtual Filesystem
●Networking Stack
●Block Layer
●Driver
这些模块共同决定了 Linux 的整体性能。
第五层：Scheduler（调度器）
CPU 性能问题几乎都发生在这里。
Scheduler 负责：
●哪个线程运行
●运行多久
●是否需要抢占
●CPU Affinity
●Load Balance
典型性能指标：
●CPU Utilization
●Run Queue
●Context Switch
●Load Average
常见工具：
top
mpstat
pidstat
perf sched
第六层：Memory Manager（内存管理）
现代服务器大量性能问题实际上来自内存，而不是 CPU。
Linux Memory Manager 负责：
●Virtual Memory
●Page Cache
●Slab
●NUMA
●Huge Page
●Swap
常见问题包括：
●Page Fault
●Cache Miss
●NUMA Remote Access
●Memory Fragmentation
●OOM
常见工具：
vmstat
free
numastat
perf mem
第七层：Filesystem（文件系统）
几乎所有数据库最终都会经过文件系统。
Linux VFS（Virtual Filesystem）负责统一管理：
●ext4
●XFS
●Btrfs
●OverlayFS
性能关注点包括：
●Page Cache
●Buffered IO
●Direct IO
●Journaling
●Metadata
典型工具：
iostat
iotop
blktrace
第八层：Device Driver（设备驱动）
驱动负责与硬件通信。
例如：
存储：
NVMe Driver
SATA Driver
VirtIO Block
网络：
Intel ixgbe
mlx5
ENA
VirtIO Net
GPU：
NVIDIA Driver
驱动层常见问题包括：
●Interrupt
●DMA
●Queue Depth
●Ring Buffer
第九层：Hardware（硬件）
最终，请求会落到真实硬件。
包括：
CPU
负责计算。
Memory
负责数据访问。
SSD / NVMe
负责持久化存储。
NIC（Network Interface Card）
负责网络收发。
GPU
负责 AI、图形和高性能计算。
如果硬件已经达到极限，再优化软件也无法获得明显收益。
如何定位性能瓶颈？
一次性能分析通常遵循自上而下的思路：
Application
│
▼
System Call
│
▼
Scheduler
│
▼
Memory
│
▼
Filesystem
│
▼
Driver
│
▼
Hardware
如果发现某一层已经成为瓶颈，就可以停止继续向下分析。
例如：
●QPS 很低 → 先检查应用逻辑。
●CPU Run Queue 很长 → 调度器可能是瓶颈。
●Page Fault 激增 → 内存可能存在问题。
●Disk Queue 持续堆积 → 存储成为瓶颈。
●Packet Loss 增多 → 网络或驱动可能异常。
小结
Linux 性能分析的核心，不是记住多少命令，而是理解一次请求在系统中的完整路径。
从 Application → glibc → System Call → Kernel → Scheduler → Memory → Filesystem → Driver → Hardware，每一层都承担着不同的职责，也都有可能成为性能瓶颈。
建立这张性能架构图后，再学习 top、vmstat、iostat、perf、sar、bpftrace 等工具时，就能够明确每个工具对应的是哪一层，从而更高效地定位和解决性能问题。
