Linux

概述 凌晨三点，你被告警吵醒，登录服务器发现屏幕上只有一行 Kernel panic - not syncing: Fatal exception，然后系统就重启了。等你好不容易连上去，崩溃现场什么都没留下——没有日志，没有 core dump，没有调用栈。你只能对着一句 systemd-logind: System is going down 发呆。 这种场景，每个干过几年运维的人都遇到过。内核崩溃本身已经够头疼了，但更头疼的是崩溃后什么都抓不到，问题根本没法定位。 kdump 就是解决这个问题的。它相当于给 Linux 服务器装了一台飞行记录仪——飞机坠毁时，黑匣子能告诉你最后几秒发生了什么；内核崩溃时，kdump 能把崩溃瞬间的完整内存状态保存下来，让你事后用 crash 工具逐帧分析。 这篇文章不讲虚的，从 kdump 的工作原理到生产环境的完整配置流程，再到 crash 工具的实际分析操作，全部覆盖。读完之后，你应该能在自己的服务器上搭一套可靠的崩溃捕获系统。 kdump 是怎么工作的 双内核机制 要理解 kdump，先搞懂一个关键概念：崩溃时主内核已经不可信了。你不能指望一个已经 panic 的内核去把自己的内存好好保存下来——它连正常执行代码都做不到。 kdump 的思路很巧妙：系统启动时，提前预留一块物理内存，在里面加载一个精简的"捕获内核"（capture kernel，也叫第二内核）。主内核正常运行时，这块内存被隔离，谁都不许动。一旦主内核崩溃，kexec 机制会直接把 CPU 控制权交给捕获内核——不走 BIOS，不重启硬件，直接在预留内存里启动。捕获内核接管后，主内核的内存内容还完好无损地躺在那里，捕获内核把它打包成 vmcore 文件，写到磁盘上。 整个过程像这样： ┌──────────────────────────────────────────────┐ │ 物理内存布局 │ │ │ │ ┌────────────────┐ ┌───────────────────┐ │ │ │ 主内核区域 │ │ 预留内存区域 │ │ │ │ (正常运行) │ │ (crashkernel) │ │ │ │ │ │ │ │ │ │ 用户进程 │ │ 捕获内核 + │ │ │ │ 内核模块 │ │ initramfs │ │ │ │ 页缓存....

概述 凌晨三点，你被告警吵醒。登录服务器一看，某个关键配置文件被改了，但 last 命令显示那个时间段没有人登录，bash_history 也没记录。你知道出事了，但不知道是谁干的、怎么干的。 这时候你需要的是 auditd——Linux 内核自带的审计系统。它就像飞机的黑匣子，记录系统上发生的每一个关键动作：谁执行了什么命令、访问了哪些文件、改了什么配置、什么时候提的权。而且这些记录在内核层面生成，不依赖 shell history 或应用日志——攻击者就算删了 ~/.bash_history，也删不掉 auditd 的日志。 本文从安装部署讲到规则编写、日志分析和生产调优。不是手册翻译，是踩过坑后的实战经验。 auditd 是什么，和 syslog 有什么区别 先说清楚一个常见的混淆。很多人觉得"我有 syslog/journald 了，还要 auditd 干嘛？" 两者记录的东西完全不同： 对比项 syslog/journald auditd 记录层级 应用层 内核层 记录内容 服务启动/停止、应用日志、登录记录 系统调用、文件访问、权限变更 粒度 粗（按事件） 细（按系统调用） 防篡改 无（root 可随意修改） 有（日志写入前加密校验） 性能影响 极低 有，取决于规则数量和复杂度 典型用途 日常运维日志 安全审计、合规检查、应急响应 打个比方：syslog 像小区门口的保安登记簿，谁进谁出记一笔。auditd 像每户人家的门禁记录加室内监控——什么时候开了哪个门、谁开的、开了多久，精确到秒。 auditd 最初源自 Solaris 的审计子系统，Linux 内核 2.6（2004 年）开始引入，由 Red Hat 和 IBM 主导开发。现在已经是 CIS Benchmark、PCI-DSS、HIPAA 等安全合规标准的必备组件。 auditd 已成为 Linux 安全标准（如 CIS Benchmark、PCI-DSS、HIPAA）的重要组成部分。参考来源：Demystifying Auditd: A Complete Guide for Linux Security Monitoring...

概述 线上跑着一个高频交易系统，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 总线，延迟翻倍。...

概述 Linux 命名空间与 cgroups：容器技术的底层基础是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要Linux 命名空间与 cgroups 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。Linux 命名空间与 cgroups能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 Linux 命名空间与 cgroups的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是Linux 命名空间与 cgroups的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 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 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 Nginx 性能调优：从配置到内核参数的完整实践是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要Nginx 性能调优 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。Nginx 性能调优能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 Nginx 性能调优的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是Nginx 性能调优的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 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 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 Linux 系统调用追踪：strace 与 ltrace 调试实战是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要Linux 系统调用追踪 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。Linux 系统调用追踪能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 Linux 系统调用追踪的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是Linux 系统调用追踪的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 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 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 Linux 防火墙经历了从 ipfwadm → ipchains → iptables → nftables 的演进。底层均基于 Netfilter 框架，但上层语法和管理方式不断改进。从 Netfilter 架构出发，深入 iptables 的五链四表、nftables 的优势与用法、NAT/端口转发、连接追踪机制以及生产环境的性能优化实践。 Netfilter 框架 架构概览 Netfilter 是 Linux 内核中的数据包处理框架，通过在内核网络栈的关键位置挂载钩子（hook）来实现数据包过滤、地址转换、连接追踪等功能。 Netfilter 钩子点 [数据包进入] → PREROUTING → [路由判断] →─┬─→ FORWARD → POSTROUTING → [数据包发出] │ └─→ INPUT → [本地进程] → OUTPUT → POSTROUTING → [数据包发出] 五大钩子点 钩子点 触发时机 中文含义 NF_INET_PRE_ROUTING 数据包进入网络栈，路由前 路由前 NF_INET_LOCAL_IN 数据包目的地是本机 输入 NF_INET_FORWARD 数据包需要转发到其他接口 转发 NF_INET_LOCAL_OUT 本机产生的数据包 输出 NF_INET_POST_ROUTING 数据包即将离开网络栈 路由后 数据包流向 入站（访问本机）: NIC → PREROUTING → INPUT → 本机进程 出站（本机发出）: 本机进程 → OUTPUT → POSTROUTING → NIC 转发（经过本机）: NIC → PREROUTING → FORWARD → POSTROUTING → NIC iptables 五链四表 四张表 iptables 通过"表"来组织不同功能的规则链：...

概述 进程调度器是操作系统内核的核心组件，它决定了哪个进程在哪个 CPU 上运行、运行多长时间。Linux 自 2.6.23 起采用 CFS（Completely Fair Scheduler）作为默认调度器，经过多年演进，在 6.6 内核中又引入了 EEVDF（Earliest Eligible Virtual Deadline First）替代 CFS。本文深入理解 CFS 的工作原理、nice/cgroup CPU 控制、实时调度、CPU 亲和性等核心主题，并分享生产环境的调优经验。 CFS 调度器原理 设计哲学 CFS 的核心目标是"完全公平"——每个进程按照其权重比例获得 CPU 时间。与传统调度器基于时间片不同，CFS 使用"虚拟运行时间"（vruntime）来跟踪每个进程的 CPU 消耗： vruntime = 实际运行时间 × (NICE_0_LOAD / 进程权重) nice 值为 0 的进程权重为 1024（NICE_0_LOAD） nice 值越低，权重越大，vruntime 增长越慢，获得更多 CPU 时间 CFS 始终选择 vruntime 最小的进程运行 红黑树与调度队列 CFS 使用红黑树维护运行队列，按 vruntime 排序： [vruntime=50] / \ [vruntime=20] [vruntime=80] / \ [vruntime=10] [vruntime=35] 最左节点（vruntime 最小）是下一个被调度的进程 进程运行后 vruntime 增加，被重新插入红黑树 查找、插入、删除均为 O(log N) 调度周期与最小粒度 # 调度周期（目标延迟）：所有进程在这段时间内至少运行一次 $ sysctl kernel....

概述 内存是 Linux 系统中最宝贵的资源之一。理解内核如何管理内存，不仅能帮助你定位 OOM、内存泄漏等线上故障，还能在容量规划和性能调优时做出更准确的决策。从虚拟内存模型出发，覆盖 Page Cache、Swap 策略、OOM Killer 原理、cgroup v2 内存限制、slab/shmem 调优等核心主题，并附带多个生产环境实战案例。 虚拟内存模型 地址空间分层 Linux 采用虚拟内存机制，每个进程拥有独立的虚拟地址空间： 层级 说明 用户态可见 用户空间 0x000000000000 ~ 0x00007FFFFFFFFFFF 是 非规范区 0x0000800000000000 ~ 0xFFFF7FFFFFFFFFFF 否（空洞） 内核空间 0xFFFF800000000000 ~ 0xFFFFFFFFFFFFFFFF 否 64 位系统下，用户空间理论上有 128TB（47 位地址），内核空间同样 128TB。实际可用受 TASK_SIZE 和 mm_struct 限制。 内存_zone 划分 内核将物理内存划分为多个 zone，不同 zone 有不同用途： $ cat /proc/zoneinfo | grep -E "^Node|pages free|high|normal|DMA" Zone 用途 典型场景 DMA 16MB 以下，旧 ISA 设备 DMA 几乎不用 DMA32 4GB 以下，32 位 DMA 设备 老硬件 Normal 4GB 以上，大多数内存分配 主要使用 Movable 可迁移页面，支持内存热插拔 虚拟化/大页 当 Normal zone 内存耗尽时，内核会从 DMA32 zone 借用页面（watermark 机制），但频繁借用会导致性能下降。...

概述 Linux 系统的启动是一个精密编排的多阶段过程，从固件加电自检到内核加载、再到用户空间服务启动，每个阶段都有其特定职责。理解完整的启动流程不仅有助于排查启动故障，还能进行启动性能优化。从固件层出发，逐层解析 BIOS/UEFI、GRUB2、initramfs、内核初始化、systemd 启动流程，并覆盖启动优化和内核崩溃恢复。 启动流程概览 [电源开启] │ ▼ [1. 固件阶段] BIOS / UEFI │ POST (加电自检) │ 硬件初始化 │ 查找启动设备 ▼ [2. 引导阶段] GRUB2 │ 加载 GRUB 到内存 │ 读取 grub.cfg │ 加载内核和 initramfs ▼ [3. 内核阶段] Linux Kernel │ 内核解压并初始化 │ 硬件检测和驱动加载 │ 挂载 initramfs │ 启动 init (systemd) ▼ [4. 用户空间阶段] systemd │ 读取 default.target │ 按依赖顺序启动服务 │ 启动登录服务 ▼ [5. 登录阶段] │ getty / display-manager │ 用户认证 │ Shell 启动 ▼ [系统就绪] BIOS 与 UEFI BIOS vs UEFI 特性 BIOS UEFI 启动模式 Legacy UEFI 固件接口 16位 32/64位 分区表 MBR (≤2TB) GPT (>2TB) 启动代码 512字节MBR EFI分区 启动速度 慢 快 网络功能 无 有（PXE/HTTP启动） 安全启动 不支持 支持 分辨率 文本模式 图形模式 BIOS 启动流程 1....