3、操作系统层瓶颈诊断：CPU上下文切换、内存Swap与大页、文件系统与IO调度器
各位好，我是老张。在券商系统里摸爬滚打这么多年，我越来越觉得——操作系统就像地基。你上层应用写得再花哨，地基不稳，行情一波动，系统说崩就崩。今天咱们就聊聊操作系统层的三个核心瓶颈点：CPU上下文切换、内存Swap与大页、文件系统与IO调度器。
说白了，这三块就是操作系统给咱们交易系统设下的三道坎。跨不过去，延迟就上不去。我见过太多团队，代码优化到极致了，结果发现瓶颈在OS层，那叫一个憋屈。
3.1 CPU上下文切换：看不见的隐形杀手
先问个问题：你的CPU到底在忙什么？
很多人看CPU使用率不高，就觉得系统很闲。其实不然。CPU可能正在忙着做「上下文切换」——说白了，就是在不同线程、进程之间来回跳。每一次切换，都有代价。
上下文切换到底有多贵？
我举个例子。一次CPU上下文切换，大概需要几微秒。听起来不多对吧？但你的交易系统一秒钟可能要处理几万笔订单，每笔订单涉及几十次系统调用。你算算，光切换开销就吃掉多少时间？
我在项目中遇到过一件事：某券商的核心交易节点，CPU使用率只有30%，但延迟就是下不来。我上去一看，vmstat 的 cs（context switch）列，每秒超过10万次。嗯，找到问题了。
关键指标：用 vmstat 1 观察 cs 列。如果每秒超过5万次，就要警惕了。超过10万次，基本可以断定上下文切换是瓶颈。
怎么诊断？两个命令搞定。
第一个是 vmstat。看 cs 和 in（中断）两列。如果 cs 高但 in 不高，说明是线程调度导致的切换。如果两者都高，那可能是硬件中断太频繁。
# 每秒输出一次，重点关注 cs 列
vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 2048576 1024 4194304 0 0 0 0 1200 45000 15 10 75 0 0
第二个是 pidstat -w。它能告诉你每个进程的上下文切换次数。我习惯先跑 vmstat 看整体，再用 pidstat 定位到具体进程。
# 查看每个进程的上下文切换情况
pidstat -w 1
Linux 4.18.0-305.el8.x86_64 (hostname) 01/15/2024 _x86_64_ (32 CPU)
10:32:15 AM UID PID cswch/s nvcswch/s Command
10:32:16 AM 0 12345 3200.00 150.00 java
10:32:16 AM 999 23456 2800.00 80.00 nginx
我的小技巧：看 nvcswch/s（非自愿上下文切换）。这个值高，说明线程在争抢CPU，往往是线程数设置过多导致的。我曾经把一个交易进程的线程池从64降到16，上下文切换直接降了70%。
避坑指南：我曾经遇到一个案例，某团队把业务线程数设成了CPU核数的4倍。他们觉得这样能提高吞吐。结果呢？上下文切换爆炸，延迟反而翻倍。记住：对于计算密集型任务，线程数 = CPU核数 + 1 就够了。IO密集型可以适当多些，但别超过2倍。
3.2 内存Swap与大页（HugePages）：别让内存拖后腿
内存这块，我见过最坑的就是Swap。说白了，Swap就是操作系统把内存里不常用的数据挪到磁盘上。但磁盘比内存慢几个数量级。一旦触发Swap，你的交易延迟直接崩盘。
Swap是怎么发生的？
当物理内存不够用时，OS会把一些内存页换到磁盘的Swap分区。等需要时再换回来。这个过程叫「页交换」。一次页交换，少则几毫秒，多则几十毫秒。在交易系统里，这就是灾难。
我记得有一次，某交易系统在收盘前突然延迟飙升。我一看 vmstat 的 si 和 so 列，数值非零。再查内存使用，发现JVM堆外内存泄漏了。嗯，Swap就是那个报警器。
警告：只要 vmstat 的 si（swap in）或 so（swap out）大于0，就说明系统已经在用Swap了。对于交易系统，这绝对不可接受。必须立即处理。
# 检查Swap使用情况
vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 204800 1048576 1024 4194304 0 0 0 0 1200 45000 15 10 75 0 0
大页（HugePages）是什么？
操作系统管理内存的基本单位是「页」。默认是4KB。对于交易系统这种需要大量内存的应用，4KB的页太小了。CPU需要频繁查页表，TLB（页表缓存）很容易失效。
大页就是把页大小从4KB提升到2MB甚至1GB。好处很明显：
- TLB覆盖范围更大，减少缺页中断
- 页表更小，内存访问更快
- 减少TLB miss，提升内存访问性能
我建议所有交易系统都开启大页。尤其是Java应用，配合 -XX:+UseLargePages 参数，效果立竿见影。
# 查看当前大页配置
cat /proc/meminfo | grep -i huge
AnonHugePages: 20480 kB
HugePages_Total: 1024
HugePages_Free: 512
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
配置建议：大页数量 = 应用内存 / 大页大小。比如你的JVM分配了4GB内存，大页大小2MB，那就需要2048个大页。记得在 /etc/sysctl.conf 里设置 vm.nr_hugepages=2048。
避坑指南：我曾经遇到一个坑——开启大页后，应用启动报错。原因是OS预留的大页不够。记住：大页是预分配的，不是按需分配的。你得算好应用需要多少，提前预留。否则应用启动时拿不到大页，会回退到普通页，性能反而下降。
3.3 文件系统与IO调度器：磁盘那点事
文件系统和IO调度器，是很多人容易忽略的瓶颈。你想想看，交易系统要写日志、写数据库、读配置文件。这些IO操作，如果调度不当，延迟会很高。
IO调度器选哪个？
Linux有几种IO调度器：cfq、deadline、noop、mq-deadline、kyber 等。对于交易系统，我推荐 deadline 或 mq-deadline。
为什么？因为 deadline 对读写请求有超时机制。它保证每个请求在deadline之前得到处理。这对交易系统这种对延迟敏感的场景特别友好。
# 查看当前IO调度器
cat /sys/block/sda/queue/scheduler
[mq-deadline] kyber none
# 临时修改IO调度器
echo mq-deadline > /sys/block/sda/queue/scheduler
用iostat看IO性能
iostat 是我最常用的IO诊断工具。重点关注 await（平均IO等待时间）和 %util（磁盘利用率）。
# 查看磁盘IO性能
iostat -x 1
Device r/s w/s rkB/s wkB/s await svctm %util
sda 120.00 80.00 4800.00 3200.00 2.50 0.80 16.00
如果 await 超过10ms，说明磁盘响应慢了。如果 %util 接近100%，说明磁盘已经饱和。
关键指标：对于交易系统，await 应该控制在5ms以内。超过10ms就要排查了。如果是SSD，await 应该在1ms以内。
用blktrace做深度分析
当 iostat 告诉你磁盘有问题，但不知道具体是哪个进程、哪个文件导致的，就该 blktrace 出场了。
# 跟踪sda的IO事件
blktrace -d /dev/sda -o - | blkparse -i -
# 输出示例
8,0 0 1 0.000000000 12345 A W 123456 + 8 <- (8,0) 123456
8,0 0 2 0.000001000 12345 Q W 123456 + 8 [java]
8,0 0 3 0.000002000 12345 G W 123456 + 8 [java]
8,0 0 4 0.000003000 12345 D W 123456 + 8 [java]
8,0 0 5 0.000010000 12345 C W 123456 + 8 [java]
每一行代表一个IO事件。A是插入请求，Q是进入队列，G是获取请求，D是下发到磁盘，C是完成。从D到C的时间，就是磁盘实际处理时间。
我的经验：用 blktrace 配合 btt 工具，可以生成IO延迟分布图。我曾经用这个工具发现，某个日志文件的写入延迟特别高，原因是文件系统块大小设置不合理。改成4K对齐后，延迟降了30%。
文件系统选型建议
对于交易系统，我推荐使用 XFS 或 ext4。XFS对大文件和高并发场景支持更好。ext4更成熟稳定。我个人习惯用XFS，尤其是日志文件系统，XFS的并发写入性能比ext4好不少。
记得挂载时加上 noatime 选项，避免每次访问都更新文件访问时间。这个优化虽然小，但积少成多。
# 推荐挂载参数
mount -t xfs -o noatime,nodiratime,allocsize=1m /dev/sda1 /data
注意：不要使用 barrier 或 nobarrier 参数。对于交易系统，数据一致性比性能更重要。默认的barrier行为是安全的。
小结
操作系统层的瓶颈诊断，说白了就是三件事：看CPU在忙什么（上下文切换）、看内存够不够用（Swap和大页）、看磁盘快不快（IO调度和文件系统）。
我个人的诊断流程是这样的：先用 vmstat 扫一遍，看CPU和内存有没有异常。再用 iostat 看磁盘。如果发现问题，用 pidstat 和 blktrace 定位到具体进程和文件。这套组合拳，基本能覆盖90%的OS层问题。
记住：操作系统不是黑盒。它给你提供了足够的工具，关键是你得会用。下次系统出问题，别急着改代码，先看看OS层有没有猫腻。
公众号:蓝海资料掘金营，微信deep3321