Linux性能优化

发布时间：2023-02-20 10:14:08 所属栏目：Linux 来源：互联网

导读：高并发和响应快对应着性能优化的两个核心指标：吞吐和延时。应用负载角度：直接影响了产品终端的用户体验系统资源角度：资源使用率、饱和度等性能问题的本质就是系统资源已经到达瓶颈，但请求的处理还不够快，无法支撑更多的请求。性能分析实际上就是找出

　　用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使用情况.找出导致平均负载较高的进程.

　　上下文切换案例

　　先用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攻击导致

　　根据不同的性能指标来找合适的工具：

　　在生产环境中往往开发者没有权限安装新的工具包,只能最大化利用好系统中已经安装好的工具. 因此要了解一些主流工具能够提供哪些指标分析：

　　先运行几个支持指标较多的工具,如top/vmstat/pidstat,根据它们的输出可以得出是哪种类型的性能问题. 定位到进程后再用strace/perf分析调用情况进一步分析. 如果是软中断导致用/proc/softirqs。

　　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)每秒事务数,软件测试的结果.

　　系统吞吐量,包括几个重要参数:

　　内存
　　Linux内存是怎么工作的

　　内存映射

　　大多数计算机用的主存都是动态随机访问内存(DRAM)，只有内核才可以直接访问物理内存。Linux内核给每个进程提供了一个独立的虚拟地址空间，并且这个地址空间是连续的。这样进程就可以很方便的访问内存(虚拟内存)。

　　虚拟地址空间的内部分为内核空间和用户空间两部分，不同字长的处理器地址空间的范围不同。32位系统内核空间占用1G，用户空间占3G。64位系统内核空间和用户空间都是128T，分别占内存空间的最高和最低处，中间部分为未定义。

　　并不是所有的虚拟内存都会分配物理内存，只有实际使用的才会。分配后的物理内存通过内存映射管理。为了完成内存映射，内核为每个进程都维护了一个页表，记录虚拟地址和物理地址的映射关系。页表实际存储在cpu的内存管理单元MMU中，处理器可以直接通过硬件找出要访问的内存。

　　当进程访问的虚拟地址在页表中查不到时，系统会产生一个缺页异常，进入内核空间分配物理内存，更新进程页表，再返回用户空间恢复进程的运行。

　　MMU以页为单位管理内存，页大小4KB。为了解决页表项过多问题Linux提供了多级页表和HugePage的机制。

　　虚拟内存空间分布

　　用户空间内存从低到高是五种不同的内存段：

　　只读段代码和常量等

　　数据段全局变量等

　　堆动态分配的内存，从低地址开始向上增长

　　文件映射动态库、共享内存等，从高地址开始向下增长

（编辑：莱芜站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

3/7

首页

尾页