- 博客(88)
- 收藏
- 关注
RSS订阅原创 二十、分析篇 如何分析CPU利用率飙高问题 ？
我们这节的内容，对于应用开发者和运维人员而言是有些难度的。我之所以讲这些有难度的内容，就是希望你可以拓展分析问题的边界。这节课的内容对内核开发者而言基本都是基础知识，如果你看不太明白，说明你对内核的理解还不够，你需要花更多的时间好好学习它。strace工具是应用和内核的边界，如果你是一名应用开发者，并且想去拓展分析问题的边界，那你就需要去了解strace的原理，还需要了解如何去分析strace发现的问题；ftrace是分析内核问题的利器，你需要去了解它；
2026-01-13 14:00:00
951
原创 十九、案例篇 网络吞吐高的业务是否需要开启网卡特性呢？
硬中断、软中断以及ksoftirqd这个内核线程，它们与用户线程之间的关系是相对容易引发业务抖动的地方，你需要掌握它们的观测方式；硬中断对业务的主要影响体现在硬中断的发生频率上，但是它也容易受线程影响，因为内核里关中断的地方有很多；软中断的执行时间如果太长，就会给用户线程带来延迟，你需要避免你的系统中存在耗时较大的软中断处理程序。如果有的话，你需要去做优化；ksoftirqd的优先级与用户线程是一致的，因此，如果软中断处理函数是在ksoftirqd里执行的，那它可能会有一些延迟；
2026-01-13 10:00:00
736
原创 十八、案例篇 业务是否需要使用透明大页：水可载舟，亦可覆舟？
细化CPU利用率监控，在CPU利用率高时，你需要查看具体是哪一项指标比较高；sysrq是分析内核态CPU利用率高的利器，也是分析很多内核疑难问题的利器，你需要去了解如何使用它；THP可以给业务带来性能提升，但也可能会给业务带来严重的稳定性问题，你最好以madvise的方式使用它。如果你不清楚如何使用它，那就把它关闭。
2026-01-12 14:00:00
621
原创 十七、基础篇 CPU是如何执行任务的？
要想明白CPU是如何执行任务的，你首先需要去了解CPU的架构；CPU的存储层次对大型软件系统的性能影响会很明显，也是你在性能调优时需要着重考虑的；高并发场景下的Cache Line伪共享问题是一个普遍存在的问题，你需要留意一下它；系统中需要运行的线程数可能大于CPU核数，这样就会导致线程排队等待CPU，这可能会导致一些延迟。如果你的任务对延迟容忍度低，你可以通过一些手段来人为干预Linux默认的调度策略。
2026-01-12 10:00:00
1650
原创 十六、套路篇 如何分析常见的TCP问题？
尽量不要使用netstat命令，而是多使用它的替代品ss，因为ss的性能开销更小，运行也更快；当你面对网络问题一筹莫展时，可以考虑使用tcpdump抓包看看，当系统中的网络连接数较大时，它对系统性能会产生比较明显的影响，所以你需要想办法避免它给业务带来实质影响；TCP Tracepoints是比较轻量级的分析方案，你需要去了解它们，最好试着去用一下它们。
2026-01-09 14:00:00
1619
原创 十五、分析篇 如何高效地分析TCP重传问题？
我在“开篇词”中举过一个TCP重传率的例子，如下图所示：这是互联网企业普遍都有的TCP重传率监控，它是服务器稳定性的一个指标，如果它太高，就像上图中的那些毛刺一样，往往就意味着服务器不稳定了。那TCP重传率究竟表示什么呢？其实TCP重传率是通过解析/proc/net/snmp这个文件里的指标计算出来的，这个文件里面和TCP有关的关键指标如下：也就是说，单位时间内TCP重传包的数量除以TCP总的发包数量，就是TCP重传率。
2026-01-09 10:00:00
720
原创 十四、案例篇 TCP端到端时延变大，怎样判断是哪里出现了问题？
我们这节以典型的C/S架构为例，分析了RT发生抖动时，该如何高效地识别出问题发生在哪里。tcpdump是分析网络问题必须要掌握的工具，但是用它分析问题并不容易。在你不清楚该如何分析网络问题时，你可以先使用tcpdump把现场信息保存下来；TCP是数据流，如何把TCP流和具体的业务请求/响应数据包关联起来，是分析具体应用问题的前提。你需要结合你的业务模型来做合理的关联；RT抖动问题是很棘手的，你需要结合你的业务模型来开发一些高效的问题分析工具。
2026-01-08 14:00:00
937
原创 十三、案例篇 TCP拥塞控制是如何导致业务性能抖动的？
TCP拥塞控制是一个非常复杂的行为，我们在这节课里讲到的内容只是其中一些基础部分，希望这些基础知识可以让你对TCP拥塞控制有个大致的了解。网络拥塞状况会体现在TCP连接的拥塞窗口（cwnd）中，该拥塞窗口会影响发送方的发包行为；接收方的处理能力同样会反馈给发送方，这个处理是通过rwnd来表示的。rwnd和cwnd会共同作用于发送方，来决定发送方最大能够发送多少TCP包；
2026-01-08 10:00:00
599
原创 十二、基础篇 TCP收发包过程会受哪些配置项影响？
好了，这节就讲到这里，我们简单回顾一下。TCP/IP是一个很复杂的协议栈，它的数据包收发过程也是很复杂的，我们这节课只是重点围绕这个过程中最容易引发问题的地方来讲述的。我们刚才提到的那些配置选项都很容易在生产环境中引发问题，并且也是我们针对高性能网络进行调优时必须要去考虑的。我把这些配置项也总结为了一个表格，方便你来查看：这些值都需要根据你的业务场景来做灵活的调整，当你不知道针对你的业务该如何调整时，你最好去咨询更加专业的人员，或者一边调整一边观察系统以及业务行为的变化。
2026-01-07 14:00:00
922
原创 十一、基础篇 TCP连接的建立和断开受哪些系统配置影响？
这节我们讲了很多的配置项，我把这些配置项汇总到了下面这个表格里，方便你记忆：当然了，有些配置项也是可以根据你的服务器负载以及CPU和内存大小来做灵活配置的，比如tcp_max_syn_backlog、somaxconn、tcp_max_tw_buckets这三项，如果你的物理内存足够大、CPU核数足够多，你可以适当地增大这些值，这些往往都是一些经验值。另外，我们这节的目的不仅仅是为了让你去了解这些配置项，最主要的是想让你了解其背后的机制，这样你在遇到一些问题时，就可以有一个大致的分析方向。
2026-01-07 10:00:00
3293
2
原创 十、分析篇 内存泄漏时，我们该如何一步步找到根因？
top工具和/proc/meminfo文件是分析Linux上内存泄漏问题，甚至是所有内存问题的第一步，我们先找出来哪个进程或者哪一项有异常，然后再针对性地分析；应用程序的内存泄漏千奇百怪，所以你需要掌握一些通用的分析技巧，掌握了这些技巧很多时候就可以以不变应万变。但是，这些技巧的掌握，是建立在你的基础知识足够扎实的基础上。你需要熟练掌握我们这个系列课程讲述的这些基础知识，熟才能生巧。
2026-01-06 14:00:00
1761
原创 九、分析篇 如何对内核内存泄漏做些基础的分析？
这节我们讲了一种更难分析以及引起危害更大的内存泄漏：内核内存泄漏。你可以通过/proc/meminfo里面的信息来看内核内存的使用情况，然后根据这里面的信息来做一些基本的判断：如果内核太大那就值得怀疑；kmemleak是内核内存分析的利器，但是一般只在测试环境上使用它，因为它对性能会有比较明显的影响；在生产环境中可以使用tracepoint或者kprobe，来追踪特定类型内核内存的申请和释放，从而帮助我们判断是否存在内存泄漏。但这往往需要专业的知识，你在不明白的时候可以去请教一些内核专家；
2026-01-06 10:00:00
960
原创 八、案例篇 Shmem：进程没有消耗内存，内存哪去了？
这节，我们学习了tmpfs这种类型的内存泄漏以及它的观察方法，这种类型的内存泄漏和其他进程内存泄漏最大的不同是，你很难通过进程消耗的内存来判断是哪里在泄漏，因为这种类型的内存不会体现在进程的RES中。但是，如果你熟悉内存问题的常规分析方法，你就能很快地找到问题所在。在不清楚内存被谁消耗时，你可以通过/proc/meminfo找到哪种类型的内存开销比较大，然后再对这种类型的内存做针对性分析。
2026-01-05 14:00:00
1700
原创 七、案例篇 如何预防内存泄漏导致的系统假死？
这节我们讲了什么是内存泄漏，以及内存泄漏可能造成的危害。对于长时间运行的后台任务而言，它存在的内存泄漏可能会给系统带来比较严重的危害，所以我们一定要重视这些任务的内存泄漏问题。内存泄漏问题是非常容易发生的，所以我们需要提前做好内存泄漏的兜底工作：即使有泄漏了也不要让它给系统带来很大的危害。长时间的内存泄漏问题最后基本都会以OOM结束，所以你需要去掌握OOM的相关知识，来做好这个兜底工作。
2026-01-05 10:00:00
1001
原创 六、 基础篇 进程的哪些内存类型容易引起内存泄漏？
这节我们讲述进程内存管理相关的一些知识，包括进程的虚拟内存与物理内存，要点如下。进程直接读写的都是虚拟地址，虚拟地址最终会通过Paging（分页）来转换为物理内存的地址，Paging这个过程是由内核来完成的。进程的内存类型可以从anon（匿名）与file（文件）、private（私有）与shared（共享）这四项来区分为4种不同的类型，进程相关的所有内存都是这几种方式的不同组合。查看进程内存时，可以先使用top来看系统中各个进程的内存使用概况，再使用pmap去观察某个进程的内存细节。
2026-01-04 14:00:00
1428
原创 五、分析篇 如何判断问题是否由Page Cache产生的？
好了，这节我们就讲到这里，我们简单回顾一下。这节我们讲了Page Cache问题的分析方法论，按照这个方法论我们几乎可以分析清楚Page Cache相关的所有问题，而且也能帮助我们了解业务的内存访问模式，从而帮助我们更好地对业务来做优化。当然这套分析方法论不仅仅适用于Page Cache引发的问题，对于系统其他层面引起的问题同样也适用。在观察Page Cache的行为时，你可以先从最简单易用的分析工具比如sar入手，来得到一个概况，然后再使用更加专业一些的工具比如tracepoint去做更细致的分析。
2026-01-04 10:00:00
709
原创 四、案例篇 如何处理Page Cache容易回收引起的业务性能问题？
我们在前一篇讲到了Page Cache回收困难引起的load飙高问题，这也是很直观的一类问题；在这一篇讲述的则是一类相反的问题，即Page Cache太容易被回收而引起的一些问题，这一类问题是不那么直观的一类问题。对于很直观的问题，我们相对比较容易去观察分析，而且由于它们比较容易观察，所以也相对能够得到重视；对于不直观的问题，则不是那么容易观察分析，相对而言它们也容易被忽视。外在的特征不明显，并不意味着它产生的影响不严重，就好比皮肤受伤流血了，我们知道需要立即止血这个伤病也能很容易得到控制；
2025-12-31 14:00:00
1070
原创 三、案例篇 如何处理Page Cache难以回收产生的load飙高问题？
这节我们讲的这几个案例都是内存回收过程中引起的load飙高问题。关于内存回收这事，我们可以做一个形象的类比。我们知道，内存是操作系统中很重要的一个资源，它就像我们在生活过程中很重要的一个资源——钱一样，如果你的钱（内存）足够多，那想买什么就可以买什么，而不用担心钱花完（内存用完）后要吃土（引起load飙高）。
2025-12-31 10:00:00
567
原创 二、基础篇 Page Cache是怎样产生和释放的？
Page Cache是在应用程序读写文件的过程中产生的，所以在读写文件之前你需要留意是否还有足够的内存来分配Page Cache；Page Cache中的脏页很容易引起问题，你要重点注意这一块；在系统可用内存不足的时候就会回收Page Cache来释放出来内存，我建议你可以通过sar或者/proc/vmstat来观察这个行为从而更好的判断问题是否跟回收有关总的来说，Page Cache的生命周期对于应用程序而言是相对比较透明的，即它的分配与回收都是由操作系统来进行管理的。
2025-12-30 14:00:00
804
原创 一、基础篇 如何用数据观测Page Cache？
我记得很多应用开发者或者运维在向我寻求帮助，解决Page Cache引起的问题时，总是喜欢问我Page Cache到底是属于内核还是属于用户？针对这样的问题，我一般会让他们先看下面这张图：通过这张图片你可以清楚地看到，红色的地方就是Page Cache，很明显，Page Cache是内核管理的内存，也就是说，它属于内核不属于用户。那咱们怎么来观察Page Cache呢？
2025-12-30 10:00:00
927
原创 五十二、套路篇：Linux 性能工具速查
上一节，一起梳理了常见的性能优化思路，先简单回顾一下。我们可以从系统和应用程序两个角度，来进行性能优化。性能优化最好逐步完善，动态进行。不要追求一步到位，而要首先保证能满足当前的性能要求。性能优化通常意味着复杂度的提升，也意味着可维护性的降低。如果你发现单机的性能调优带来过高复杂度，一定不要沉迷于单机的极限性能，而要从软件架构的角度，以水平扩展的方法来提升性能。工欲善其事，必先利其器。我们知道，在性能分析和优化时，借助合适的性能工具，可以让整个过程事半功倍。你还记得有哪些常用的性能工具吗？
2025-12-29 14:00:00
605
原创 五十一、套路篇：优化性能问题的一般方法
上一节，一起梳理了性能问题分析的一般步骤。先简单回顾一下。我们可以从系统资源瓶颈和应用程序瓶颈，这两个角度来分析性能问题的根源。从系统资源瓶颈的角度来说，USE 法是最为有效的方法，即从使用率、饱和度以及错误数这三个方面，来分析 CPU、内存、磁盘和文件系统 I/O、网络以及内核资源限制等各类软硬件资源。至于这些资源的分析方法，我也带你一起回顾了，咱们专栏前面几大模块的分析套路。从应用程序瓶颈的角度来说，可以把性能问题的来源，分为资源瓶颈、依赖服务瓶颈以及应用自身的瓶颈这三类。
2025-12-29 10:00:00
1066
原创 五十、套路篇：分析性能问题的一般步骤
上一节，一起学习了应用程序监控的基本思路，先简单回顾一下。应用程序的监控，可以分为指标监控和日志监控两大块。在跨多个不同应用的复杂业务场景中，你还可以构建全链路跟踪系统。这样，你就可以动态跟踪调用链中各个组件的性能，生成整个应用的调用拓扑图，从而加快定位复杂应用的性能问题。不过，如果你收到监控系统的告警，发现系统资源或者应用程序出现性能瓶颈，又该如何进一步分析它的根源呢？今天，我就分别从系统资源瓶颈和应用程序瓶颈这两个角度，带你一起来看看，性能分析的一般步骤。
2025-12-28 14:00:00
1610
原创 四十九、套路篇：应用监控的一般思路
上一节，学习了如何使用 USE 法来监控系统的性能，先简单回顾一下。系统监控的核心是资源的使用情况，这既包括CPU、内存、磁盘、文件系统、网络等硬件资源，也包括文件描述符数、连接数、连接跟踪数等软件资源。而要描述这些资源瓶颈，最简单有效的方法就是 USE 法。USE 法把系统资源的性能指标，简化为了三个类别：使用率、饱和度以及错误数。当这三者之中任一类别的指标过高时，都代表相对应的系统资源可能存在性能瓶颈。
2025-12-28 10:00:00
693
原创 四十八、套路篇：系统监控的综合思路
在前面的内容中，介绍了很多性能分析的原理、思路以及相关的工具。不过，在实际的性能分析中，一个很常见的现象是，明明发生了性能瓶颈，但当你登录到服务器中想要排查的时候，却发现瓶颈已经消失了。或者说，性能问题总是时不时地发生，但却很难找出发生规律，也很难重现。当面对这样的场景时，你可能会发现，前面介绍的各种工具、方法都“失效“了。为什么呢？因为它们都需要在性能问题发生的时刻才有效，而在这些事后分析的场景中，我们就很难发挥它们的威力了。那该怎么办呢？置之不理吗？
2025-12-27 14:00:00
545
原创 四十七、案例篇：服务吞吐量下降很厉害，怎么分析？
上一节，学习了怎么使用动态追踪来观察应用程序和内核的行为。先简单来回顾一下。所谓动态追踪，就是在系统或者应用程序还在正常运行的时候，通过内核中提供的探针，来动态追踪它们的行为，从而辅助排查出性能问题的瓶颈。使用动态追踪，便可以在不修改代码也不重启服务的情况下，动态了解应用程序或者内核的行为。这对排查线上的问题、特别是不容易重现的问题尤其有效。在 Linux 系统中，常见的动态追踪方法包括 ftrace、perf、eBPF/BCC 以及 SystemTap 等。
2025-12-27 10:00:00
995
原创 四十六、案例篇：动态追踪怎么用？（下）
上一节，一起学习了常见的动态追踪方法。所谓动态追踪，就是在系统或者应用程序正常运行的时候，通过内核中提供的探针，来动态追踪它们的行为，从而辅助排查出性能问题的瓶颈。使用动态追踪，可以在不修改代码、不重启服务的情况下，动态了解应用程序或者内核的行为，这对排查线上问题、特别是不容易重现的问题尤其有效。在 Linux 系统中，常见的动态追踪方法包括 ftrace、perf、eBPF 以及 SystemTap 等。上节课，我们具体学习了 ftrace 的使用方法。今天，我们再来一起看看其他几种方法。
2025-12-26 16:00:00
906
原创 四十五、案例篇：动态追踪怎么用？（上）
这些探针只有在开启探测功能时，才会被执行到；未开启时并不会执行。常见的静态探针包括内核中的跟踪点（tracepoints）和 USDT（Userland Statically Defined Tracing）探针。
2025-12-26 10:00:00
1043
原创 四十四、案例篇：内核线程 CPU 利用率太高，我该怎么办？
上一期，梳理了网络时不时丢包的分析定位和优化方法。先简单回顾一下。网络丢包，通常会带来严重的性能下降，特别是对 TCP 来说，丢包通常意味着网络拥塞和重传，进而会导致网络延迟增大以及吞吐量降低。而分析丢包问题，还是用我们的老套路，从 Linux 网络收发的流程入手，结合 TCP/IP 协议栈的原理来逐层分析。其实，在排查网络问题时，还经常碰到的一个问题，就是内核线程的 CPU 使用率很高。比如，在高并发的场景中，内核线程 ksoftirqd 的 CPU 使用率通常就会比较高。
2025-12-25 14:00:00
860
原创 四十三、案例篇：服务器总是时不时丢包，我该怎么办？（下）
上一节，学习了如何分析网络丢包的问题，特别是从链路层、网络层以及传输层等主要的协议栈中进行分析。不过，通过前面这几层的分析，还是没有找出最终的性能瓶颈。看来，还是要继续深挖才可以。今天，就来继续分析这个未果的案例。在开始下面的内容前，可以先回忆一下上节课的内容，并且自己动脑想一想，除了我们提到的链路层、网络层以及传输层之外，还有哪些潜在问题可能会导致丢包呢？
2025-12-25 10:00:00
1556
原创 四十二、案例篇：服务器总是时不时丢包，我该怎么办？（上）
上一节，梳理了应用程序容器化后性能下降的分析方法。简单回顾下。容器利用 Linux 内核提供的命名空间技术，将不同应用程序的运行隔离起来，并用统一的镜像，来管理应用程序的依赖环境。这为应用程序的管理和维护，带来了极大的便捷性，并进一步催生了微服务、云原生等新一代技术架构。不过，虽说有很多优势，但容器化也会对应用程序的性能带来一定影响。比如，上一节我们一起分析的 Java 应用，就容易发生启动过慢、运行一段时间后 OOM 退出等问题。
2025-12-24 14:00:00
959
原创 四十一、案例篇：为什么应用容器化后，启动慢了很多？
不知不觉，已经学完了整个专栏的四大基础模块，即 CPU、内存、文件系统和磁盘 I/O、以及网络的性能分析和优化。相信你已经掌握了这些基础模块的基本分析、定位思路，并熟悉了相关的优化方法。接下来，我们将进入最后一个重要模块—— 综合实战篇。这部分实战内容，也将是我们对前面所学知识的复习和深化。我们都知道，随着 Kubernetes、Docker 等技术的普及，越来越多的企业，都已经走上了应用程序容器化的道路。不过，任何技术都不是银弹。
2025-12-24 10:00:00
631
原创 四十、套路篇：网络性能优化的几个思路（下）
上一节，学了网络性能优化的几个思路，我先带你简单复习一下。在优化网络的性能时，你可以结合 Linux 系统的网络协议栈和网络收发流程，然后从应用程序、套接字、传输层、网络层再到链路层等每个层次，进行逐层优化。今天，我们顺着 TCP/IP 网络模型，继续向下，看看如何从传输层、网络层以及链路层中，优化 Linux 网络性能。
2025-12-23 14:00:00
893
原创 三十九、套路篇：网络性能优化的几个思路（上）
上一节，了解了NAT（网络地址转换）的原理，学会了如何排查 NAT 带来的性能问题，最后还总结了 NAT 性能优化的基本思路。先来简单回顾一下。NAT 基于 Linux 内核的连接跟踪机制，实现了 IP 地址及端口号重写的功能，主要被用来解决公网 IP 地址短缺的问题。在分析 NAT 性能问题时，可以先从内核连接跟踪模块 conntrack 角度来分析，比如用 systemtap、perf、netstat 等工具，以及 proc 文件系统中的内核选项，来分析网络协议栈的行为；
2025-12-23 10:00:00
680
原创 三十八、案例篇：如何优化 NAT 性能？（下）
上一节，学习了 NAT 的原理，明白了如何在 Linux 中管理 NAT 规则。先来简单复习一下。NAT 技术能够重写 IP 数据包的源 IP 或目的 IP，所以普遍用来解决公网 IP 地址短缺的问题。它可以让网络中的多台主机，通过共享同一个公网 IP 地址，来访问外网资源。同时，由于 NAT 屏蔽了内网网络，也为局域网中机器起到安全隔离的作用。Linux 中的NAT ，基于内核的连接跟踪模块实现。所以，它维护每个连接状态的同时，也对网络性能有一定影响。那么，碰到 NAT 性能问题时，我们又该怎么办呢。
2025-12-22 14:00:00
702
原创 三十七、案例篇：如何优化 NAT 性能？（上）
上一节，探究了网络延迟增大问题的分析方法，并通过一个案例，掌握了如何用 hping3、tcpdump、Wireshark、strace 等工具，来排查和定位问题的根源。简单回顾一下，网络延迟是最核心的网络性能指标。由于网络传输、网络包处理等各种因素的影响，网络延迟不可避免。但过大的网络延迟，会直接影响用户的体验。所以，在发现网络延迟增大的情况后，你可以先从路由、网络包的收发、网络包的处理，再到应用程序等，从各个层级分析网络延迟，等到找出网络延迟的来源层级后，再深入定位瓶颈所在。
2025-12-22 10:00:00
1607
原创 三十六、网络请求延迟变大了，该怎么办？
上一节，学习了碰到分布式拒绝服务（DDoS）的缓解方法。简单回顾一下，DDoS 利用大量的伪造请求，导致目标服务要耗费大量资源，来处理这些无效请求，进而无法正常响应正常用户的请求。由于 DDoS 的分布式、大流量、难追踪等特点，目前确实还没有方法，能够完全防御 DDoS 带来的问题，我们只能设法缓解 DDoS 带来的影响。比如，你可以购买专业的流量清洗设备和网络防火墙，在网络入口处阻断恶意流量，只保留正常流量进入数据中心的服务器。
2025-12-21 14:00:00
1211
原创 三十五、案例篇：怎么缓解 DDoS 攻击带来的性能下降问题？
DDoS 的前身是 DoS（Denail of Service），即拒绝服务攻击，指利用大量的合理请求，来占用过多的目标资源，从而使目标服务无法响应正常请求。DDoS（Distributed Denial of Service） 则是在 DoS 的基础上，采用了分布式架构，利用多台主机同时攻击目标主机。这样，即使目标服务部署了网络防御设备，面对大量网络请求时，还是无力应对。
2025-12-21 10:00:00
747
原创 三十四、案例篇：怎么使用 tcpdump 和 Wireshark 分析网络流量？
上一节，学习了 DNS 性能问题的分析和优化方法。简单回顾一下，DNS 可以提供域名和 IP 地址的映射关系，也是一种常用的全局负载均衡（GSLB）实现方法。通常，需要暴露到公网的服务，都会绑定一个域名，既方便了人们记忆，也避免了后台服务 IP 地址的变更影响到用户。不过要注意，DNS 解析受到各种网络状况的影响，性能可能不稳定。比如公网延迟增大，缓存过期导致要重新去上游服务器请求，或者流量高峰时 DNS 服务器性能不足等，都会导致 DNS 响应的延迟增大。
2025-12-20 14:00:00
729
原创 三十三、案例篇：DNS 解析时快时慢，该怎么办？
上一节，学习了网络性能的评估方法。简单回顾一下，Linux 网络基于 TCP/IP 协议栈构建，而在协议栈的不同层，所关注的网络性能也不尽相同。在应用层，关注的是应用程序的并发连接数、每秒请求数、处理延迟、错误数等，可以使用 wrk、JMeter 等工具，模拟用户的负载，得到想要的测试结果。而在传输层，关注的是 TCP、UDP 等传输层协议的工作状况，比如 TCP 连接数、 TCP 重传、TCP 错误数等。此时，可以使用 iperf、netperf 等，来测试 TCP 或 UDP 的性能。
2025-12-20 10:00:00
1316
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人