Linux 服务器 CPU 性能排查方法

Linux 服务器 CPU 性能排查方法

By netmainFebruary 17, 2026February 12, 2026

当服务器整体响应变慢、负载（load average）异常升高、QPS/吞吐下降、请求延迟抖动或用户反馈“卡顿”时，CPU 瓶颈 是最常见嫌疑之一。但“CPU 高”并不等于“CPU 就是瓶颈”——它可能是计算密集、锁竞争、上下文切换爆炸、调度延迟、虚拟化偷窃周期（steal）等不同子类的表现。 本文给出从快速判断 → 分类定位 → 深度剖析的完整、可操作排查路径，适用于物理机、虚拟机、容器宿主机场景（2026 年主流内核 6.6–6.12+）。 第一步：快速确认是否真的是 CPU 瓶颈（1–3 分钟） 跑以下命令组合，建立初步画像： 负载与运行队列uptime 或 cat /proc/loadavg → load average（1/5/15 min）持续 > 核数 × 1.5–2.5，且 runq-sz（运行队列长度） 高 → 有 CPU 相关等待 top / htop 概览（最重要第一屏） 按 1 查看每个核使用率 按 P 排序进程（Shift+P） 看 %Cpu(s) 行： us（用户态）+ sy（内核态）持续 > 80–90% id（idle） < […]

Linux 服务器性能排查

By netmainFebruary 16, 2026February 12, 2026

性能问题出现时（响应变慢、负载飙升、请求超时、吞吐下降等），最致命的不是技术深度不够，而是排查顺序混乱。正确的思路是先全局定性、再分层定位、最后针对性深挖，而不是一上来就 strace / perf / gdb。 以下是 2025–2026 年生产环境中，经过 Netflix、Brendan Gregg、Red Hat 等验证过的完整、可重复的排查框架，分为四个阶段。 第一阶段：症状收集与基线对比（1–3 分钟） 目标：明确“到底慢在哪里”，建立问题画像。 必问 5 个问题（自己回答或问业务）： 慢是从什么时候开始的？有无明显触发事件（代码发布、流量峰值、配置变更）？ 是所有请求慢，还是部分接口/用户慢？ 是 CPU/内存/磁盘/网络/数据库 其中哪类资源最明显异常？ 历史基线如何？（正常时 load/响应时间/qps 大概多少？） 有无告警？（Prometheus/Grafana/Zabbix 等是否有 Utilization/Saturation/Errors 异常） 立即执行的 6 条命令（复制粘贴顺序跑）： uptime → load average 与核数对比 top / htop（按 1 看多核，按 M 看内存，按 P 看 CPU 排序） free -h -w → 重点看 […]

Linux 日志分析工具与技巧

By netmainFebruary 15, 2026February 5, 2026

 Linux 服务器运维的日常工作中，日志几乎是“真相的唯一来源”。 无论是定位线上 bug、排查慢查询、分析安全事件、发现内存泄漏、还是复盘一次生产事故，最终都要回到日志里找证据。 但日志文件往往体量巨大、格式杂乱、分布分散，很多运维同学面对几 GB 的 error.log 或 journalctl 输出时，第一反应是“从哪里开始看”。 这篇文章将围绕 Linux 生产环境中最实用、最高效的日志分析工具与技巧展开，从基础命令到高级组合、从单机到分布式、从手动排查到自动化告警，系统梳理一套“快速定位问题 → 深度挖掘根因 → 建立长期可观测性”的完整方法论。 一、日志分析的层次与心态 在开始工具之前，先建立正确的层次认知，能避免 80% 的无效翻日志时间。 日志分析的四个层次（由浅入深） 事件发现层：什么时候、哪个服务、报了什么错？（关键词、时间范围、错误码） 上下文还原层：这个错误的前因后果是什么？（上下 10–50 行、traceId、requestId） 根因定位层：为什么会报这个错？（代码路径、系统资源、依赖服务、外部调用） 趋势与模式层：这个错误是否周期性？是否随流量增加而放大？是否新版本引入？ 最常见的心态误区： 只 grep “error” / “exception” → 错过 warning、超时、重试、慢查询等前兆 只看最后 100 行 → 错过真正触发问题的起点 只看当前机器日志 → 分布式系统下错过分布式 trace 只看日志不结合监控 → 无法判断是偶发还是趋势性问题 二、单机日志分析核心工具链（日常 90% 场景够用） 1. 基础三件套：grep […]

Linux 性能分析工具详解

By netmainFebruary 14, 2026February 5, 2026

在 Linux 服务器运维与性能优化工作中，“不知道瓶颈在哪里”永远是最让人焦虑的状态。 CPU 使用率高？内存泄漏？磁盘 IO 饱和？网络丢包？锁竞争？软中断过载？还是应用本身算法复杂度爆炸？ 每一种可能性都需要不同的工具去验证，而盲目猜测、随意调参只会浪费时间，甚至把系统越调越差。 本文将围绕生产环境中真正高频使用、诊断能力最强的性能分析工具，按照从基础到高级、从宏观到微观的顺序，系统讲解它们的适用场景、核心指标解读、典型用法以及实际案例中的定位思路。目标是让你在遇到“服务器卡了/慢了/负载高了”时，能迅速形成清晰的诊断路径，而不是漫无目的敲命令。 全文约 2100 字，建议收藏备用，下次出问题时直接对照流程走。 一、宏观概览工具（1 分钟快速定性） 这些工具用来回答最核心的问题：“现在系统到底卡在哪里？” 1. top / htop / glances（日常第一屏） top：最基础，wa%（iowait）高 → 先怀疑 IO；us+sy 高 → CPU 计算密集；hi+si 高 → 中断或软中断 htop：树形进程视图 + 颜色 + 鼠标操作，F2 设置显示列（加 DELAY、SWAP、IO% 等），F6 按 CPU/内存/IO 排序 glances：一屏看全（CPU、内存、IO、网络、进程、磁盘、传感器），支持 Web 模式和导出 InfluxDB/Prometheus 使用建议： wa% > 20–30% 持续 → 优先看 IO（iostat […]

Linux 服务器高并发连接优化思路

By netmainFebruary 13, 2026February 5, 2026

Linux 服务器在高并发连接场景下的表现，很大程度上取决于内核 TCP/IP 协议栈的资源分配逻辑、文件描述符（fd）管理机制、连接状态机的生命周期控制，以及应用层对 accept 队列与 worker 线程池的合理使用。 真正能把单机并发连接从几千提升到几万甚至十万以上的优化，几乎都围绕以下几个核心约束展开： fd 资源枯竭（进程/线程能打开的文件描述符上限） 本地端口号耗尽（主动连接或被动连接的源端口/目标端口对有限） TIME_WAIT 状态堆积（短连接场景最致命的瓶颈） accept 队列与 SYN 队列溢出（listen backlog 与 tcp_max_syn_backlog） 连接跟踪表（conntrack）与 NAT 表溢出（特别是 NAT 网关或 LVS 场景） 单核软中断（ksoftirqd）瓶颈与网络中断分布不均 内核调度开销与上下文切换压力 下面按优化收益从高到低、实施优先级从前到后的顺序，系统梳理生产环境中真正有效的优化思路与核心逻辑。 一、最关键的第一步：fd 资源与进程限制（必须最先解决） 文件描述符是 Linux 高并发连接的“硬天花板”。 一个进程能同时持有的 fd 数量直接决定了它能 accept 和处理多少个并发 socket。 默认软限制通常只有 1024，硬限制 4096，这在任何高并发服务面前都远远不够。 优化逻辑 系统全局打开文件数（fs.file-max）要提升到 100 万级别以上。 每个服务进程的 nofile 限制要独立设置到 50 万～100 万（视内存规模）。 […]

Linux 服务器 DNS 解析问题详解

By netmainFebruary 12, 2026February 5, 2026

DNS 解析问题是 Linux 服务器最常见、最隐蔽、也最容易被误判的网络故障之一。 很多“网站打不开”“接口超时”“curl 卡死”“容器拉镜像失败”等现象，最终追溯回去都是 DNS 解析出了问题，但因为表现形式多样（间歇性、特定域名、特定时间段、特定网络环境），排查起来往往让人抓狂。 本文从原理 → 常见表现 → 系统性排查路径 → 生产场景真实案例 → 预防与优化的完整逻辑，帮你建立一套遇到 DNS 问题时能快速定位的思维框架。 一、Linux 服务器 DNS 解析的基本原理（必须先搞清楚） Linux 系统中的 DNS 解析流程主要依赖以下几个组件： 应用程序 → getaddrinfo() / gethostbyname() 等 libc 函数 glibc 解析器（/etc/nsswitch.conf 中的 hosts 行决定顺序） files → /etc/hosts dns → 通过 /etc/resolv.conf 指定的 nameserver 进行递归/迭代查询 myhostname / resolve / systemd-resolved […]

Linux 服务器端口无法访问的常见原因

By netmainFebruary 11, 2026February 5, 2026

Linux 服务器端口无法访问（telnet/nc/curl 连接超时或拒绝）是运维中最常见的故障之一，也是告警和用户投诉的高频来源。 端口不通的根本原因可以分为三大类： 服务本身没有在监听 服务在监听，但外部访问不到 连接到达了，但被拒绝或处理失败 下面按出现概率从高到低逐一拆解最常见的真实原因，并给出快速验证方法，帮助你在 3–10 分钟内定位到 95% 的问题。 第一类：服务根本没起来或没监听（占比 ≈ 40%） 这是最基础、最容易被忽略的一类。 常见表现： ss -tuln | grep :端口号 完全没有输出，或者只看到 127.0.0.1 而不是 0.0.0.0 / ::。 典型原因： 服务压根没启动（systemctl status 显示 inactive/failed） 服务启动失败（配置错误、端口冲突、依赖缺失、权限问题） 服务绑定了 127.0.0.1 而不是 0.0.0.0 或 ::（最经典的 Nginx/Apache/MySQL 坑） 容器化场景下网络模式错误（network_mode: host vs bridge） systemd unit 文件中指定了 PrivateNetwork=yes 或 RestrictAddressFamilies 进程启动用户与监听端口权限不匹配（比如非 root 用户监听 […]

Linux 磁盘 IO 慢的排查思路

By netmainFebruary 10, 2026February 5, 2026

磁盘 IO 慢是 Linux 服务器最常见、最隐蔽、也最容易被误判的性能瓶颈之一。 很多人一看到 top 里 wa%（iowait）很高，就直接下结论“磁盘慢了”，然后盲目换 SSD、调调度器、改文件系统参数，结果问题依旧；也有人看到 iostat %util 没到 100% 就觉得“磁盘没问题”，其实真正的瓶颈早已发生在队列深处。 下面是一套系统性、由表及里、从现象到根因的排查思路框架，适用于数据库、日志服务、文件服务器、容器存储、虚拟机宿主机等几乎所有高 IO 场景。核心思想是：先定性、再定位、最后优化。 一、先明确“IO 慢”的具体表现（30 秒定方向） IO 慢可以表现为很多种形态，不同形态指向完全不同的根因，必须先切割清楚： 表现形式 最可能瓶颈类型（优先级排序） 典型场景 数据库查询/写入明显变慢 随机小 IO、锁等待、元数据压力 MySQL/PostgreSQL/Redis 日志写入导致服务卡顿 顺序大 IO + 脏页回写阻塞 高并发业务日志 文件拷贝/解压/打包极慢 顺序 IO 吞吐低、元数据操作多 备份、解压、git 操作 容器启动/镜像拉取慢 随机读 + 元数据 + overlayfs 层叠 Docker/Kubernetes 整个系统响应变慢，top wa% 高 混合负载、队列饱和、D 状态进程堆积 […]

Linux 服务器网络慢的排查思路

By netmainFebruary 9, 2026February 5, 2026

Linux 服务器出现“网络慢”是一个非常典型的运维场景，但“慢”本身是一个高度模糊的症状。它可能涉及从物理层到应用层的任意一环，也可能是多因素叠加的结果。 最有效的排查方式不是一上来就改内核参数、换拥塞算法或抓包，而是先把“慢”的边界和表现形式切割清楚，再沿着网络栈从近到远、从底层到上层逐层验证。 以下是生产环境中真正高频使用的、结构化的排查思路框架，按优先级与收益排序组织。整个流程的核心思想是：用最少的步骤排除最大面积的可能性。 一、先明确“慢”的具体画像（决定后续方向的 30 秒） 在动手之前，必须先把问题切割成以下维度，否则后续所有操作都可能是盲人摸象： 慢的范围 全网慢，还是只有特定域名/端口/协议慢？ 内网正常、外网慢，还是内外都慢？ 只有出方向慢，还是双向都慢？ 慢的形态 持续性慢（稳定高延迟） 间歇性卡顿（周期性抖动或偶发丢包） 前期正常，后期越来越慢（连接积累型） 建立连接慢，但一旦连上就快（握手慢型） 慢的体感 ssh 敲字有明显回显延迟 网页打开卡（TTFB 长） 大文件下载速度远低于预期带宽 视频/实时应用频繁缓冲 时间与触发条件 特定时间段（凌晨、业务高峰） 特定操作后（大文件传输后、大量短连接后） 重启服务器/网络服务后是否恢复 一句话总结： 先花 30 秒把“慢”描述成 3–4 个具体可验证的现象，比直接跳到 mtr 或 tcpdump 更高效十倍。 二、分层排查框架（由近及远） 层 1：本地环回与本机网络栈（排除最基础问题） 先确认服务器自身的 TCP/IP 协议栈是否健康。 关键验证点： 本地环回（127.0.0.1）是否延迟异常 本机外网 IP 是否能正常 ping 通自己 lo 接口是否存在异常丢包或错误 如果这一层就有问题，通常是内核网络模块加载异常、网卡驱动崩溃、或 iptables/nftables […]

SELinux 安全模块详解

By netmainFebruary 8, 2026February 5, 2026

SELinux（Security-Enhanced Linux）是目前 Linux 内核中最强大、最严格的强制访问控制（MAC）机制。它由美国国家安全局开发并开源，已成为 Red Hat 系发行版（RHEL、CentOS、Rocky、AlmaLinux、Fedora）和部分其他发行版的默认安全组件。 与传统权限模型（chmod/chown + owner/group/other）最大的不同在于：即使你是 root 用户，进程也必须严格遵守 SELinux 策略定义的访问规则。这使得即使存在配置错误、提权漏洞或恶意代码，攻击面也会被极大压缩。 一、SELinux 的核心价值与防护能力 SELinux 最擅长的防护场景包括： 即使服务被提权，也无法读取 /etc/shadow、修改系统关键文件 Web 服务进程即使被 RCE，也很难写 webshell 到其他目录或执行反弹 shell 数据库服务即使存在 SQL 注入导致的文件写入，也无法访问其他数据库文件或家目录 防止横向移动：一个被攻陷的低权限服务难以访问高权限服务的文件/端口/进程 限制零日漏洞的破坏半径：即使漏洞允许任意代码执行，也受限于进程的域（domain）权限 一句话总结：SELinux 把“出了漏洞还能做什么”变成了“出了漏洞也做不了太多”。 二、三种运行模式与切换方式 SELinux 有三种运行状态： enforcing（强制模式） 严格执行策略，违规访问直接被拒绝并记录审计日志。这是生产推荐模式。 permissive（宽松模式） 记录所有违规访问，但不实际拒绝。这是调试和迁移时的最佳状态。 disabled（完全关闭） 内核不加载 SELinux 策略模块，性能损失最小，但失去全部 MAC 保护。强烈不建议长期使用。 常用切换命令（无需重启）： Bash # 查看当前模式 getenforce sestatus | grep “Current […]