一.free数据的来源 1.碰到看不明白的指标时该怎么办吗? 不懂就去查手册.用 man 命令查询 free 的文档.就可以找到对应指标的详细说明.比如,我们执行 man fre... 2.free数据的来源 [root@ccb-installment-api ~]# man free NAME free - Display amount of free and used memory in the system SYNOPSIS free [options] DESCRIPTION free…

一.案例环境描述 1.环境准备 2CPU,4GB内存 预先安装docker sysstat工具 2.温馨提示 案例中 Python 应用的核心逻辑比较简单,你可能一眼就能看出问题,但实际生产环境中的源码就复杂多了.所以,我依旧建议,操作之前别看源码,避免先入为主,要把它当成一个黑盒来分析.这样 你可以更好把握住,怎么从系统的资源使用问题出发,分析出瓶颈所在的应用,以及瓶颈在应用中大概的位置 3.应用环境 1.运行目标应用 docker run -v /tmp:/tmp --name=app -i…

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

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

一.磁盘 1.机械磁盘 2.固态磁盘 3.相同磁盘随机I/O比连续I/O慢很多 4.最小单位 5.接口 6.RAID陈列卡 7.网路存储 二.通用块层 1.概念 2.第一功能 3.第二功能 4.I/O调度算法 三.I/O栈 1.Linux存储系统I/O栈全景图 2.全景图详解 1.文件系统层 2.通用块层 3.设备层 4.存储系统的I/O 5.优化…

一.案例环境描述 1.环境准备 2CPU,4GB内存 预先安装docker sysstat工具 apt install docker.io sysstat nake git 案例总共由三个容器组成: 1.包括一个 MySQL 数据库应用.2.一个商品搜索应用3.一个数据处理的应用. 其中,商品搜索应用以 HTTP 的形式提供了一个接口: /:返回 Index Page:/db/insert/products/:插入指定数量的商品信息/products/:查询指定商品的信息,并返回处理时间. 2.…

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

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

一.上节回顾 上一节,我们梳理了,应用程序容器化后性能下降的分析方法.一起先简单回顾下.容器利用 Linux 内核提供的命名空间技术,将不同应用程序的运行隔离起来,并用统一的镜像,来管理应用程序的依赖环境.这为应用程序的管理和维护,带来了极大的便捷性,并进一步催生了微服务.云原生等新一代技术架构. 不过,虽说有很多优势,但容器化也会对应用程序的性能带来一定影响.比如,上一节我们一起分析的 Java 应用,就容易发生启动过慢.运行一段时间后 OOM 退出等问题.当你碰到这种问题时,不要慌,我们前面…

一.内存映射 内存管理也是操作系统最核心的功能之一,内存主要用来存储系统和应用程序的指令.数据.缓存等 1.我们通说的内存指的是物理内存还是虚拟内存? 我们通常说的内存容量,其实这指的是物理内存,物理内存也称为主存,大多数计算机用的主存都是动态随机访问内存(DRAM).只有内核才可以直接访问物理内存. 那么,进程要访问内存时,该怎么办呢? 2.进程是如何访问内存的? Linux 内核给每个进程都提供了一个独立的虚拟地址空间,并且这个地址空间是连续的.这样,进程就可以很方便地访问内存,更确切地说是…

一.坏境准备 1.拓扑图 2.安装包 在第9节的基础上 在VM2上安装hping3依奈包 wget http://www.tcpdump.org/release/libpcap-1.9.0.tar.gz tar xf libpcap-1.9.0.tar.gz cd libpcap-1.9.0/ ./configure && make && make install [root@luoahong pcap]# pwd /root/libpcap-1.9.0/pcap [roo…

问题1:性能工具版本太低,导致指标不全 解决方案1: 这是使用 CentOS 的同学普遍碰到的问题.在文章中,我的pidstat 输出里有一个 %wait 指标,代表进程等待 CPU 的时间百分比, 这是 systat 11.5.5 版本才引入的新指标,旧版本没有这一项.而 CentOS 软件库里的 sysstat 版本刚好比这个低,所以没有这项指标. 解决方案2 查看proc文件系统,获取自己想要的指标 问题 2:使用 stress 命令,无法模拟 iowait高的场景 1.分析过程: 使用…

一.索引节点和目录 1.索引节点 2.目录项 3.关系 为了帮助你理解目录项.索引节点以及文件数据的关系,我画了一张示意图,你可以对照这张图,来回忆刚刚讲过的内容,把只知识和细节串联起来 4.Slabs 5.系统格式化 二.虚拟文件系统 1.Linux文件系统的架构图 这里.我画了一张Linux文件系统的架构图,帮你更好地理解系统调用.VFS.缓存.文件系统以及块存储之间的关系图 2.基于磁盘的文件系统 2.基于内存的文件系统 3.网络文件系统 三.文件系统I/O 1.cat过程解析 2.标准库…

一.磁盘性能指标 1.使用率 2.饱和度 3.IOPS 4.吞吐量 5.响应时间 6.性能测试工具 二.磁盘I/O观测 1.每块磁盘的使用率(指标实际上来自/proc/diskstats) [root@luoahong ~]# iostat -d -x 1 Linux 5.1.0-1.el7.elrepo.x86_64 (luoahong) 05/18/2019 _x86_64_ (2 CPU) Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s…

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

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

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

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

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

一.上节回顾 上一节,我带你学习了,如何使用 USE 法来监控系统的性能,先简单回顾一下. 系统监控的核心是资源的使用情况,这既包括 CPU.内存.磁盘.文件系统.网络等硬件资源,也包括文件描述符数.连接数.连接跟踪数等软件资源.而要描述这些资源瓶颈,最简单有效的方法就是 USE 法. USE 法把系统资源的性能指标,简化为了三个类别:使用率.饱和度以及错误数. 当这三者之中任一类别的指标过高时,都代表相对应的系统资源可能存在性能瓶颈. 基于 USE 法建立性能指标后,我们还需要通过一套完整的监…

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

一.上节总结 专栏更新至今,四大基础模块的第三个模块——文件系统和磁盘 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…

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

一.上节回顾 上一节,我以 ksoftirqd CPU 使用率高的问题为例,带你一起学习了内核线程 CPU 使用率高时的分析方法.先简单回顾一下. 当碰到内核线程的资源使用异常时,很多常用的进程级性能工具,并不能直接用到内核线程上.这时,我们就可以使用内核自带的 perf 来观察它们的行为,找出热点函数,进一步定位性能瓶颈.不过,perf 产生的汇总报告并不直观,所以我通常也推荐用火焰图来协助排查. 其实,使用 perf 对系统内核线程进行分析时,内核线程依然还在正常运行中,所以这种方法也被称为…

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

一.上节回顾 在前面的内容中,我为你介绍了很多性能分析的原理.思路以及相关的工具.不过,在实际的性能分析中,一个很常见的现象是,明明发生了性能瓶颈,但当你登录到服务器中想要排查的时候,却发现瓶颈已经消失了.或者说,性能问题总是时不时地发生,但却很难找出发生规律,也很难重现. 当面对这样的场景时,你可能会发现,我们前面介绍的各种工具.方法都“失效“了.为什么呢?因为它们都需要在性能问题发生的时刻才有效,而在这些事后分析的场景中,我们就很难发挥它们的威力了. 那该怎么办呢?置之不理吗?其实以往,很多…

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