- 博客(60)
- 收藏
- 关注
RSS订阅原创 四十四、案例篇：内核线程 CPU 利用率太高，我该怎么办？
上一期，梳理了网络时不时丢包的分析定位和优化方法。先简单回顾一下。网络丢包，通常会带来严重的性能下降，特别是对 TCP 来说，丢包通常意味着网络拥塞和重传，进而会导致网络延迟增大以及吞吐量降低。而分析丢包问题，还是用我们的老套路，从 Linux 网络收发的流程入手，结合 TCP/IP 协议栈的原理来逐层分析。其实，在排查网络问题时，还经常碰到的一个问题，就是内核线程的 CPU 使用率很高。比如，在高并发的场景中，内核线程 ksoftirqd 的 CPU 使用率通常就会比较高。
2025-12-25 14:00:00
394
原创 四十三、案例篇：服务器总是时不时丢包，我该怎么办？（下）
上一节，学习了如何分析网络丢包的问题，特别是从链路层、网络层以及传输层等主要的协议栈中进行分析。不过，通过前面这几层的分析，还是没有找出最终的性能瓶颈。看来，还是要继续深挖才可以。今天，就来继续分析这个未果的案例。在开始下面的内容前，可以先回忆一下上节课的内容，并且自己动脑想一想，除了我们提到的链路层、网络层以及传输层之外，还有哪些潜在问题可能会导致丢包呢？
2025-12-25 10:00:00
921
原创 四十二、案例篇：服务器总是时不时丢包，我该怎么办？（上）
上一节，梳理了应用程序容器化后性能下降的分析方法。简单回顾下。容器利用 Linux 内核提供的命名空间技术，将不同应用程序的运行隔离起来，并用统一的镜像，来管理应用程序的依赖环境。这为应用程序的管理和维护，带来了极大的便捷性，并进一步催生了微服务、云原生等新一代技术架构。不过，虽说有很多优势，但容器化也会对应用程序的性能带来一定影响。比如，上一节我们一起分析的 Java 应用，就容易发生启动过慢、运行一段时间后 OOM 退出等问题。
2025-12-24 14:00:00
602
原创 四十一、案例篇：为什么应用容器化后，启动慢了很多？
不知不觉，已经学完了整个专栏的四大基础模块，即 CPU、内存、文件系统和磁盘 I/O、以及网络的性能分析和优化。相信你已经掌握了这些基础模块的基本分析、定位思路，并熟悉了相关的优化方法。接下来，我们将进入最后一个重要模块—— 综合实战篇。这部分实战内容，也将是我们对前面所学知识的复习和深化。我们都知道，随着 Kubernetes、Docker 等技术的普及，越来越多的企业，都已经走上了应用程序容器化的道路。不过，任何技术都不是银弹。
2025-12-24 10:00:00
537
原创 四十、套路篇：网络性能优化的几个思路（下）
上一节，学了网络性能优化的几个思路，我先带你简单复习一下。在优化网络的性能时，你可以结合 Linux 系统的网络协议栈和网络收发流程，然后从应用程序、套接字、传输层、网络层再到链路层等每个层次，进行逐层优化。今天，我们顺着 TCP/IP 网络模型，继续向下，看看如何从传输层、网络层以及链路层中，优化 Linux 网络性能。
2025-12-23 14:00:00
753
原创 三十九、套路篇：网络性能优化的几个思路（上）
上一节，了解了NAT（网络地址转换）的原理，学会了如何排查 NAT 带来的性能问题，最后还总结了 NAT 性能优化的基本思路。先来简单回顾一下。NAT 基于 Linux 内核的连接跟踪机制，实现了 IP 地址及端口号重写的功能，主要被用来解决公网 IP 地址短缺的问题。在分析 NAT 性能问题时，可以先从内核连接跟踪模块 conntrack 角度来分析，比如用 systemtap、perf、netstat 等工具，以及 proc 文件系统中的内核选项，来分析网络协议栈的行为；
2025-12-23 10:00:00
652
原创 三十八、案例篇：如何优化 NAT 性能？（下）
上一节，学习了 NAT 的原理，明白了如何在 Linux 中管理 NAT 规则。先来简单复习一下。NAT 技术能够重写 IP 数据包的源 IP 或目的 IP，所以普遍用来解决公网 IP 地址短缺的问题。它可以让网络中的多台主机，通过共享同一个公网 IP 地址，来访问外网资源。同时，由于 NAT 屏蔽了内网网络，也为局域网中机器起到安全隔离的作用。Linux 中的NAT ，基于内核的连接跟踪模块实现。所以，它维护每个连接状态的同时，也对网络性能有一定影响。那么，碰到 NAT 性能问题时，我们又该怎么办呢。
2025-12-22 14:00:00
672
原创 三十七、案例篇：如何优化 NAT 性能？（上）
上一节，探究了网络延迟增大问题的分析方法，并通过一个案例，掌握了如何用 hping3、tcpdump、Wireshark、strace 等工具，来排查和定位问题的根源。简单回顾一下，网络延迟是最核心的网络性能指标。由于网络传输、网络包处理等各种因素的影响，网络延迟不可避免。但过大的网络延迟，会直接影响用户的体验。所以，在发现网络延迟增大的情况后，你可以先从路由、网络包的收发、网络包的处理，再到应用程序等，从各个层级分析网络延迟，等到找出网络延迟的来源层级后，再深入定位瓶颈所在。
2025-12-22 10:00:00
1570
原创 三十六、网络请求延迟变大了，该怎么办？
上一节，学习了碰到分布式拒绝服务（DDoS）的缓解方法。简单回顾一下，DDoS 利用大量的伪造请求，导致目标服务要耗费大量资源，来处理这些无效请求，进而无法正常响应正常用户的请求。由于 DDoS 的分布式、大流量、难追踪等特点，目前确实还没有方法，能够完全防御 DDoS 带来的问题，我们只能设法缓解 DDoS 带来的影响。比如，你可以购买专业的流量清洗设备和网络防火墙，在网络入口处阻断恶意流量，只保留正常流量进入数据中心的服务器。
2025-12-21 14:00:00
1184
原创 三十五、案例篇：怎么缓解 DDoS 攻击带来的性能下降问题？
DDoS 的前身是 DoS（Denail of Service），即拒绝服务攻击，指利用大量的合理请求，来占用过多的目标资源，从而使目标服务无法响应正常请求。DDoS（Distributed Denial of Service） 则是在 DoS 的基础上，采用了分布式架构，利用多台主机同时攻击目标主机。这样，即使目标服务部署了网络防御设备，面对大量网络请求时，还是无力应对。
2025-12-21 10:00:00
724
原创 三十四、案例篇：怎么使用 tcpdump 和 Wireshark 分析网络流量？
上一节，学习了 DNS 性能问题的分析和优化方法。简单回顾一下，DNS 可以提供域名和 IP 地址的映射关系，也是一种常用的全局负载均衡（GSLB）实现方法。通常，需要暴露到公网的服务，都会绑定一个域名，既方便了人们记忆，也避免了后台服务 IP 地址的变更影响到用户。不过要注意，DNS 解析受到各种网络状况的影响，性能可能不稳定。比如公网延迟增大，缓存过期导致要重新去上游服务器请求，或者流量高峰时 DNS 服务器性能不足等，都会导致 DNS 响应的延迟增大。
2025-12-20 14:00:00
714
原创 三十三、案例篇：DNS 解析时快时慢，该怎么办？
上一节，学习了网络性能的评估方法。简单回顾一下，Linux 网络基于 TCP/IP 协议栈构建，而在协议栈的不同层，所关注的网络性能也不尽相同。在应用层，关注的是应用程序的并发连接数、每秒请求数、处理延迟、错误数等，可以使用 wrk、JMeter 等工具，模拟用户的负载，得到想要的测试结果。而在传输层，关注的是 TCP、UDP 等传输层协议的工作状况，比如 TCP 连接数、 TCP 重传、TCP 错误数等。此时，可以使用 iperf、netperf 等，来测试 TCP 或 UDP 的性能。
2025-12-20 10:00:00
1295
原创 三十二、套路篇：怎么评估系统的网络性能？
上一节，回顾了经典的 C10K 和 C1000K 问题。简单回顾一下，C10K 是指如何单机同时处理 1 万个请求（并发连接1万）的问题，而 C1000K 则是单机支持处理 100 万个请求（并发连接100万）的问题。I/O 模型的优化，是解决 C10K 问题的最佳良方。Linux 2.6 中引入的 epoll，完美解决了 C10K 的问题，并一直沿用至今。今天的很多高性能网络方案，仍都基于 epoll。自然，随着互联网技术的普及，催生出更高的性能需求。
2025-12-19 14:00:00
546
原创 三十一、基础篇:C10K和C1000K回顾
前面内容，学习了 Linux 网络的基础原理以及性能观测方法。简单回顾一下，Linux 网络基于 TCP/IP 模型，构建了其网络协议栈，把繁杂的网络功能划分为应用层、传输层、网络层、网络接口层等四个不同的层次，既解决了网络环境中设备异构的问题，也解耦了网络协议的复杂性。基于 TCP/IP 模型，还梳理了 Linux 网络收发流程和相应的性能指标。在应用程序通过套接字接口发送或者接收网络包时，这些网络包都要经过协议栈的逐层处理。我们通常用带宽、吞吐、延迟、PPS 等来衡量网络性能。
2025-12-19 10:00:00
610
原创 三十、关于Linux网路，你必须知道这些（下）
上一节，学习了 Linux 网络的基础原理。简单回顾一下，Linux 网络根据 TCP/IP 模型，构建其网络协议栈。TCP/IP 模型由应用层、传输层、网络层、网络接口层等四层组成，这也是 Linux 网络栈最核心的构成部分。应用程序通过套接字接口发送数据包时，先要在网络协议栈中从上到下逐层处理，然后才最终送到网卡发送出去；而接收数据包时，也要先经过网络栈从下到上的逐层处理，最后送到应用程序。了解Linux 网络的基本原理和收发流程后，你肯定迫不及待想知道，如何去观察网络的性能情况。
2025-12-18 14:00:00
869
原创 二十九、关于Linux网路，你必须知道这些（上）
前几节，学习了文件系统和磁盘 I/O 的工作原理，以及相应的性能分析和优化方法。接下来，我们将进入下一个重要模块—— Linux 的网络子系统。由于网络处理的流程最复杂，跟我们前面讲到的进程调度、中断处理、内存管理以及 I/O 等都密不可分，所以，我把网络模块作为最后一个资源模块来讲解。同 CPU、内存以及 I/O 一样，网络也是 Linux 系统最核心的功能。网络是一种把不同计算机或网络设备连接到一起的技术，它本质上是一种进程间通信方式，特别是跨系统的进程间通信，必须要通过网络才能进行。
2025-12-18 10:00:00
1617
原创 二十八、套路篇：磁盘I_O性能优化的几个思路
上一节，回顾了常见的文件系统和磁盘 I/O 性能指标，梳理了核心的 I/O 性能观测工具，最后还总结了快速分析 I/O 性能问题的思路。虽然 I/O 的性能指标很多，相应的性能分析工具也有好几个，但理解了各种指标的含义后，你就会发现它们其实都有一定的关联。顺着这些关系往下理解，你就会发现，掌握这些常用的瓶颈分析思路，其实并不难。找出了 I/O 的性能瓶颈后，下一步要做的就是优化了，也就是如何以最快的速度完成 I/O操作，或者换个思路，减少甚至避免磁盘的 I/O 操作。
2025-12-17 14:00:00
1691
原创 二十七、套路篇：如何迅速分析出系统I_O瓶颈？
前几节学习中，通过几个案例，分析了各种常见的 I/O 性能问题。通过这些实战操作，熟悉了 I/O 性能问题的分析和定位思路，也掌握了很多 I/O 性能分析的工具。今天，一起复习总结一下，如何“快准狠”定位系统的 I/O 瓶颈；并且梳理清楚，在不同场景下，指标工具怎么选，性能瓶颈又该如何定位。
2025-12-17 10:00:00
975
原创 二十六、案例篇：Redis响应严重延迟，如何解决？
上一节，分析了一个基于 MySQL 的商品搜索案例，先来回顾一下。在访问商品搜索接口时，发现接口的响应特别慢。通过对系统 CPU、内存和磁盘 I/O 等资源使用情况的分析，发现这时出现了磁盘的 I/O 瓶颈，并且正是案例应用导致的。接着，借助 pidstat，发现罪魁祸首是 mysqld 进程。又通过 strace、lsof，找出了 mysqld 正在读的文件。根据文件的名字和路径，找出了 mysqld 正在操作的数据库和数据表。综合这些信息，猜测这是一个没利用索引导致的慢查询问题。
2025-12-16 14:00:00
738
原创 二十五、案例篇：一个SQL查询要15秒，这是怎么回事？
上一节，分析了一个单词热度应用响应过慢的案例。当用 top、iostat 分析了系统的 CPU 和磁盘 I/O 使用情况后，我们发现系统出现了磁盘的 I/O 瓶颈，而且正是案例应用导致的。接着，在使用 strace 却没有任何发现后，我又给你介绍了两个新的工具 filetop 和 opensnoop，分析它们对系统调用 write() 和 open() 的追踪结果。我们发现，案例应用正在读写大量的临时文件，因此产生了性能瓶颈。
2025-12-16 10:00:00
910
原创 二十四、为什么我的磁盘I_O延迟很高？
上一节，研究了一个狂打日志引发 I/O 性能问题的案例，先来简单回顾一下。日志，是了解应用程序内部运行情况，最常用也是最有效的工具。日志一般会分为调试、信息、警告、错误等多个不同级别。通常，生产环境只用开启警告级别的日志，这一般不会导致 I/O 问题。但在偶尔排查问题时，可能需要我们开启调试日志。调试结束后，很可能忘了把日志级别调回去。这时，大量的调试日志就可能会引发 I/O 性能问题。可以用 iostat ，确认是否有 I/O 性能瓶颈。
2025-12-15 14:00:00
1065
原创 二十三、案例篇：如何找出狂打日志的“内鬼“？
前两节，学了文件系统和磁盘的 I/O 原理，先来复习一下。文件系统，是对存储设备上的文件进行组织管理的一种机制。为了支持各类不同的文件系统，Linux在各种文件系统上，抽象了一层虚拟文件系统VFS。它定义了一组所有文件系统都支持的数据结构和标准接口。这样，应用程序和内核中的其他子系统，就只需要跟 VFS 提供的统一接口进行交互。在文件系统的下层，为了支持各种不同类型的存储设备，Linux又在各种存储设备的基础上，抽象了一个通用块层。通用块层，为文件系统和应用程序提供了访问块设备的标准接口；
2025-12-15 10:00:00
986
原创 二十二、基础篇：Linux磁盘I_O是怎么工作的（下）
上一节学习了 Linux 磁盘 I/O 的工作原理，并了解了由文件系统层、通用块层和设备层构成的 Linux 存储系统 I/O 栈。其中，通用块层是 Linux 磁盘 I/O 的核心。向上，它为文件系统和应用程序，提供访问了块设备的标准接口；向下，把各种异构的磁盘设备，抽象为统一的块设备，并会对文件系统和应用程序发来的 I/O 请求，进行重新排序、请求合并等，提高了磁盘访问的效率。掌握了磁盘 I/O 的工作原理，你估计迫不及待想知道，怎么才能衡量磁盘的 I/O 性能。
2025-12-14 14:00:00
691
原创 二十一、基础篇：Linux磁盘I_O是怎么工作的（上）
上一节，学习了 Linux 文件系统的工作原理。简单回顾一下，文件系统是对存储设备上的文件，进行组织管理的一种机制。而Linux 在各种文件系统实现上，又抽象了一层虚拟文件系统VFS，它定义了一组，所有文件系统都支持的，数据结构和标准接口。这样，对应用程序来说，只需要跟 VFS 提供的统一接口交互，而不需要关注文件系统的具体实现；对具体的文件系统来说，只需要按照 VFS 的标准，就可以无缝支持各种应用程序。VFS 内部又通过目录项、索引节点、逻辑块以及超级块等数据结构，来管理文件。
2025-12-14 10:00:00
1480
原创 二十、基础篇：Linux文件系统是怎样工作的？
通过前面CPU和内存模块的学习，已经掌握了CPU和内存的性能分析以及优化思路。从这一节开始，我们将进入下一个重要模块——文件系统和磁盘的I/O性能。同CPU、内存一样，磁盘和文件系统的管理，也是操作系统最核心的功能。磁盘为系统提供了最基本的持久化存储。文件系统则在磁盘的基础上，提供了一个用来管理文件的树状结构。那么，磁盘和文件系统是怎么工作的呢？又有哪些指标可以衡量它们的性能呢？今天，我就带你先来看看，Linux文件系统的工作原理。磁盘的工作原理，我们下一节再来学习。
2025-12-13 14:00:00
703
原创 十八、案例篇：为什么系统的Swap变高了（下）
上一节学习了 Linux 内存回收，特别是 Swap 的原理，先简单回顾一下。在内存资源紧张时，Linux通过直接内存回收和定期扫描的方式，来释放文件页和匿名页，以便把内存分配给更需要的进程使用。文件页的回收比较容易理解，直接清空缓存，或者把脏数据写回磁盘后，再释放缓存就可以了。而对不常访问的匿名页，则需要通过Swap换出到磁盘中，这样在下次访问的时候，再次从磁盘换入到内存中就可以了。
2025-12-12 14:00:00
544
原创 十七、案例篇：为什么系统的Swap变高了（上）
上一节，通过一个斐波那契数列的案例，学习了内存泄漏的分析。如果在程序中直接或间接地分配了动态内存，一定要记得释放掉它们，否则就会导致内存泄漏，严重时甚至会耗尽系统内存。不过，反过来讲，当发生了内存泄漏时，或者运行了大内存的应用程序，导致系统的内存资源紧张时，系统又会如何应对呢？在内存基础篇我们已经学过，这其实会导致两种可能结果，内存回收和 OOM 杀死进程。
2025-12-12 10:00:00
933
原创 十六、案例篇：内存泄漏了，该如何定位和处理？
通过前几节对内存基础的学习，相信对 Linux 内存的工作原理，已经有了初步了解。对普通进程来说，能看到的其实是内核提供的虚拟内存，这些虚拟内存还需要通过页表，由系统映射为物理内存。当进程通过 malloc() 申请虚拟内存后，系统并不会立即为其分配物理内存，而是在首次访问时，才通过缺页异常陷入内核中分配内存。为了协调 CPU 与磁盘间的性能差异，Linux 还会使用 Cache 和 Buffer ，分别把文件和磁盘读写的数据缓存到内存中。
2025-12-11 14:00:00
544
原创 十九、套路篇：如何“快准狠“找到系统内存的问题？
前几节，通过几个案例，分析了各种常见的内存性能问题。通过学习，对内存的性能分析已经有了基本的思路，也熟悉了很多分析内存性能的工具。你肯定会想，有没有迅速定位内存问题的方法？当定位出内存的瓶颈后，又有哪些优化内存的思路呢？今天，就来梳理一下，怎样可以快速定位系统内存，并且总结了相关的解决思路。
2025-12-11 10:11:36
136
原创 十五、案例篇：如何利用系统缓存优化程序的运行效率？
Buffers 和 Cache 可以极大提升系统的 I/O 性能。通常，我们用缓存命中率，来衡量缓存的使用效率。命中率越高，表示缓存被利用得越充分，应用程序的性能也就越好。可以用 cachestat 和 cachetop 这两个工具，观察系统和进程的缓存命中情况。其中，cachestat 提供了整个系统缓存的读写命中情况。cachetop 提供了每个进程的缓存命中情况。不过要注意，Buffers 和 Cache 都是操作系统来管理的，应用程序并不能直接控制这些缓存的内容和生命周期。
2025-12-11 10:00:00
912
原创 十四、基础篇：怎么理解内存中的Buffer和Cache?
上一节，梳理了 Linux 内存管理的基本原理，并学会了用 free 和 top 等工具，来查看系统和进程的内存使用情况。内存和 CPU 的关系非常紧密，而内存管理本身也是很复杂的机制，所以感觉知识很硬核、很难啃，都是正常的。但还是那句话，初学时不用非得理解所有内容，继续往后学，多理解相关的概念并配合一定的实践之后，再回头复习往往会容易不少。当然，基本功不容放弃。显然，这个界面包含了物理内存Mem和交换分区Swap的具体使用情况，比如总内存、已用内存、缓存、可用内存等。
2025-12-10 14:00:00
938
原创 十三、基础篇：Linux内存是怎样工作的？
前几节学习了 CPU 的性能原理和优化方法，接下来，进入另一个板块——内存。同 CPU 管理一样，内存管理也是操作系统最核心的功能之一。内存主要用来存储系统和应用程序的指令、数据、缓存等。那么，Linux 到底是怎么管理内存的呢？今天，就来一起来看看这个问题。
2025-12-10 10:00:00
1167
原创 十二、套路篇：CPU性能优化的几个思路
今天，梳理了常见的 CPU 性能优化思路和优化方法。发现性能问题后，不要急于动手优化，而要先找出最重要的、可以获得最大性能提升的问题，然后再从应用程序和系统两个方面入手优化。这样不仅可以获得最大的性能提升，而且很可能不需要优化其他问题，就已经满足了性能要求。但是记住，一定要忍住“把 CPU 性能优化到极致”的冲动，因为 CPU 并不是唯一的性能因素。在后续的文章中，我还会介绍更多的性能问题，比如内存、网络、I/O 甚至是架构设计的问题。
2025-12-09 19:00:00
802
原创 十一、套路篇：如何快速分析出系统CPU的瓶颈在哪里？
前几节里，通过几个案例，分析了各种常见的 CPU 性能问题。通过这些，相信对 CPU 的性能分析已经不再陌生和恐惧，起码有了基本的思路，也了解了不少 CPU 性能的分析工具。不过，我猜你可能也碰到了一个我曾有过的困惑： CPU 的性能指标那么多，CPU 性能分析工具也是一抓一大把，如果换成实际的工作场景，我又该观察什么指标、选择哪个性能工具呢？不要担心，今天我就给你总结出一个“又快又准”的瓶颈定位套路，告诉你在不同场景下，指标工具怎么选，性能瓶颈怎么找。
2025-12-09 14:34:49
1149
原创 十、案例篇：系统的软中断CPU使用率升高，该怎么办？
前面讲了软中断的基本原理，先来简单复习下。中断是一种异步的事件处理机制，用来提高系统的并发处理能力。中断事件发生，会触发执行中断处理程序，而中断处理程序被分为上半部和下半部这两个部分。上半部对应硬中断，用来快速处理中断；下半部对应软中断，用来异步处理上半部未完成的工作。Linux 中的软中断包括网络收发、定时、调度、RCU锁等各种类型，可以查看 proc 文件系统中的 /proc/softirqs ，观察软中断的运行情况。
2025-09-16 10:26:38
935
原创 九、基础篇：怎么理解linux软中断？
前面学习了iowait（也就是等待I/O的CPU使用率）升高时的分析方法。这里要记住，进程的不可中断状态是系统的一种保护机制，可以保证硬件的交互过程不被意外打断。所以，短时间的不可中断状态是很正常的。但是，当进程长时间都处于不可中断状态时，就得当心了。这时可以使用 dstat、pidstat 等工具，确认是不是磁盘 I/O 的问题，进而排查相关的进程和磁盘设备。其实除了 iowait，软中断（softirq）CPU使用率升高也是最常见的一种性能问题。
2025-09-09 09:40:07
593
原创 八、案例篇：系统中出现大量不可中断进程和僵尸进程怎么办？（下）
上一节，讲了Linux进程状态的含义，以及不可中断进程和僵尸进程产生的原因，先来简单复习下。使用 ps 或者 top 可以查看进程的状态，这些状态包括运行、空闲、不可中断睡眠、可中断睡眠、僵尸以及暂停等。其中，重点学习了不可中断状态和僵尸进程：不可中断状态，一般表示进程正在跟硬件交互，为了保护进程数据与硬件一致，系统不允许其他进程或中断打断该进程。僵尸进程表示进程已经退出，但它的父进程没有回收该进程所占用的资源。上一节的最后，用一个案例展示了处于这两种状态的进程。
2025-09-04 10:44:52
613
原创 七、案例篇：系统中出现大量不可中断进程和僵尸进程怎么办？（上）
前面，用一个 Nginx+PHP 的案例，讲了服务器 CPU 使用率高的分析和应对方法。当碰到无法解释的 CPU 使用率问题时，先要检查一下是不是短时应用在捣鬼。短时应用的运行时间比较短，很难在 top 或者 ps 这类展示系统概要和进程快照的工具中发现，你需要使用记录事件的工具来配合诊断，比如 execsnoop 或者 perf top。另外，我们还讲到 CPU 使用率的类型。
2025-09-04 10:12:17
568
原创 六、案例篇：系统的CPU使用率高，但为啥找不到高CPU的应用？
回顾前面的内容，我们知道，系统的 CPU 使用率，不仅包括进程用户态和内核态的运行，还包括中断处理、等待 I/O 以及内核线程等。所以，当发现系统的 CPU 使用率很高的时候，不一定能找到相对应的高 CPU 使用率的进程。今天，我就用一个 Nginx + PHP 的 Web 服务的案例，来分析这种情况。
2025-09-02 14:54:43
941
原创 五、基础篇：应用的CPU使用率达到100%，我该怎么办？
之前进行了平均负载和 CPU 上下文切换的学习，已经对 CPU 的性能已经有了初步了解。不过还是想问一下，最常用什么指标来描述系统的 CPU 性能呢？我想你的答案，可能不是平均负载，也不是 CPU 上下文切换，而是另一个更直观的指标—— CPU 使用率。前面说过，CPU 使用率是单位时间内 CPU 使用情况的统计，以百分比的方式展示。那么，作为最常用也是最熟悉的 CPU 指标，你能说出 CPU 使用率到底是怎么算出来的吗？带着这个问题来开始接下来的探索和分析，进一步了解CPU使用率的内容。
2025-08-29 11:26:42
812
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人