一.上节回顾 专栏更新至今,四大基础模块的最后一个模块——网络篇,我们就已经学完了.很开心你还没有掉队,仍然在积极学习思考和实践操作,热情地留言和互动.还有不少同学分享了在实际生产环境中,碰到各种性能问题的分析思路和优化方法,这里也谢谢你们. 今天是性能优化答疑的第五期.照例,我从网络模块的留言中,摘出了一些典型问题,作为今天的答疑内容,集中回复.同样的,为了便于你学习理解,它们并不是严格按照文章顺序排列的. 每个问题,我都附上了留言区提问的截屏.如果你需要回顾内容原文,可以扫描每个问题右下方的

一.上节总结 专栏更新至今,四大基础模块的第三个模块——文件系统和磁盘 I/O 篇,我们就已经学完了.很开心你还没有掉队,仍然在积极学习思考和实践操作,并且热情地留言与讨论. 今天是性能优化的第四期.照例,我从 I/O 模块的留言中摘出了一些典型问题,作为今天的答疑内容,集中回复.同样的,为了便于你学习理解,它们并不是严格按照文章顺序排列的. 每个问题,我都附上了留言区提问的截屏.如果你需要回顾内容原文,可以扫描每个问题右下方的二维码查看. 二.问题 1:阻塞.非阻塞 I/O 与同步.异步 I/

一.上节总结回顾 上一节,我们回顾了经典的 C10K 和 C1000K 问题.简单回顾一下,C10K 是指如何单机同时处理 1 万个请求(并发连接 1 万)的问题,而 C1000K 则是单机支持处理 100 万个请求(并发连接 100 万)的问题. I/O 模型的优化,是解决 C10K 问题的最佳良方.Linux 2.6 中引入的 epoll,完美解决了C10K 的问题,并一直沿用至今.今天的很多高性能网络方案,仍都基于 epoll. 自然,随着互联网技术的普及,催生出更高的性能需求.从 C10

一.上节回顾 上一节,我们了解了 NAT(网络地址转换)的原理,学会了如何排查 NAT 带来的性能问题,最后还总结了 NAT 性能优化的基本思路.我先带你简单回顾一下. NAT 基于 Linux 内核的连接跟踪机制,实现了 IP 地址及端口号重写的功能,主要被用来解决公网 IP 地址短缺的问题. 在分析 NAT 性能问题时,可以先从内核连接跟踪模块 conntrack 角度来分析,比如用systemtap.perf.netstat 等工具,以及 proc 文件系统中的内核选项,来分析网络协议栈的

一.上节回顾 上一节,我们学了网络性能优化的几个思路,我先带你简单复习一下. 在优化网络的性能时,你可以结合 Linux 系统的网络协议栈和网络收发流程,然后从应用程序.套接字.传输层.网络层再到链路层等每个层次,进行逐层优化.上一期我们主要学习了应用程序和套接字的优化思路,比如: 在应用程序中,主要优化 I/O 模型.工作模型以及应用层的网络协议: 在套接字层中,主要优化套接字的缓冲区大小. 今天,我们顺着 TCP/IP 网络模型,继续向下,看看如何从传输层.网络层以及链路层中,优化 Linu

一.上节回顾 上一节,我们一起学习了怎么使用动态追踪来观察应用程序和内核的行为.先简单来回顾一下.所谓动态追踪,就是在系统或者应用程序还在正常运行的时候,通过内核中提供的探针,来动态追踪它们的行为,从而辅助排查出性能问题的瓶颈. 使用动态追踪,便可以在不修改代码也不重启服务的情况下,动态了解应用程序或者内核的行为.这对排查线上的问题.特别是不容易重现的问题尤其有效. 在 Linux 系统中,常见的动态追踪方法包括 ftrace.perf.eBPF/BCC 以及 SystemTap 等. 使用 p

一.上节回顾 上一节,我们一起学习了,应用程序监控的基本思路,先简单回顾一下.应用程序的监控,可以分为指标监控和日志监控两大块. 指标监控,主要是对一定时间段内的性能指标进行测量,然后再通过时间序列的方式,进行处理.存储和告警. 而日志监控,则可以提供更详细的上下文信息,通常通过 ELK 技术栈,来进行收集.索引和图形化展示. 在跨多个不同应用的复杂业务场景中,你还可以构建全链路跟踪系统.这样,你就可以动态跟踪调用链中各个组件的性能,生成整个应用的调用拓扑图,从而加快定位复杂应用的性能问题. 不

一.上节回顾 专栏更新至今,咱们专栏最后一部分——综合案例模块也要告一段落了.很高兴看到你没有掉队,仍然在积极学习思考.实践操作,并热情地分享你在实际环境中,遇到过的各种性能问题的分析思路以及优化方法. 今天是性能优化答疑的第六期.照例,我从综合案例模块的留言中,摘出了一些典型问题,作为今天的答疑内容,集中回复.为了便于你学习理解,它们并不是严格按照文章顺序排列的.每个问题,我都附上了留言区提问的截屏.如果你需要回顾内容原文,可以扫描每个问题右下方的二维码查看. 二.问题 1:容器冷启动性能分析

一.内存的分配和回收 1.管理内存的过程中,也很容易发生各种各样的“事故”, 对应用程序来说,动态内存的分配和回收,是既核心又复杂的一的一个逻辑功能模块.管理内存的过程中,也很容易发生各种各样的“事故”, 比如,没正确回收分配后的内存,导致了泄漏.访问的是已分配内存边界外的地址,导致程序异常退出,等等. 你在程序中定义了一个局部变量,比如一个整数数组 int data[64] ,就定义了一个可以存储 64 个整数的内存段.由于这是一个局部变量,它会从内它会从内存空间的栈中分配内存 1.栈内存由系

一.上节回顾 上一节,我们一起回顾了常见的文件系统和磁盘 I/O 性能指标,梳理了核心的 I/O 性能观测工具,最后还总结了快速分析 I/O 性能问题的思路. 虽然 I/O 的性能指标很多,相应的性能分析工具也有好几个,但理解了各种指标的含义后,你就会发现它们其实都有一定的关联. 顺着这些关系往下理解,你就会发现,掌握这些常用的瓶颈分析思路,其实并不难.找出了 I/O 的性能瓶颈后,下一步要做的就是优化了,也就是如何以最快的速度完成 I/O 操作,或者换个思路,减少甚至避免磁盘的 I/O 操作.

一.上节回顾 上一节,我带你一起梳理了,性能问题分析的一般步骤.先带你简单回顾一下. 我们可以从系统资源瓶颈和应用程序瓶颈,这两个角度来分析性能问题的根源. 从系统资源瓶颈的角度来说,USE 法是最为有效的方法,即从使用率.饱和度以及错误数这三个方面,来分析 CPU.内存.磁盘和文件系统 I/O.网络以及内核资源限制等各类软硬件资源.至于这些资源的分析方法,我也带你一起回顾了,咱们专栏前面几大模块的分析套路. 从应用程序瓶颈的角度来说,可以把性能问题的来源,分为资源瓶颈.依赖服务瓶颈以及应用自身

一.上节回顾 上一节,我带你一起梳理了常见的性能优化思路,先简单回顾一下.我们可以从系统和应用程序两个角度,来进行性能优化. 从系统的角度来说,主要是对 CPU.内存.网络.磁盘 I/O 以及内核软件资源等进行优化. 而从应用程序的角度来说,主要是简化代码.降低 CPU 使用.减少网络请求和磁盘 I/O,并借助缓存.异步处理.多进程和多线程等,提高应用程序的吞吐能力. 性能优化最好逐步完善,动态进行.不要追求一步到位,而要首先保证能满足当前的性能要求. 性能优化通常意味着复杂度的提升,也意味着可

一.性能优化方法论 不可中断进程案例 二.怎么评估性能优化的效果? 1.评估思路 2.几个为什么 1.为什么要选择不同维度的指标? 应用程序和系统资源是相辅相成的关系 2.性能优化的最终目的和结果? 好的应用程序 3.为什么必须要使用应用程序的指标,来评估性能优化的整体效果? 系统优化总是为应用程序服务的 4.为什么需要用系统资源的指标,来观察和分析瓶颈的来源 系统资源的使用情况是影响应用程序性能的根源 三.多个性能问题同时存在,要怎么选择? 四.有多种优化方法时,要如何选择? 五.系统优化 六

一.上节回顾 上一节,我带你一起学习了网络性能的评估方法.简单回顾一下,Linux 网络基于 TCP/IP协议栈构建,而在协议栈的不同层,我们所关注的网络性能也不尽相同. 在应用层,我们关注的是应用程序的并发连接数.每秒请求数.处理延迟.错误数等,可以使用 wrk.Jmeter 等工具,模拟用户的负载,得到想要的测试结果. 而在传输层,我们关注的是 TCP.UDP 等传输层协议的工作状况,比如 TCP 连接数.TCP 重传.TCP 错误数等.此时,你可以使用 iperf.netperf 等,来测

一.上节回顾 不知不觉,我们已经学完了整个专栏的四大基础模块,即 CPU.内存.文件系统和磁盘 I/O.以及网络的性能分析和优化.相信你已经掌握了这些基础模块的基本分析.定位思路,并熟悉了相关的优化方法. 接下来,我们将进入最后一个重要模块—— 综合实战篇.这部分实战内容,也将是我们对前面所学知识的复习和深化. 我们都知道,随着 Kubernetes.Docker 等技术的普及,越来越多的企业,都已经走上了应用程序容器化的道路.我相信,你在了解学习这些技术的同时,一定也听说过不少,基于 Dock

一.上节回顾 前几节,我们一起学习了文件系统和磁盘 I/O 的工作原理,以及相应的性能分析和优化方法.接下来,我们将进入下一个重要模块—— Linux 的网络子系统. 由于网络处理的流程最复杂,跟我们前面讲到的进程调度.中断处理.内存管理以及 I/O等都密不可分,所以,我把网络模块作为最后一个资源模块来讲解. 同 CPU.内存以及 I/O 一样,网络也是 Linux 系统最核心的功能.网络是一种把不同计算机或网络设备连接到一起的技术,它本质上是一种进程间通信方式,特别是跨系统的进程间通信,必须要

一.上节回顾 前面内容,我们学习了 Linux 网络的基础原理以及性能观测方法.简单回顾一下,Linux网络基于 TCP/IP 模型,构建了其网络协议栈,把繁杂的网络功能划分为应用层.传输层.网络层.网络接口层等四个不同的层次,既解决了网络环境中设备异构的问题,也解耦了网络协议的复杂性. 基于 TCP/IP 模型,我们还梳理了 Linux 网络收发流程和相应的性能指标.在应用程序通过套接字接口发送或者接收网络包时,这些网络包都要经过协议栈的逐层处理.我们通常用带宽.吞吐.延迟.PPS 等来衡量网

一.上节回顾 上一节,我们学习了 DNS 性能问题的分析和优化方法.简单回顾一下,DNS 可以提供域名和 IP 地址的映射关系,也是一种常用的全局负载均衡(GSLB)实现方法. 通常,需要暴露到公网的服务,都会绑定一个域名,既方便了人们记忆,也避免了后台服务 IP 地址的变更影响到用户. 不过要注意,DNS 解析受到各种网络状况的影响,性能可能不稳定.比如公网延迟增大,缓存过期导致要重新去上游服务器请求,或者流量高峰时 DNS 服务器性能不足等,都会导致 DNS 响应的延迟增大. 此时,可以借助

一.上节回顾 上一节,我带你学习了 tcpdump 和 Wireshark 的使用方法,并通过几个案例,带你用这两个工具实际分析了网络的收发过程.碰到网络性能问题,不要忘记可以用 tcpdump 和Wireshark 这两个大杀器,抓取实际传输的网络包,排查潜在的性能问题. 今天,我们一起来看另外一个问题,怎么缓解 DDoS(Distributed Denial of Service)带来的性能下降问题. 二.DDoS 简介 1.DDoS 简介 DDoS 的前身是 DoS(Denail of S

一.上节回顾 上一节,我们学习了碰到分布式拒绝服务(DDoS)的缓解方法.简单回顾一下,DDoS利用大量的伪造请求,导致目标服务要耗费大量资源,来处理这些无效请求,进而无法正常响应正常用户的请求. 由于 DDoS 的分布式.大流量.难追踪等特点,目前确实还没有方法,能够完全防御DDoS 带来的问题,我们只能设法缓解 DDoS 带来的影响. 比如,你可以购买专业的流量清洗设备和网络防火墙,在网络入口处阻断恶意流量,只保留正常流量进入数据中心的服务器. 在 Linux 服务器中,你可以通过内核调优.