性能优化

概述 线上跑着一个高频交易系统，P99 延迟平时 2ms，但偶尔飙到 20ms。CPU 使用率不高，内存充足，网络正常。查了一圈，发现是 CPU 调度器把关键线程踢到了另一个核上，L3 缓存全部 miss，延迟直接翻了 10 倍。 这种问题不是靠加资源能解决的。问题出在"共享"——所有进程共享 CPU 核心，调度器自由分配，谁也不知道哪个线程是延迟敏感的。 解决办法就是 CPU 隔离：把关键业务绑到专属核心上，不让别的进程碰。同时做 NUMA 调优，让 CPU 和内存在物理上"就近"，避免跨节点访问带来的延迟翻倍。 这篇笔记覆盖从基础概念到生产实操的完整链路：isolcpus 内核参数、cpuset cgroup、taskset 绑核、NUMA 亲和性、中断绑核、以及组合使用的最佳实践。所有命令都在 Ubuntu 22.04（内核 5.15）和 CentOS 8 上实测过。 基础概念：为什么要隔离 CPU CPU 调度器是怎么工作的 Linux 默认使用 CFS（Completely Fair Scheduler，完全公平调度器）分配 CPU 时间。CFS 的设计目标是"公平"——每个进程根据权重获得 CPU 时间片，调度器在所有可用核心之间自由迁移进程。 听起来没问题，但对延迟敏感的场景是个灾难： 上下文切换开销：线程从 CPU A 迁移到 CPU B，L1/L2 缓存全部失效，需要重新从内存加载数据。一次迁移的代价是微秒级的延迟抖动。 缓存污染：其他进程跑在你的目标核上，把你之前缓存的数据挤出去，下次你的线程回来时全是 cache miss。 中断干扰：网卡中断、定时器中断随时打断你的线程。对于要求微秒级响应的系统，一次中断就是一次延迟尖峰。 NUMA 架构是什么 NUMA（Non-Uniform Memory Access，非统一内存访问）是多路服务器的标配架构。简单说就是：每个 CPU 插槽有自己的本地内存，访问自己的内存很快，访问别的 CPU 的内存要跨 QPI/UPI 总线，延迟翻倍。...

概述 MySQL 性能优化：慢查询分析与索引调优实践是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要MySQL 性能优化 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。MySQL 性能优化能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 MySQL 性能优化的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是MySQL 性能优化的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具： 场景 推荐工具 说明 配置管理 Ansible 无代理，适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源，社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

eBPF：内核可编程的革命 传统性能分析工具分两类：一类是 top、vmstat、iostat 这样的"概览型"工具，告诉你系统层面发生了什么，但看不到细节；另一类是 strace、gdb 这样的"跟踪型"工具，能看细节但开销巨大，生产环境基本不敢用。 eBPF（Extended Berkeley Packet Filter）改变了一切。它允许你在不修改内核源码、不加载内核模块的前提下，安全地在内核中运行沙箱程序。这些程序挂载到内核的 hook 点（kprobes、tracepoints、perf events 等），在事件发生时被触发执行，采集数据后通过 ring buffer 传递到用户态。 为什么说这是革命性的？三个原因： 安全：eBPF 程序在加载时经过验证器（verifier）检查，确保不会死循环、不会非法访问内存，不需要 root 权限加载内核模块的风险。 低开销：eBPF 程序在内核态直接执行，只有采集到的数据才通过 ring buffer 拷贝到用户态，热路径上的开销极小。 可编程：你可以针对自己的具体问题编写精确的探针程序，而不是依赖通用工具"凑合"用。 eBPF 的完整技术文档可参考 BPF Compiler Collection (BCC) 官方仓库，本文所有工具均来自该项目。 bcc 工具集安装 bcc（BPF Compiler Collection）是基于 eBPF 的性能分析工具集，由 iovisor 项目维护，提供了数十个开箱即用的追踪工具。 Ubuntu / Debian # Ubuntu 20.04+ 推荐方式 sudo apt update sudo apt install -y bpfcc-tools linux-headers-$(uname -r) # 验证安装 /usr/share/bcc/tools/biolatency --help CentOS / RHEL # CentOS 8 / RHEL 8+ sudo dnf install -y bcc-tools kernel-devel-$(uname -r) # CentOS 7 需通过 ELRepo sudo yum install -y epel-release sudo yum install -y bcc-tools kernel-devel-$(uname -r) # 工具默认安装在 /usr/share/bcc/tools/ 目录下 ls /usr/share/bcc/tools/ 安装后建议将工具路径加入 PATH：...

概述 性能问题几乎是每个 SRE 都会遇到的高频场景：用户反馈"好慢"、告警说"P99 延迟超标"、监控显示"CPU 快满了"。但很多团队对性能问题的处理方式是"哪里高了调哪里"——CPU 高了就加机器，SQL 慢了就加索引，延迟高了就加缓存。这种头痛医头的做法短期内可能有效，但长期来看会让系统越来越复杂、成本越来越高、问题越来越难排查。 性能工程（Performance Engineering）与性能调优（Performance Tuning）有本质区别。性能调优是"发现问题→优化"的反应式过程；性能工程是"建立基线→持续度量→主动发现→系统优化"的工程化体系。SRE 的视角不是"让某个接口快 10ms"，而是"建立系统性的性能管理体系，让性能问题在被用户感知之前发现和解决"。 从方法论、分析框架、基线建立、瓶颈定位、优化策略到持续管理，详细梳理 SRE 视角的性能工程。 关于性能分析的系统性方法，可参考 Brendan Gregg - USE Method 和 Tom Wilkie - RED Method。 一、性能工程 vs 性能调优 概念区分 维度 性能调优 性能工程 时机 性能问题出现后 贯穿系统全生命周期 目标 解决当前的性能问题 建立持续的性能管理体系 方法 经验驱动，试试看 数据驱动，详细分析 范围 聚焦特定瓶颈 覆盖全栈（应用→中间件→基础设施） 产出 问题解决 基线、SLO、监控、优化策略 持续性 一次性 持续度量和管理 为什么 SRE 需要性能工程 没有性能工程的团队： 用户投诉"慢" → 紧急排查 → 发现 SQL 慢 → 加索引 → 一个月后又慢了 → 发现是缓存命中率低 → 加缓存 → 又一个月后又慢了 → 发现是连接池不够 → 调连接池 → 循环往复，系统越来越复杂，问题越来越多 有性能工程的团队： 建立性能基线 → 持续监控 → 发现 P99 缓慢上升（用户还没感知） → 主动分析 → 定位到数据库查询模式变化 → 优化查询 → 在用户感知之前解决问题 性能工程的价值：...

前言 磁盘 I/O 往往是系统性能链条中最慢的一环。一次机械磁盘寻道约 10ms，而内存访问仅约 100ns——两者相差 10 万倍。当业务出现延迟抖动、响应变慢，排查方向总会指向 I/O 子系统。从指标体系出发，结合工具实战与生产案例，建立一套可复用的 I/O 诊断方法论。 I/O 性能指标体系 在动手之前，必须搞清楚四个核心指标的含义及其相互关系。 指标 单位 含义 典型参考值 IOPS 次/秒 每秒完成的 I/O 读写次数 HDD ~100，SATA SSD ~10 万，NVMe SSD ~50 万+ 吞吐量 MB/s 每秒传输的数据量 HDD ~150 MB/s，SATA SSD ~550 MB/s，NVMe SSD ~3000 MB/s+ 延迟 ms/μs 单次 I/O 从提交到完成的耗时 HDD 5-15ms，SSD 0.1-1ms，NVMe 0.02-0.1ms 队列深度 个 等待处理的 I/O 请求数 建议值 NVMe 32-256，SSD 8-32 这四个指标之间存在关键约束关系： 小块随机读写场景下，瓶颈是 IOPS（如数据库 OLTP 4KB 随机写） 大块顺序读写场景下，瓶颈是吞吐量（如日志追加、视频流媒体） 延迟是最终用户感知的指标，即使 IOPS 和吞吐量充足，单次延迟过高仍会导致卡顿 队列深度提升能增加并发，但也意味着单请求等待时间变长 一个重要认知：IOPS × 块大小 ≈ 吞吐量。例如 4KB 块、100 IOPS，吞吐量约 0....