一、前置思考

1.1 应用层优化到头了，还能更快吗？

代码已经优化到极致，为什么高并发下还是卡？因为性能的瓶颈往往不在应用层，而在内核：

应用层优化: 算法、缓存、并发 (提升 2-10 倍)
内核层调优: 调度、内存、IO、网络 (再提升 2-5 倍)

服务器级场景: 数据库、容器、高并发网关
  → 内核参数不调 → 白花应用层功夫

1.2 内核调优的对象

调度器: 进程怎么分配 CPU (CFS/优先级/亲和性)
内存: 缓存回收、脏页回写、大页
IO: 磁盘怎么排队 (noop/deadline/cfq)
网络: 协议栈缓冲区、连接队列
SLAB: 内核对象缓存分配效率

1.3 调优的前提

⚠️ 调优是"权衡"，不是"越大越好"
  → 缓存调大 → 内存变少
  → 队列调大 → 延迟变高
  → 必须针对场景测量后调参

工具: sysctl / /proc 接口 / perf / sar

二、核心原理

2.1 sysctl 机制

sysctl: 内核运行时参数接口
  → /proc/sys/ 目录树
  → sysctl 命令读写
  → 参数分域:
      vm.*     内存管理
      kernel.* 内核核心
      net.*    网络协议栈
      fs.*     文件系统

永久生效: /etc/sysctl.conf
立即生效: sysctl -p / sysctl -w xxx=yyy

2.2 调度器参数

CFS (完全公平调度器):
  sched_min_granularity_ns: 进程最小运行时间片
    → 调小: 交互更灵敏 (桌面场景)
    → 调大: 吞吐更高 (服务器场景)

  sched_wakeup_granularity_ns: 唤醒抢占粒度
    → 调小: 新唤醒进程更快抢占 (低延迟)

NUMA 亲和性:
  numactl: 进程绑定到本地内存节点

CPU 亲和性:
  taskset: 进程绑定指定 CPU → 避免缓存漂移

2.3 内存与 IO 参数

vm.dirty_ratio: 脏页占内存比例上限
  → 到达后阻塞写入强制回写
  → 调大: 写入吞吐高、丢数据风险大
  → 调小: 回写更频繁、更安全

vm.swappiness: 交换倾向 (0-100)
  → 0: 尽量用内存，不换出 (服务器)
  → 100: 积极换出 (内存紧张设备)

IO 调度器:
  none/noop: 顺序访问性能最好 (SSD/NVMe)
  deadline: 均衡延迟与吞吐 (默认推荐)
  cfq: 公平分配带宽 (机械硬盘多进程)

fs.file-max: 系统最大打开文件数
  → 高并发服务器必须调大

三、源码/API 深度解析

3.1 核心调优命令全集

# ===== 调度器调优 =====
# 查看当前调度参数
sysctl kernel.sched_min_granularity_ns
# 交互型负载: 减小时间片 → 响应更快
sysctl -w kernel.sched_min_granularity_ns=2000000
sysctl -w kernel.sched_wakeup_granularity_ns=1500000

# ===== 内存调优 =====
# 查看内存状态
cat /proc/meminfo
# 服务器型: 减少交换，多留缓存
sysctl -w vm.swappiness=10
# 写性能优先: 提高脏页阈值
sysctl -w vm.dirty_ratio=30
sysctl -w vm.dirty_background_ratio=10

# ===== IO 调度器 =====
# 查看当前调度器
cat /sys/block/sda/queue/scheduler
# SSD 用 none (无队列调度，直接下发)
echo none > /sys/block/sda/queue/scheduler

# ===== 网络调优 =====
# 高并发连接: 调大文件句柄
sysctl -w fs.file-max=1048576
# TCP 缓冲区 (读写)
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
# TIME_WAIT 复用 (高并发短连接)
sysctl -w net.ipv4.tcp_tw_reuse=1
# 连接队列长度
sysctl -w net.core.somaxconn=65535

# 永久保存
echo "vm.swappiness=10" >> /etc/sysctl.conf
sysctl -p

3.2 SLAB 缓存参数

# SLAB: 内核对象缓存 (kmalloc 池)
# 查看 slab 状态
cat /proc/slabinfo

# 常用调优:
# 1. 高并发网络 → 扩大连接相关对象缓存
# 2. 频繁创建/销毁进程 → 调整 task_struct 缓存
# 3. slab 收缩时机
sysctl -w vm.shrink_slab=1  # 内存压力时主动收缩

# 大页内存 (HugeTLB): 减少 TLB 缺失
# 数据库/大数据场景收益巨大
echo 512 > /proc/sys/vm/nr_hugepages
# THP (透明大页) — 数据库类可能需关闭
echo never > /sys/kernel/mm/transparent_hugepage/enabled

3.3 调优验证工具

// 应用层观测内核行为 (ArkTS 侧)
import { os } from '@kit.BasicServicesKit';

// 观测系统负载与内存压力
function observeKernelStats(): string[] {
  const lines: string[] = [];
  // CPU 负载
  lines.push('CPU 负载: ' + os.getLoadAverage()[0].toFixed(2));
  // 可用内存
  lines.push('可用内存: ' + os.availableMemorySize + ' KB');
  // 系统信息
  lines.push('内核版本: ' + os.version);
  return lines;
}

四、企业级实战落地

4.1 场景化调优方案

场景	核心参数	目标
数据库	大页内存、swappiness=0、deadline IO	稳定低延迟
Web 网关	file-max、TCP 队列、TIME_WAIT 复用	高并发连接
容器平台	调度器参数、内存 cgroup 隔离	公平调度
车载系统	实时调度、抢占延迟最小	实时响应
IoT 设备	内存紧凑、swap 关闭、体积最小	低资源运行

4.2 完整示例：内核调优演示

@Entry
@ComponentV2
struct KernelTuneDemo {
  @Local logs: string[] = [];
  @Local state: string = '未开始';

  private runSchedDemo(): void {
    this.logs = [];
    this.state = '调度器调优';
    this.log('⚡ 调度器参数调优演示 (交互型场景)');
    this.log('默认参数:');
    this.log('  sched_min_granularity_ns = 3000000');
    this.log('  sched_wakeup_granularity_ns = 2000000');
    this.log('调优目标: UI 交互更灵敏');
    this.log('① 减小最小时间片: 3000000 → 2000000');
    this.log('   → 更多进程轮流运行 → 响应更快');
    this.log('② 减小唤醒抢占粒度: 2000000 → 1500000');
    this.log('   → 新事件唤醒的任务更快获得 CPU');
    this.log('③ 绑定 CPU: 前台任务 taskset 到固定核');
    this.log('   → 缓存命中率提升, 抖动减少');
    this.log('效果: 交互延迟 120ms → 45ms ✅');
  }

  private runMemNetDemo(): void {
    this.logs = [];
    this.state = '内存/网络调优';
    this.log('🌐 内存与网络参数调优 (服务器场景)');
    this.log('内存侧:');
    this.log('  vm.swappiness: 60 → 10 (少换出)');
    this.log('  vm.dirty_ratio: 20 → 30 (写吞吐↑)');
    this.log('  HugePages: 开启 512 页 (TLB 缺失↓)');
    this.log('网络侧:');
    this.log('  fs.file-max: 1024 → 1048576');
    this.log('  net.core.somaxconn: 128 → 65535');
    this.log('  tcp_tw_reuse: 0 → 1 (端口复用)');
    this.log('效果: 并发连接 3K → 60K');
    this.log('  P99 延迟 88ms → 32ms ✅');
  }

  build() {
    Column({ space: 12 }) {
      Text('🚀 内核级性能调优').fontSize(20).fontWeight(FontWeight.Bold)
      Text('状态: ' + this.state).fontSize(13).fontColor('#4FC3F7')

      Row({ space: 8 }) {
        Button('调度器调优').layoutWeight(1).height(40).fontSize(12)
          .onClick(() => this.runSchedDemo())
        Button('内存网络').layoutWeight(1).height(40).fontSize(12)
          .onClick(() => this.runMemNetDemo())
      }
      .width('100%')

      Scroll() {
        Column() {
          ForEach(this.logs, (l: string) => {
            Text(l).fontSize(11).lineHeight(18).fontColor('rgba(255,255,255,0.8)').width('100%')
          }, (l: string, i: number) => l + i)
        }.width('100%')
      }
      .layoutWeight(1).width('100%').scrollBar(BarState.Off)
    }
    .width('100%').height('100%').padding(16)
    .backgroundColor('#0D1B2A')
  }
}

4.3 调优方法论

1. 测量: 先拿到基线数据 (perf/sar 全指标)
2. 假设: 根据瓶颈提出参数假设
3. 单变量: 每次只改一个参数
4. 复测: 同场景对比前后数据
5. 归档: 记录参数与效果 → 形成调优手册
6. 回归: 压力测试验证长期稳定性

五、问题排查与性能优化

问题	原因	解决
参数改了无效	未生效/需重启	sysctl -p / 检查 /proc
延迟反而升高	参数过度激进	回退到折中值
内存不足告警	缓存调得过大	降低 dirty_ratio
连接被拒	队列/somaxconn 不足	调大 + 调文件句柄
磁盘写放大	IO 调度不当	SSD 用 none
数据库抖动	THP 大页分配卡顿	关闭 THP 用 HugeTLB

5.1 调优陷阱清单

1. 不要盲目抄参数: 场景不同参数不同
2. 先测量后调参: 无数据不调优
3. 单变量原则: 一次只改一个
4. 注意权衡: 吞吐↑可能延迟↑
5. 生产前回归: 调优必须在测试环境验证
6. 参数归档: 记录到配置管理，可回滚

六、高阶总结与最佳实践

1. 场景决定参数：交互型调调度器、服务器型调内存网络、数据库型调大页——没有万能参数。
2. 先测量再动手：基线数据是调优的起点，无测量不调优。
3. 权衡是常态：每次调参都是一次取舍，用数据说话而不是感觉。
4. 单变量迭代：一次改一个参数，才能确认因果。
5. 归档可回滚：参数变更纳入版本管理，出问题能一键回滚。

一句话记住：内核调优四步法——测量基线（perf/sar）→ 定位瓶颈（调度/内存/IO/网络/SLAB）→ 单变量调参（sysctl 一次一个）→ 复测归档（数据对比 + 可回滚）——场景决定参数，权衡决定取舍，数据决定结论。