1. 课程导论：进程调度与 Docker 性能的关系概述
在云原生与微服务架构中，Docker 容器已成为应用交付的标准单元。然而，容器化并非“零开销”的虚拟化——Linux 内核的进程调度器直接决定了容器内工作负载的 CPU 时间分配、响应延迟与吞吐量。本课程将深入剖析调度器参数如何影响 Docker 容器的性能表现，并给出可落地的调优实践。
1.1 为什么进程调度对容器性能至关重要？
Docker 容器本质上是宿主机上的一组受 cgroups 和 namespace 约束的进程。当多个容器共享同一套 CPU 资源时，内核的完全公平调度器（CFS）负责决定：
- 每个容器内的进程何时获得 CPU 时间片；
- 每个时间片的长度（粒度）；
- 在 CPU 争抢时如何分配权重（优先级）。
错误的调度参数配置会导致：
- CPU 饥饿：延迟敏感型容器（如 Redis、Nginx）频繁被调度出去；
- 上下文切换爆炸：时间片过短导致内核频繁切换进程，浪费 CPU 在调度开销上；
- 不公平抢占：高负载容器长时间霸占 CPU，影响其他容器的服务质量。
核心观点： 调度器是容器性能的“隐形天花板”。不调整调度参数，即使分配了足够的 CPU 配额，容器也可能无法达到预期的性能指标。
1.2 调度器参数与容器性能的映射关系
下表列出了 Linux CFS 调度器中最关键的参数，以及它们对 Docker 容器性能的直接影响：
| 调度参数 | 内核接口 | 对容器性能的影响 |
|---|---|---|
| sched_latency_ns | /proc/sys/kernel/sched_latency_ns | 目标调度延迟。值越小，交互性越好，但上下文切换开销增大；值越大，吞吐量提升，但延迟增加。 |
| sched_min_granularity_ns | /proc/sys/kernel/sched_min_granularity_ns | 进程最小运行时间片。过小导致频繁切换，过大则降低交互响应。 |
| sched_wakeup_granularity_ns | /proc/sys/kernel/sched_wakeup_granularity_ns | 唤醒抢占粒度。控制被唤醒进程能否立即抢占当前运行进程。对短任务容器（如 API 网关）影响显著。 |
| sched_nr_migrate | /proc/sys/kernel/sched_nr_migrate | 负载均衡时一次迁移的最大进程数。影响多核容器间的负载分布效率。 |
| cpu.cfs_period_us | /sys/fs/cgroup/cpu/docker/<id>/cpu.cfs_period_us | CFS 带宽控制的周期。通常固定为 100000（100ms），与 quota 配合限制容器 CPU 使用上限。 |
| cpu.cfs_quota_us | /sys/fs/cgroup/cpu/docker/<id>/cpu.cfs_quota_us | 容器在每个周期内可使用的 CPU 时间上限。设置不当会导致容器被限流（throttling）。 |
1.3 调度器与容器的交互流程
下图展示了从容器进程创建到 CPU 时间分配的完整调度链路：
1.4 性能调优的三大维度
本课程将围绕以下三个维度展开调度器参数的调优实践：
- 延迟优化：调整
sched_latency_ns与sched_min_granularity_ns，降低容器内交互型任务的响应时间。 - 吞吐量优化：调整
sched_wakeup_granularity_ns与sched_nr_migrate，减少不必要的上下文切换与迁移开销。 - 隔离性优化：利用 cgroup 的
cpu.cfs_quota_us与cpu.shares参数，确保多容器场景下的公平调度与 QoS 保障。
学习建议： 在阅读后续章节前，请确保你已熟悉 Linux 进程状态（TASK_RUNNING、TASK_INTERRUPTIBLE 等）以及 cgroups v1/v2 的基本概念。本课程将直接使用这些术语进行参数分析。
1.5 课程实验环境概览
所有调优实验将在以下环境中进行验证：
| 组件 | 版本/配置 |
|---|---|
| Linux 内核 | 5.15+（支持 CFS 带宽控制与 SCHED_IDLE） |
| Docker 引擎 | 24.0+（支持 --cpus、--cpu-shares、--cpuset-cpus） |
| 性能采集工具 | perf、/proc/sched_debug、cgroup 统计接口 |
| 基准测试负载 | sysbench（CPU 密集型）、wrk（网络 I/O 密集型） |