Linux性能优化知识点总结大全 · 实践+珍藏版
Part1Linux性能优化
1性能优化
性能指标
高并发和响应快对应着性能优化的两个焦点指标：吞吐和延时
图片来自: www.ctq6.cn
应用负载角度：直接影响了产品终端的用户体验
系统资源角度：资源使用率、饱和度等
性能问题的实质就是系统资源已经抵达瓶颈 ，但请求的处理还不敷快 ，无法支持更多的请求。性能剖析现实上就是找出应用或系统的瓶颈 ，想法去阻止或缓解它们。
选择指标评估应用程序和系统性能
为应用程序和系统设置性能目的
举行性能基准测试
性能剖析定位瓶颈
性能监控和告警
关于差别的性能问题要选取差别的性能剖析工具。下面是常用的Linux Performance Tools以及对应剖析的性能问题类型。
图片来自: www.ctq6.cn
究竟应该怎么明确”平均负载”
平均负载：单位时间内 ，系统处于可运行状态和不可中止状态的平均历程数 ，也就是平均活跃历程数。它和我们古板意义上明确的CPU使用率并没有直接关系。
其中不可中止历程是正处于内核态要害流程中的历程（如常见的期待装备的I/O响应）。不可中止状态现实上是系统对历程和硬件装备的一种� ；せ�。
平均负载几多时合理
现实生产情形中将系统的平均负载监控起来 ，凭证历史数据判断负载的转变趋势。当负载保存显着升高趋势时 ，实时举行剖析和视察。虽然也可以当设置阈值（如当平均负载高于CPU数目的70%时）
现实事情中我们会经� ；煜骄涸睾虲PU使用率的看法 ，着实两者并不完全对等：
CPU麋集型历程 ，大宗CPU使用会导致平均负载升高 ，此时两者一致
I/O麋集型历程 ，期待I/O也会导致平均负载升高 ，此时CPU使用率并纷歧定高
大宗期待CPU的历程调理会导致平均负载升高 ，此时CPU使用率也会较量高
平均负载高时可能是CPU麋集型历程导致 ，也可能是I/O忙碌导致。详细剖析时可以团结mpstat/pidstat工具辅助剖析负载泉源
2CPU
CPU上下文切换(上)
CPU上下文切换 ，就是把前一个使命的CPU上下文（CPU寄存器和PC）生涯起来 ，然后加载新使命的上下文到这些寄存器和程序计数器 ，最后再跳转到程序计数器所指的位置 ，运行新使命。其中 ，生涯下来的上下文会存储在系统内核中 ，待使命重新调理执行时再加载 ，包管原来的使命状态不受影响。关注Linux中文社区
凭证使命类型 ，CPU上下文切换分为：
历程上下文切换
线程上下文切换
中止上下文切换
历程上下文切换
Linux历程凭证品级权限将历程的运行空间分为内核空间和用户空间。从用户态向内核态转变时需要通过系统挪用来完成。
一次系统挪用历程着实举行了两次CPU上下文切换：
CPU寄存器中用户态的指令位置先生涯起来 ，CPU寄存器更新为内核态指令的位置 ，跳转到内核态运行内核使命 ；
系统挪用竣事后 ，CPU寄存器恢回复来生涯的用户态数据 ，再切换到用户空间继续运行。
系统挪用历程中并不会涉及虚拟内存等历程用户态资源 ，也不会切换历程。和古板意义上的历程上下文切换差别。因此系统挪用通常称为特权模式切换。
历程是由内核治理和调理的 ，历程上下文切换只能爆发在内核态。因此相比系统挪用来说 ，在生涯目今历程的内核状态和CPU寄存器之前 ，需要先把该历程的虚拟内存 ，栈生涯下来。再加载新历程的内核态后 ，还要刷新历程的虚拟内存和用户栈。
历程只有在调理到CPU上运行时才需要切换上下文 ，有以下几种场景：CPU时间片轮流分派 ，系统资源缺乏导致历程挂起 ，历程通过sleep函数自动挂起 ，高优先级历程抢占时间片 ，硬件中止时CPU上的历程被挂起转而执行内核中的中止效劳。
线程上下文切换
线程上下文切换分为两种：
前后线程同属于一个历程 ，切换时虚拟内存资源稳固 ，只需要切换线程的私有数据 ，寄存器等 ；
前后线程属于差别历程 ，与历程上下文切换相同。
同历程的线程切换消耗资源较少 ，这也是多线程的优势。
中止上下文切换
中止上下文切换并不涉及到历程的用户态 ，因其中止上下文只包括内核态中止效劳程序执行所必需的状态（CPU寄存器 ，内核客栈 ，硬件中止参数等）。
中止处理优先级比历程高 ，以是中止上下文切换和历程上下文切换不会同时爆发
CPU上下文切换(下)
通过vmstat可以审查系统总体的上下文切换情形
vmstat 5 #每隔5s输出一组数据 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 103388 145412 511056 0 0 18 60 1 1 2 1 96 0 0 0 0 0 103388 145412 511076 0 0 0 2 450 1176 1 1 99 0 0 0 0 0 103388 145412 511076 0 0 0 8 429 1135 1 1 98 0 0 0 0 0 103388 145412 511076 0 0 0 0 431 1132 1 1 98 0 0 0 0 0 103388 145412 511076 0 0 0 10 467 1195 1 1 98 0 0 1 0 0 103388 145412 511076 0 0 0 2 426 1139 1 0 99 0 0 4 0 0 95184 145412 511108 0 0 0 74 500 1228 4 1 94 0 0 0 0 0 103512 145416 511076 0 0 0 455 723 1573 12 3 83 2 0
登录后复制
cs （context switch） 每秒上下文切换次数
in （interrupt） 每秒中止次数
r （runnning or runnable）停当行列的长度 ，正在运行和期待CPU的历程数
b （Blocked） 处于不可中止睡眠状态的历程数
要审查每个历程的详细情形 ，需要使用pidstat来审查每个历程上下文切换情形
pidstat -w 5 14时51分16秒 UID PID cswch/s nvcswch/s Command 14时51分21秒 0 1 0.80 0.00 systemd 14时51分21秒 0 6 1.40 0.00 ksoftirqd/0 14时51分21秒 0 9 32.67 0.00 rcu_sched 14时51分21秒 0 11 0.40 0.00 watchdog/0 14时51分21秒 0 32 0.20 0.00 khugepaged 14时51分21秒 0 271 0.20 0.00 jbd2/vda1-8 14时51分21秒 0 1332 0.20 0.00 argusagent 14时51分21秒 0 5265 10.02 0.00 AliSecGuard 14时51分21秒 0 7439 7.82 0.00 kworker/0:2 14时51分21秒 0 7906 0.20 0.00 pidstat 14时51分21秒 0 8346 0.20 0.00 sshd 14时51分21秒 0 20654 9.82 0.00 AliYunDun 14时51分21秒 0 25766 0.20 0.00 kworker/u2:1 14时51分21秒 0 28603 1.00 0.00 python3
登录后复制
cswch 每秒自愿上下文切换次数 （历程无法获取所需资源导致的上下文切换）
nvcswch 每秒非自愿上下文切换次数 （时间片轮流等系统强制调理）
vmstat 1 1 #首先获取空闲系统的上下文切换次数 sysbench --threads=10 --max-time=300 threads run #模拟多线程切换问题 vmstat 1 1 #新终端视察上下文切换情形 此时发明cs数据显着升高 ，同时视察其他指标： r列： 远超系统CPU个数 ，说明保存大宗CPU竞争 us和sy列：sy列占比80% ，说明CPU主要被内核占用 in列： 中止次数显着上升 ，说明中止处理也是潜在问题
登录后复制
说明运行/期待CPU的历程过多 ，导致大宗的上下文切换 ，上下文切换导致系统的CPU占用率高
pidstat -w -u 1 #审查究竟哪个历程导致的问题
登录后复制
从效果中看出是sysbench导致CPU使用率过高 ，可是pidstat输出的上下文次数加起来也并未几。剖析sysbench模拟的是线程的切换 ，因此需要在pidstat后加-t参数审查线程指标。
另外关于中止次数过多 ，我们可以通过/proc/interrupts文件读取
watch -d cat /proc/interrupts
登录后复制
发明次数转变速率最快的是重调理中止（RES） ，该中止用来叫醒空闲状态的CPU来调理新的使命运行。剖析照旧由于过多使命的调理问题 ，和上下文切换剖析一致。
某个应用的CPU使用率抵达100% ，怎么办？
Linux作为多使命操作系统 ，将CPU时间划分为很短的时间片 ，通过调理器轮流分派给各个使命使用。为了维护CPU时间 ，Linux通过事先界说的节奏率 ，触发时间中止 ，并使用全局变了jiffies纪录开机以来的节奏数。时间中止爆发一次该值+1.
CPU使用率 ，除了空闲时间以外的其他时间占总CPU时间的百分比�？梢酝ü�/proc/stat中的数据来盘算出CPU使用率。由于/proc/stat时开机以来的节奏数累加值 ，盘算出来的是开机以来的平均CPU使用率 ，一样平常意义不大�？梢跃嗬肴∫欢问奔涞牧酱沃底鞑罾磁趟愀枚问奔淠诘钠骄鵆PU使用率。性能剖析工具给出的都是距离一段时间的平均CPU使用率 ，要注重距离时间的设置。
CPU使用率可以通过top 或 ps来审查。剖析历程的CPU问题可以通过perf ，它以性能事务采样为基础 ，不但可以剖析系统的种种事务和内核性能 ，还可以用来剖析指定应用程序的性能问题。
perf top / perf record / perf report （-g 开启挪用关系的采样）
sudo docker run --name nginx -p 10000:80 -itd feisky/nginx sudo docker run --name phpfpm -itd --network container:nginx feisky/php-fpm ab -c 10 -n 100 http://XXX.XXX.XXX.XXX:10000/ #测试Nginx效劳性能
登录后复制
发明此时每秒可遭受请求给长少 ，此时将测试的请求数从100增添到10000。在另外一个终端运行top审查每个CPU的使用率。发明系统中几个php-fpm历程导致CPU使用率骤升。
接着用perf来剖析详细是php-fpm中哪个函数导致该问题。
perf top -g -p XXXX #对某一个php-fpm历程举行剖析
登录后复制
发明其中sqrt和add_function占用CPU过多 ， 此时审查源码找到原来是sqrt中在宣布前没有删除测试代码段 ，保存一个百万次的循环导致。将该无用代码删除后发明nginx负载能力显着提升
系统的CPU使用率很高 ，为什么找不到高CPU的应用？
sudo docker run --name nginx -p 10000:80 -itd feisky/nginx:sp sudo docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:sp ab -c 100 -n 1000 http://XXX.XXX.XXX.XXX:10000/ #并发100个请求测试
登录后复制
实验效果中每秒请求数依旧不高 ，我们将并发请求数降为5后 ，nginx负载能力依旧很低。
此时用top和pidstat发明系统CPU使用率过高 ，可是并没有发明CPU使用率高的历程。
泛起这种情形一样平常时我们剖析时遗漏的什么信息 ，重新运行top下令并视察一会。发明停当行列中处于Running状态的举行过多 ，凌驾了我们的并发请求次数5. 再仔细审查历程运行数据 ，发明nginx和php-fpm都处于sleep状态 ，真正处于运行的却是几个stress历程。
下一步就使用pidstat剖析这几个stress历程 ，发明没有任何输出。用ps aux交织验证发明依旧不保存该历程。说明不是工具的问题。再top审查发明stress历程的历程号转变了 ，此时有可能时以下两种缘故原由导致：
历程一直的瓦解重启（如段过失/设置过失等） ，此时历程退出后可能又被监控系统重启 ；
短时历程导致 ，即其他应用内部通过exec挪用的外面下令 ，这些下令一样平常只运行很短时间就竣事 ，很难用top这种距离较长的工具来发明
可以通过pstree来查找 stress的父历程 ，找出挪用关系。
pstree | grep stress
登录后复制
发明是php-fpm挪用的该子历程 ，此时去审查源码可以看出每个请求都会挪用一个stress下令来模拟I/O压力。之前top显示的效果是CPU使用率升高 ，是否真的是由该stress下令导致的 ，还需要继续剖析。代码中给每个请求加了verbose=1的参数后可以审查stress下令的输出 ，在中止测试该下令效果显示stress下令运行时保存因权限问题导致的文件建设失败的bug。
此时依旧只是推测 ，下一步继续通过perf工具来剖析。性能报告显示确实时stress占用了大宗的CPU ，通过修复权限问题来优化解决即可.
系统中泛起大宗不可中止历程和僵尸历程怎么办？
历程状态
R Running/Runnable ，体现历程在CPU的停当行列中 ，正在运行或者期待运行 ；
D Disk Sleep ，不可中止状态睡眠 ，一样平常体现历程正在跟硬件交互 ，并且交互历程中不允许被其他历程中止 ；
Z Zombie ，僵尸历程 ，体现历程现实上已经竣事 ，可是父历程还没有接纳它的资源 ；
S Interruptible Sleep ，可中止睡眠状态 ，体现历程由于期待某个事务而被系统挂起 ，当期待事务爆发则会被叫醒并进入R状态 ；
I Idle ，空闲状态 ，用在不可中止睡眠的内核线程上。该状态不会导致平均负载升高 ；
T Stop/Traced ，体现历程处于暂� ；蚋僮刺⊿IGSTOP/SIGCONT ， GDB调试） ；
X Dead ，历程已经消亡 ，不会在top/ps中看到。
关于不可中止状态 ，一样平常都是在很短时间内竣事 ，可忽略。可是若是系统或硬件爆发故障 ，历程可能会坚持不可中止状态良久 ，甚至系统中泛起大宗不可中止状态 ，此时需注重是否泛起了I/O性能问题。
僵尸历程一样平常多历程应用容易遇到 ，父历程来缺乏处理子历程状态时子历程就提前退出 ，此时子历程就酿成了僵尸历程。大宗的僵尸历程会用尽PID历程号 ，导致新历程无法建设。
磁盘O_DIRECT问题
sudo docker run --privileged --name=app -itd feisky/app:iowait ps aux | grep '/app'
登录后复制
可以看到此时有多个app历程运行 ，状态划分时Ss+和D+。其中后面s体现历程是一个会话的向导历程 ，+号体现前台历程组。
其中历程组体现一组相互关联的历程 ，子历程是父历程所在组的组员。会话指共享统一个控制终端的一个或多个历程组。
用top审查系统资源发明：1）平均负载在逐渐增添 ，且1分钟内平均负载抵达了CPU个数 ，说明系统可能已经有了性能瓶颈 ；2）僵尸历程较量多且在一直增添 ；3）us和sys CPU使用率都不高 ，iowait却较量高 ；4）每个历程CPU使用率也不高 ，但有两个历程处于D状态 ，可能在期待IO。
剖析现在数据可知：iowait过高导致系统平均负载升高 ，僵尸历程一直增添说明有程序没能准确整理子历程资源。
用dstat来剖析 ，由于它可以同时审查CPU和I/O两种资源的使用情形 ，便于比照剖析。
dstat 1 10 #距离1秒输出10组数据
登录后复制
可以看到当wai（iowait）升高时磁盘请求read都会很大 ，说明iowait的升高和磁盘的读请求有关。接下来剖析究竟时哪个历程在读磁盘。
之前top审查的处于D状态的历程号 ，用pidstat -d -p XXX 展示历程的I/O统计数据。发明处于D状态的历程都没有任何读写操作。在用pidstat -d 审查所有历程的I/O统计数据 ，看到app历程在举行磁盘读操作 ，每秒读取32MB的数据。历程会见磁盘必需使用系统挪用处于内核态 ，接下来重点就是找到app历程的系统挪用。
sudo strace -p XXX #对app历程挪用举行跟踪
登录后复制
报错没有权限 ，由于已经时root权限了。以是遇到这种情形 ，首先要检查历程状态是否正常。ps下令查找该历程已经处于Z状态 ，即僵尸历程。
这种情形下top pidstat之类的工具无法给出更多的信息 ，此时像第5篇一样 ，用perf record -d和perf report举行剖析 ，审查app历程挪用栈。
看到app确着实通过系统挪用sys_read()读取数据 ，并且从new_sync_read和blkdev_direct_IO看出历程时举行直接读操作 ，请求直接从磁盘读 ，没有通过缓存导致iowait升高。
通过层层剖析后 ，root cause是app内部举行了磁盘的直接I/O。然后定位到详细代码位置举行优化即可。
僵尸历程
上述优化后iowait显著下降 ，可是僵尸历程数目仍然在增添。首先要定位僵尸历程的父历程 ，通过pstree -aps XXX ，打印出该僵尸历程的挪用树 ，发明父历程就是app历程。
审查app代码 ，看看子历程竣事的处理是否准确（是否挪用wait()/waitpid(),有没有注册SIGCHILD信号的处理函数等）。
遇到iowait升高时 ，先用dstat pidstat等工具确认是否保存磁盘I/O问题 ，再找是哪些历程导致I/O ，不可用strace直接剖析历程挪用时可以通过perf工具剖析。
关于僵尸问题 ，用pstree找到父历程 ，然后看源码检查子历程竣事的处理逻辑即可。
CPU性能指标
CPU使用率
用户CPU使用率, 包括用户态(user)和低优先级用户态(nice). 该指标过高说明应用程序较量忙碌.
系统CPU使用率, CPU在内核态运行的时间百分比(不含中止). 该指标高说明内核较量忙碌.
期待I/O的CPU使用率, iowait, 该指标高说明系统与硬件装备I/O交互时间较量长.
软/硬中止CPU使用率, 该指标高说明系统中爆发大宗中止.
steal CPU / guest CPU, 体现虚拟机占用的CPU百分比.
平均负载
理想情形下平均负载即是逻辑CPU个数,体现每个CPU都被充分使用. 若大于则说明系统负载较重.
历程上下文切换
包括无法获取资源的自愿切换和系统强制调理时的非自愿切换. 上下文切换自己是包管Linux正常运行的一项焦点功效. 过多的切换则会将原本运行历程的CPU时间消耗在寄存器,内核占及虚拟内存等数据生涯和恢复上
CPU缓存掷中率
CPU缓存的复用情形,掷中率越高性能越好. 其中L1/L2常用在单核,L3则用在多核中
性能工具
平均负载案例
先用uptime审查系统平均负载
判断负载在升高后再用mpstat和pidstat划分审查每个CPU和每个历程CPU使用情形.找出导致平均负载较高的历程.另外 ，搜索民众号Linux就该这样学后台回复“git书籍” ，获取一份惊喜礼包。
上下文切换案例
先用vmstat审查系统上下文切换和中止次数
再用pidstat视察历程的自愿和非自愿上下文切换情形
最后通过pidstat视察线程的上下文切换情形
历程CPU使用率高案例
先用top审查系统和历程的CPU使用情形,定位到历程
再用perf top视察历程挪用链,定位到详细函数
系统CPU使用率高案例
先用top审查系统和历程的CPU使用情形,top/pidstat都无法找到CPU使用率高的历程
重新审阅top输出
从CPU使用率不高,可是处于Running状态的历程入手
perf record/report发明短时历程导致 (execsnoop工具)
不可中止和僵尸历程案例
先用top视察iowait升高,发明大宗不可中止和僵尸历程
strace无法跟踪历程系统挪用
perf剖析挪用链发明泉源来自磁盘直接I/O
软中止案例
top视察系统软中止CPU使用率高
审查/proc/softirqs找到转变速率较快的几种软中止
sar下令发明是网络小包问题
tcpdump找出网络帧的类型和泉源, 确定SYN FLOOD攻击导致
凭证差别的性能指标来找合适的工具:
图片来自: www.ctq6.cn
在生产情形中往往开发者没有权限装置新的工具包,只能最大化使用好系统中已经装置好的工具. 因此要相识一些主流工具能够提供哪些指标剖析.
图片来自: www.ctq6.cn
先运行几个支持指标较多的工具, 如top/vmstat/pidstat,凭证它们的输出可以得出是哪种类型的性能问题. 定位到历程后再用strace/perf剖析挪用情形进一步剖析. 若是是软中止导致用/proc/softirqs
图片来自: www.ctq6.cn
CPU优化
应用程序优化
编译器优化: 编译阶段开启优化选项, 如gcc -O2
算法优化
异步处理: 阻止程序由于期待某个资源而一直壅闭,提升程序的并发处理能力. (将轮询替换为事务通知)
多线程取代多历程: 镌汰上下文切换本钱
善用缓存: 加速程序处理速率
系统优化
CPU绑定: 将历程绑定要1个/多个CPU上,提高CPU缓存掷中率,镌汰CPU调理带来的上下文切换
CPU独吞: CPU亲和性机制来分派历程
优先级调解:使用nice适当降低非焦点应用的优先级
为历程设置资源显示: cgroups设置使用上限,避免由某个应用自身问题耗尽系统资源
NUMA优化: CPU尽可能会见外地内存
中止负载平衡: irpbalance,将中止处理历程自动负载平衡到各个CPU上
TPS、QPS、系统吞吐量的区别和明确
QPS(TPS)
并发数
响应时间
QPS(TPS)=并发数/平均响应时间
用户请求效劳器
效劳器内部处理
效劳器返回给客户
QPS类似TPS,可是关于一个页面的会见形成一个TPS,可是一次页面请求可能包括多次对效劳器的请求,可能计入多次QPS
QPS (Queries Per Second)每秒盘问率,一台效劳器每秒能够响应的盘问次数.
TPS (Transactions Per Second)每秒事务数,软件测试的效果.
系统吞吐量, 包括几个主要参数:
3内存
Linux内存是怎么事情的
内存映射
大大都盘算机用的主存都是动态随时机见内存(DRAM) ，只有内核才可以直接会见物理内存。Linux内核给每个历程提供了一个自力的虚拟地点空间 ，并且这个地点空间是一连的。这样历程就可以很利便的会见内存(虚拟内存)。
虚拟地点空间的内部分为内核空间和用户空间两部分 ，差别字长的处理器地点空间的规模差别。32位系统内核空间占用1G ，用户空间占3G。64位系统内核空间和用户空间都是128T ，划分占内存空间的最高和最低处 ，中心部分为未界说。
并不是所有的虚拟内存都会分派物理内存 ，只有现实使用的才会。分派后的物理内存通过内存映射治理。为了完成内存映射 ，内核为每个历程都维护了一个页表 ，纪录虚拟地点和物理地点的映射关系。页显露实存储在CPU的内存治理单位MMU中 ，处理器可以直接通过硬件找出要会见的内存。
当历程会见的虚拟地点在页表中查不到时 ，系统会爆发一个缺页异常 ，进入内核空间分派物理内存 ，更新历程页表 ，再返回用户空间恢复历程的运行。
MMU以页为单位治理内存 ，页巨细4KB。为相识决页表项过多问题Linux提供了多级页表和HugePage的机制。
虚拟内存空间漫衍
用户空间内存从低到高是五种差别的内存段：
只读段 代码和常量等
数据段 全局变量等
堆 动态分派的内存 ，从低地点最先向上增添
文件映射 动态库、共享内存等 ，从高地点最先向下增添
栈 包括局部变量和函数挪用的上下文等 ，栈的巨细是牢靠的。一样平常8MB
内存分派与接纳
分派
malloc对应到系统挪用上有两种实现方法：
brk() 针对小块内存(<128K) ，通过移动堆顶位置来分派。内存释放后不连忙送还内存 ，而是被缓存起来。
**mmap()**针对大块内存(>128K) ，直接用内存映射来分派 ，即在文件映射段找一块空闲内存分派。
前者的缓存可以镌汰缺页异常的爆发 ，提高内存会收效率。可是由于内存没有送还系统 ，在内存事情忙碌时 ，频仍的内存分派/释放会造成内存碎片。
后者在释放时直接送还系统 ，以是每次mmap都会爆发缺页异常。在内存事情忙碌时 ，频仍内存分派会导致大宗缺页异常 ，使内核治理肩负增添。
上述两种挪用并没有真正分派内存 ，这些内存只有在首次会见时 ，才通过缺页异常进入内核中 ，由内核来分派
接纳
内存主要时 ，系统通过以下方法来接纳内存：
接纳缓存：LRU算法接纳最近最少使用的内存页面 ；
接纳不常会见内存：把不常用的内存通过交流分区写入磁盘
杀死历程：OOM内核� ；せ� （历程消耗内存越大oom_score越大 ，占用CPU越多oom_score越小 ，可以通过/proc手动调解oom_adj）
echo -16 > /proc/$(pidof XXX)/oom_adj
登录后复制
怎样审查内存使用情形
free来审查整个系统的内存使用情形
top/ps来审查某个历程的内存使用情形
VIRT 历程的虚拟内存巨细
RES 常驻内存的巨细 ，即历程现实使用的物理内存巨细 ，不包括swap和共享内存
SHR 共享内存巨细 ，与其他历程共享的内存 ，加载的动态链接库以及程序代码段
%MEM 历程使用物理内存占系统总内存的百分比
怎样明确内存中的Buffer和Cache？
buffer是对磁盘数据的缓存 ，cache是对文件数据的缓存 ，它们既会用在读请求也会用在写请求中
怎样使用系统缓存优化程序的运行效率
缓存掷中率
缓存掷中率是指直接通过缓存获取数据的请求次数 ，占所有请求次数的百分比。掷中率越高说明缓存带来的收益越高 ，应用程序的性能也就越好。
装置bcc包后可以通过cachestat和cachetop来监测缓存的读写掷中情形。
装置pcstat后可以审查文件在内存中的缓存巨细以及缓存比例
#首先装置Go export GOPATH=~/go export PATH=~/go/bin:$PATH go get golang.org/x/sys/unix go ge github.com/tobert/pcstat/pcstat
登录后复制
dd缓存加速
dd if=/dev/sda1 of=file bs=1M count=512 #生产一个512MB的暂时文件 echo 3 > /proc/sys/vm/drop_caches #整理缓存 pcstat file #确定适才天生文件不在系统缓存中 ，此时cached和percent都是0 cachetop 5 dd if=file of=/dev/null bs=1M #测试文件读取速率 #此时文件读取性能为30+MB/s ，审查cachetop效果发明并不是所有的读都落在磁盘上 ，读缓存掷中率只有50%。 dd if=file of=/dev/null bs=1M #重复上述读文件测试 #此时文件读取性能为4+GB/s ，读缓存掷中率为100% pcstat file #审查文件file的缓存情形 ，100%所有缓存
登录后复制
O_DIRECT选项绕过系统缓存
cachetop 5 sudo docker run --privileged --name=app -itd feisky/app:io-direct sudo docker logs app #确认案例启动乐成 #实验效果批注每读32MB数据都要花0.9s ，且cachetop输出中显示1024次缓存所有掷中
登录后复制
可是凭感受可知若是缓存掷中读速率不应云云慢 ，读次数时1024 ，页巨细为4K ，五秒的时间内读取了1024*4KB数据 ，即每秒0.8MB ，和效果中32MB相差较大。说明该案例没有充分使用缓存 ，嫌疑系统挪用设置了直接I/O标记绕过系统缓存。因此接下来视察系统挪用.
strace -p $(pgrep app) #strace 效果可以看到openat翻开磁盘分区/dev/sdb1 ，传入参数为O_RDONLY|O_DIRECT
登录后复制
这就诠释了为什么读32MB数据那么慢 ，直接从磁盘读写一定远远慢于缓存。找出问题后我们再看案例的源代码发明flags中指定了直接IO标记。删除该选项后重跑 ，验证性能转变。
内存走漏 ，怎样定位和处理？
对应用程序来说 ，动态内存的分派和接纳是焦点又重大的一个逻辑功效�？�。治理内存的历程中会爆发种种各样的“事故”：
没准确接纳分派的内存 ，导致了走漏
会见的是已分派内存界线外的地点 ，导致程序异常退出
内存的分派与接纳
虚拟内存漫衍从低到高划分是只读段 ，数据段 ，堆 ，内存映射段 ，栈五部分。其中会导致内存走漏的是：
堆：由应用程序自己来分派和治理 ，除非程序退出这些堆内存不会被系统自动释放。
内存映射段：包括动态链接库和共享内存 ，其中 共享内存由程序自动分派和治理
内存走漏的危害较量大 ，这些遗忘释放的内存 ，不但应用程序自己不可会见 ，系统也不可把它们再次分派给其他应用。 内存走漏一直累积甚至会耗尽系统内存.
怎样检测内存走漏
预先装置systat ，docker ，bcc
sudo docker run --name=app -itd feisky/app:mem-leak sudo docker logs app vmstat 3
登录后复制
可以看到free在一直下降 ，buffer和cache基本坚持稳固。说明系统的内存一致在升高。但并不可说明保存内存走漏。此时可以通过memleak工具来跟踪系统或历程的内存分派/释放请求
/usr/share/bcc/tools/memleak -a -p $(pidof app)
登录后复制
从memleak输出可以看到 ，应用在一直地分派内存 ，并且这些分派的地点并没有被接纳。通过挪用栈看到是fibonacci函数分派的内存没有释放。定位到源码后审查源码来修复增添内存释放函数即可.
为什么系统的Swap变高
系统内存资源主要时通过内存接纳和OOM杀死历程来解决。其中可接纳内存包括：
缓存/缓冲区 ，属于可接纳资源 ，在文件治理中通常叫做文件页
在应用程序中通过fsync将脏页同步到磁盘
交给系统 ，内核线程pdflush认真这些脏页的刷新
被应用程序修悔改暂时没写入磁盘的数据(脏页) ，要先写入磁盘然后才华内存释放
内存映射获取的文件映射页 ，也可以被释放掉 ，下次会见时从文件重新读取
关于程序自动分派的堆内存 ，也就是我们在内存治理中的匿名页 ，虽然这些内存不可直接释放 ，可是Linux提供了Swap机制将不常会见的内存写入到磁盘来释放内存 ，再次会见时从磁盘读取到内存即可。
Swap原理
Swap实质就是把一块磁盘空间或者一个外地文件看成内存来使用 ，包括换入和换出两个历程：
换出：将历程暂时不必的内存数据存储到磁盘中 ，并释放这些内存
换入：历程再次会见内存时 ，将它们从磁盘读到内存中
Linux怎样权衡内存资源是否主要？
直接内存接纳 新的大块内存分派请求 ，但剩余内存缺乏。此时系统会接纳一部分内存 ；
kswapd0 内核线程按期接纳内存。为了权衡内存使用情形 ，界说了pages_min,pages_low,pages_high三个阈值 ，并凭证其来举行内存的接纳操作。
剩余内存 < pages_min ，历程可用内存耗尽了 ，只有内核才可以分派内存
pages_min < 剩余内存 < pages_low,内存压力较大 ，kswapd0执行内存接纳 ，直到剩余内存 > pages_high
pages_low < 剩余内存 < pages_high ，内存有一定压力 ，但可以知足新内存请求
剩余内存 > pages_high ，说明剩余内存较多 ，无内存压力
pages_low = pages_min 5 / 4 pages_high = pages_min 3 / 2
NUMA 与 SWAP
许多情形下系统剩余内存较多 ，但SWAP依旧升高 ，这是由于处理器的NUMA架构。
在NUMA架构下多个处理器划分到差别的Node ，每个Node都拥有自己的外地内存空间。在剖析内存的使用时应该针对每个Node单独剖析
numactl --hardware #审查处理器在Node的漫衍情形 ，以及每个Node的内存使用情形
登录后复制
内存三个阈值可以通过/proc/zoneinfo来审查 ，该文件中还包括活跃和非活跃的匿名页/文件页数。
当某个Node内存缺乏时 ，系统可以从其他Node寻找空闲资源 ，也可以从外地内存中接纳内存。通过/proc/sys/vm/zone_raclaim_mode来调解。
0体现既可以从其他Node寻找空闲资源 ，也可以从外地接纳内存
1 ，2 ，4体现只接纳外地内存 ，2体现可以会回脏数据接纳内存 ，4体现可以用Swap方法接纳内存。
swappiness
在现实接纳历程中Linux凭证/proc/sys/vm/swapiness选项来调解使用Swap的起劲水平 ，从0-100 ，数值越大越起劲使用Swap ，即更倾向于接纳匿名页 ；数值越小越消极使用Swap ，即更倾向于接纳文件页。
注重：这只是调解Swap起劲水平的权重 ，纵然设置为0 ，当剩余内存+文件页小于页高阈值时 ，照旧会爆发Swap。
Swap升高时怎样定位剖析
free #首先通过free审查swap使用情形 ，若swap=0体现未设置Swap #先建设并开启swap fallocate -l 8G /mnt/swapfile chmod 600 /mnt/swapfile mkswap /mnt/swapfile swapon /mnt/swapfile free #再次执行free确保Swap设置乐成 dd if=/dev/sda1 of=/dev/null bs=1G count=2048 #模拟大文件读取 sar -r -S 1 #审查内存各个指标转变 -r内存 -S swap #凭证效果可以看出 ，%memused在一直增添 ，剩余内存kbmemfress一直镌汰 ，缓冲区kbbuffers一直增大 ，由此可知剩余内存一直分派给了缓冲区 #一段时间之后 ，剩余内存很小 ，而缓冲区占用了大部分内存。此时Swap使用之间增大 ，缓冲区和剩余内存只在小规模波动 停下sar下令 cachetop5 #视察缓存 #可以看到dd历程读写只有50%的掷中率 ，未掷中数为4w+页 ，说明正式dd历程导致缓冲区使用升高 watch -d grep -A 15 ‘Normal’ /proc/zoneinfo #视察内存指标转变 #发明升级内保存一个小规模一直的波动 ，低于页低阈值时会突然增大到一个大于页高阈值的值
登录后复制
说明剩余内存缓和冲区的波动转变正是由于内存接纳缓和存再次分派的循环往复。有时间Swap用的多 ，有时间缓冲区波动更多。此时审查swappiness值为60 ，是一个相对中和的设置 ，系统会凭证现实运行情形来选去合适的接纳类型.
怎样“快准狠”找到系统内存保存的问题
内存性能指标
系统内存指标
已用内存/剩余内存
共享内存 （tmpfs实现）
可用内存：包括剩余内存和可接纳内存
缓存：磁盘读取文件的页缓存 ，slab分派器中的可接纳部分
缓冲区：原始磁盘块的暂时存储 ，缓存将要写入磁盘的数据
历程内存指标
虚拟内存：5大部分
常驻内存：历程现实使用的物理内存 ，不包括Swap和共享内存
共享内存：与其他历程共享的内存 ，以及动态链接库和程序的代码段
另外 ，搜索民众号手艺社区后台回复“算法” ，获取一份惊喜礼包。
Swap内存：通过Swap换出到磁盘的内存
缺页异常
可以直接从物理内存中分派 ，次缺页异常
需要磁盘IO介入(如Swap) ，主缺页异常。此时内存会见会慢许多
内存性能工具
凭证差别的性能指标来找合适的工具:
图片来自: www.ctq6.cn
内存剖析工具包括的性能指标:
图片来自: www.ctq6.cn
怎样迅速剖析内存的性能瓶颈
通常先运行几个笼罩面较量大的性能工具 ，如free ，top ，vmstat ，pidstat等
先用free和top审查系统整体内存使用情形
再用vmstat和pidstat ，审查一段时间的趋势 ，从而判断内存问题的类型
最后举行详细剖析 ，好比内存分派剖析 ，缓存/缓冲区剖析 ，详细历程的内存使用剖析等
常见的优化思绪：
最好榨取Swap ，若必需开启则只管降低swappiness的值
镌汰内存的动态分派 ，如可以用内存池 ，HugePage等
只管使用缓存缓和冲区来会见数据。如用客栈明确声明内存空间来存储需要缓存的数据 ，或者用Redis外部缓存组件来优化数据的会见
cgroups等方法来限制历程的内存使用情形 ，确保系统内存不被异常历程耗尽
/proc/pid/oom_adj调解焦点应用的oom_score ，包管纵然内存主要焦点应用也不会被OOM杀死
vmstat使用详解
vmstat下令是最常见的Linux/Unix监控工具 ，可以展现给准时间距离的效劳器的状态值,包括效劳器的CPU使用率 ，内存使用 ，虚拟内存交流情形,IO读写情形�？梢钥吹秸龌档腃PU,内存,IO的使用情形 ，而不是单单看到各个历程的CPU使用率和内存使用率(使用场景纷歧样)。
vmstat 2 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 1379064 282244 11537528 0 0 3 104 0 0 3 0 97 0 0 0 0 0 1372716 282244 11537544 0 0 0 24 4893 8947 1 0 98 0 0 0 0 0 1373404 282248 11537544 0 0 0 96 5105 9278 2 0 98 0 0 0 0 0 1374168 282248 11537556 0 0 0 0 5001 9208 1 0 99 0 0 0 0 0 1376948 282248 11537564 0 0 0 80 5176 9388 2 0 98 0 0 0 0 0 1379356 282256 11537580 0 0 0 202 5474 9519 2 0 98 0 0 1 0 0 1368376 282256 11543696 0 0 0 0 5894 8940 12 0 88 0 0 1 0 0 1371936 282256 11539240 0 0 0 10554 6176 9481 14 1 85 1 0 1 0 0 1366184 282260 11542292 0 0 0 7456 6102 9983 7 1 91 0 0 1 0 0 1353040 282260 11556176 0 0 0 16924 7233 9578 18 1 80 1 0 0 0 0 1359432 282260 11549124 0 0 0 12576 5495 9271 7 0 92 1 0 0 0 0 1361744 282264 11549132 0 0 0 58 8606 15079 4 2 95 0 0 1 0 0 1367120 282264 11549140 0 0 0 2 5716 9205 8 0 92 0 0 0 0 0 1346580 282264 11562644 0 0 0 70 6416 9944 12 0 88 0 0 0 0 0 1359164 282264 11550108 0 0 0 2922 4941 8969 3 0 97 0 0 1 0 0 1353992 282264 11557044 0 0 0 0 6023 8917 15 0 84 0 0 # 效果说明 - r 体现运行行列(就是说几多个历程真的分派到CPU) ，我测试的效劳器现在CPU较量空闲 ，没什么程序在跑 ，当这个值凌驾了CPU数目 ，就会泛起CPU瓶颈了。这个也和top的负载有关系 ，一样平常负载凌驾了3就较量高 ，凌驾了5就高 ，凌驾了10就不正常了 ，效劳器的状态很危险。top的负载类似每秒的运行行列。若是运行行列过大 ，体现你的CPU很忙碌 ，一样平常会造成CPU使用率很高。 - b 体现壅闭的历程,这个未几说 ，历程壅闭 ，各人懂的。 - swpd 虚拟内存已使用的巨细 ，若是大于0 ，体现你的机械物理内存缺乏了 ，若是不是程序内存泄露的缘故原由 ，那么你该升级内存了或者把耗内存的使命迁徙到其他机械。 - free 空闲的物理内存的巨细 ，我的机械内存总共8G ，剩余3415M。 - buff Linux/Unix系统是用来存储 ，目录内里有什么内容 ，权限等的缓存 ，我本机或许占用300多M - cache cache直接用来影象我们翻开的文件,给文件做缓冲 ，我本机或许占用300多M(这里是Linux/Unix的智慧之处 ，把空闲的物理内存的一部分拿来做文件和目录的缓存 ，是为了提高 程序执行的性能 ，当程序使用内存时 ，buffer/cached会很快地被使用。) - si 每秒从磁盘读入虚拟内存的巨细 ，若是这个值大于0 ，体现物理内存不敷用或者内存泄露了 ，要查找耗内存历程解决掉。我的机械内存充裕 ，一切正常。 - so 每秒虚拟内存写入磁盘的巨细 ，若是这个值大于0 ，同上。 - bi 块装备每秒吸收的块数目 ，这里的块装备是指系统上所有的磁盘和其他块装备 ，默认块巨细是1024byte ，我本机上没什么IO操作 ，以是一直是0 ，可是我曾在处理拷贝大宗数据(2-3T)的机械上看过可以抵达140000/s ，磁盘写入速率差未几140M每秒 - bo 块装备每秒发送的块数目 ，例如我们读取文件 ，bo就要大于0。bi和bo一样平常都要靠近0 ，不然就是IO过于频仍 ，需要调解。 - in 每秒CPU的中止次数 ，包括时间中止 - cs 每秒上下文切换次数 ，例如我们挪用系统函数 ，就要举行上下文切换 ，线程的切换 ，也要历程上下文切换 ，这个值要越小越好 ，太大了 ，要思量调低线程或者历程的数目,例如在apache和nginx这种web效劳器中 ，我们一样平常做性能测试时会举行几千并发甚至几万并发的测试 ，选择web效劳器的历程可以由历程或者线程的峰值一直下调 ，压测 ，直到cs到一个较量小的值 ，这个历程和线程数就是较量合适的值了。系统挪用也是 ，每次挪用系统函数 ，我们的代码就会进入内核空间 ，导致上下文切换 ，这个是很耗资源 ，也要只管阻止频仍挪用系统函数。上下文切换次数过多体现你的CPU大部分铺张在上下文切换 ，导致CPU干正经事的时间少了 ，CPU没有充分使用 ，是不可取的。 - us 用户CPU时间 ，我一经在一个做加密解密很频仍的效劳器上 ，可以看到us靠近100,r运行行列抵达80(机械在做压力测试 ，性能体现不佳)。 - sy 系统CPU时间 ，若是太高 ，体现系统挪用时间长 ，例如是IO操作频仍。 - id 空闲CPU时间 ，一样平常来说 ，id + us + sy = 100,一样平常我以为id是空闲CPU使用率 ，us是用户CPU使用率 ，sy是系统CPU使用率。 - wt 期待IO CPU时间
登录后复制
pidstat 使用详解
pidstat主要用于监控所有或指定历程占用系统资源的情形,如CPU,内存、装备IO、使命切换、线程等。
使用要领：
pidstat –d interval times 统计各个历程的IO使用情形
pidstat –u interval times 统计各个历程的CPU统计信息
pidstat –r interval times 统计各个历程的内存使用信息
pidstat -w interval times 统计各个历程的上下文切换
p PID 指定PID
1、统计IO使用情形
pidstat -d 1 10 03:02:02 PM UID PID kB_rd/s kB_wr/s kB_ccwr/s Command 03:02:03 PM 0 816 0.00 918.81 0.00 jbd2/vda1-8 03:02:03 PM 0 1007 0.00 3.96 0.00 AliYunDun 03:02:03 PM 997 7326 0.00 1904.95 918.81 java 03:02:03 PM 997 8539 0.00 3.96 0.00 java 03:02:03 PM 0 16066 0.00 35.64 0.00 cmagent 03:02:03 PM UID PID kB_rd/s kB_wr/s kB_ccwr/s Command 03:02:04 PM 0 816 0.00 1924.00 0.00 jbd2/vda1-8 03:02:04 PM 997 7326 0.00 11156.00 1888.00 java 03:02:04 PM 997 8539 0.00 4.00 0.00 java
登录后复制
UID
PID
kB_rd/s: 每秒历程从磁盘读取的数据量 KB 单位 read from disk each second KB
kB_wr/s: 每秒历程向磁盘写的数据量 KB 单位 write to disk each second KB
kB_ccwr/s: 每秒历程向磁盘写入 ，可是被作废的数据量 ，This may occur when the task truncates some dirty pagecache.
iodelay: Block I/O delay, measured in clock ticks
Command: 历程名 task name
2、统计CPU使用情形
# 统计CPU pidstat -u 1 10 03:03:33 PM UID PID %usr %system %guest %CPU CPU Command 03:03:34 PM 0 2321 3.96 0.00 0.00 3.96 0 ansible 03:03:34 PM 0 7110 0.00 0.99 0.00 0.99 4 pidstat 03:03:34 PM 997 8539 0.99 0.00 0.00 0.99 5 java 03:03:34 PM 984 15517 0.99 0.00 0.00 0.99 5 java 03:03:34 PM 0 24406 0.99 0.00 0.00 0.99 5 java 03:03:34 PM 0 32158 3.96 0.00 0.00 3.96 2 ansible
登录后复制
UID
PID
%usr: 历程在用户空间占用 cpu 的百分比
%system: 历程在内核空间占用 CPU 百分比
%guest: 历程在虚拟机占用 CPU 百分比
%wait: 历程期待运行的百分比
%CPU: 历程占用 CPU 百分比
CPU: 处理历程的 CPU 编号
Command: 历程名
3、统计内存使用情形
# 统计内存 pidstat -r 1 10 Average: UID PID minflt/s majflt/s VSZ RSS %MEM Command Average: 0 1 0.20 0.00 191256 3064 0.01 systemd Average: 0 1007 1.30 0.00 143256 22720 0.07 AliYunDun Average: 0 6642 0.10 0.00 6301904 107680 0.33 java Average: 997 7326 10.89 0.00 13468904 8395848 26.04 java Average: 0 7795 348.15 0.00 108376 1233 0.00 pidstat Average: 997 8539 0.50 0.00 8242256 2062228 6.40 java Average: 987 9518 0.20 0.00 6300944 1242924 3.85 java Average: 0 10280 3.70 0.00 807372 8344 0.03 aliyun-service Average: 984 15517 0.40 0.00 6386464 1464572 4.54 java Average: 0 16066 236.46 0.00 2678332 71020 0.22 cmagent Average: 995 20955 0.30 0.00 6312520 1408040 4.37 java Average: 995 20956 0.20 0.00 6093764 1505028 4.67 java Average: 0 23936 0.10 0.00 5302416 110804 0.34 java Average: 0 24406 0.70 0.00 10211672 2361304 7.32 java Average: 0 26870 1.40 0.00 1470212 36084 0.11 promtail
登录后复制
UID
PID
Minflt/s : 每秒次缺页过失次数 （minor page faults） ，虚拟内存地点映射成物理内存地点爆发的 page fault 次数
Majflt/s : 每秒主缺页过失次数 (major page faults), 虚拟内存地点映射成物理内存地点时 ，响应 page 在 swap 中
VSZ virtual memory usage : 该历程使用的虚拟内存 KB 单位
RSS : 该历程使用的物理内存 KB 单位
%MEM : 内存使用率
Command : 该历程的下令 task name
4、审查详细历程使用情形
pidstat -T ALL -r -p 20955 1 10 03:12:16 PM UID PID minflt/s majflt/s VSZ RSS %MEM Command 03:12:17 PM 995 20955 0.00 0.00 6312520 1408040 4.37 java 03:12:16 PM UID PID minflt-nr majflt-nr Command 03:12:17 PM 995 20955 0 0 java
登录后复制
以上就是Linux性能优化知识点总结大全 · 实践+珍藏版的详细内容 ，更多请关注本网内其它相关文章！
