linux系统分析双剑客 (atop+perf)

2021-12-08 19:13:54 浏览数 (1)

linux系统分析双剑客 (atop perf)

操作系统内部本身是非常复杂,存在各种调用关系,本文主要讲解利用 atop perf 双剑客来加速排障和分析一些常见的负载问题

剑客一 atop

atop就是一款用于监控Linux系统资源与进程的工具,它以一定的频率记录系统的运行状态,所采集的数据包含系统资源(CPU、内存、磁盘和网络)使用情况和进程运行情况,并能以日志文件的方式保存在磁盘中,服务器出现问题后,我们可获取相应的atop日志文件进行分析

一,atop使用方法

yum install-y atop 在安装atop之后,我们在命令行下敲入”atop"命令即可看到系统当前的运行情况

安装后 vi /etc/sysconfig/atop更新配置, 注意间隔磁盘可能会爆

LOGINTERVAL=600 #默认600S对抓取细节帮助不大

LOGGENERATIONS=28 #保留天数

改成:

LOGINTERVAL=30 #间隔30S

LOGGENERATIONS=7 #保留时间7天

重启服务生效:

systemctl restart atop

二,监控字段的含义

ATOP列:该列显示了主机名、信息采样日期和时间点

PRC列:该列显示进程整体运行情况

sys、usr字段分别指示进程在内核态和用户态的运行时间

#proc字段指示进程总数

#zombie字段指示僵死进程的数量

#exit字段指示atop采样周期期间退出的进程数量

CPU列:该列显示CPU整体(即多核CPU作为一个整体CPU资源)的使用情况,我们知道CPU可被用于执行进程、处理中断,也可处于空闲状态(空闲状态分两种,一种是活动进程等待磁盘IO导致CPU空闲,另一种是完全空闲)

sys、usr字段指示CPU被用于处理进程时,进程在内核态、用户态所占CPU的时间比例

irq字段指示CPU被用于处理中断的时间比例

idle字段指示CPU处在完全空闲状态的时间比例

wait字段指示CPU处在“进程等待磁盘IO导致CPU空闲”状态的时间比例

CPU列各个字段指示值相加结果为N00%,其中N为cpu核数。

cpu列:该列显示某一核cpu的使用情况,各字段含义可参照CPU列,各字段值相加结果为100%

CPL列:该列显示CPU负载情况

avg1、avg5和avg15字段:过去1分钟、5分钟和15分钟内运行队列中的平均进程数量

csw字段指示上下文交换次数

intr字段指示中断发生次数

MEM列:该列指示内存的使用情况

tot字段指示物理内存总量

free字段指示空闲内存的大小

cache字段指示用于页缓存的内存大小

buff字段指示用于文件缓存的内存大小

slab字段指示系统内核占用的内存大小

SWP列:该列指示交换空间的使用情况

tot字段指示交换区总量

free字段指示空闲交换空间大小

PAG列:该列指示虚拟内存分页情况

swin、swout字段:换入和换出内存页数

DSK列:该列指示磁盘使用情况,每一个磁盘设备对应一列,如果有sdb设备,那么增多一列DSK信息

sda字段:磁盘设备标识

busy字段:磁盘忙时比例

read、write字段:读、写请求数量

NET列:多列NET展示了网络状况,包括传输层(TCP和UDP)、IP层以及各活动的网口信息

XXXi 字段指示各层或活动网口收包数目

XXXo 字段指示各层或活动网口发包数目

三,常用参数 (在交互模式下也可以用这些参数)

-n 显示网络信息(需要内核打补丁才能使用)

-m 显示内存相关信息

-d 显示磁盘读写相关

-g 查看默认的通用输出

-s 显示调度特点:每个进程的以下字段所示:进程的ID,运行状态(R)的线程数、中断状态的睡眠线程S(TLSPI)和不可中断睡眠线程D (TSLPU) 数,调度策略(分时调度策略,实时时间片轮转策略,实时调度策略FIFO),nice值,优先级(PRI),实时优先级(RTPR),当前的处理器,状态,退出代码,进程状态,cpu利用率和进程名。

-v 显示各种进程特性:每个进程的以下字段所示:进程ID(PID),父进程ID(PPID)、用户名(USERNAME)和组(GROUP),开始日期和时间,状态(例如,退出代码,如果该进程已完成),进程状态(ST)(D:不可终止进程、 R:正在运行进程 、 T:暂停进程、S:休眠进程、Z:僵尸进程……),CPU占用率和进程名。

-c 以命令行command-line的形式显示:每个进程有以下字段所示:进程的ID,所选资源占用百分比和命令行参数,

-u 以用户的形式显示:以下字段显示:在上一间隔时间内活动或终止的进程数,上一时间间隔内cpu在系统模式和用户模式的消耗,活动进程对虚拟内存和现有内存的消耗。当安装的cnt补丁后会显示读(RDDSK)写(WRDSK)到磁盘上的数据量,以及所收到(RNET)和发送(SNET)的网络数据包,内核补丁没有安装时这些计数器为零。最后一栏显示CPU百分比和用户名。

-p 以进程名的形式显示信息:和-u类似只是最后显示的是进程名

-M 按照占用物理内存百分比大小进行排列

-D,按照访问磁盘的繁忙程度进行排序

-N 按照接受和发送的网络数据包排序

-A 依据当前系统最繁忙的资源进行排序,可能有ACPU、AMEM、ADSK或者ANET

四、常用命令

atop 常用命令

atop -r atop_202112081 打开日志文件 默认存放在/var/log/atop目录下

您可在打开日志文件后,使用以下命令筛选所需数据:

lc:按照进程的 CPU 使用率降序筛选。

lm:按照进程的内存使用率降序筛选。

ld:按照进程的磁盘使用率降序筛选。

la:按照进程资源综合使用率进行降序筛选。

ln:按照进程的网络使用率进行降序筛选(使用此命令需安装额外的内核模块,默认不支持)。https://www.atoptool.nl/downloadnetatop.php

tar zxvf netatop-3.1.tar.gz &&cd netatop-3.1/

yum install zlib-devel zlib1-dev kernel-devel

make&&make install

lt:跳转到下一个监控采集点。

lT:跳转到上一个监控采集点。

lb:指定时间点,格式为 YYYYMMDDhhmm。

五、案例分析

#atop 分析

atop -r 打开/var/log/atop 监控文件,通过指定时间点或者t/T 跳转上下文来抓取历史记录

t:跳转到下一个监控采集点。

T:跳转到上一个监控采集点

b:指定时间点,格式为 YYYYMMDDhhmm。

通过atop分析系统负载异常原因

#问题场景

通过CLB分发的服务,服务均等,机器配置一致,部分机器负载偏高

#前期准备:

1、横向对比:前端部署负载均衡,通过对比看业务瓶颈点

2、atop部署:压测过程提前把时间间隔调整为5S,压测完成及时停止atop,防止磁盘爆

LOGINTERVAL=5 #5S采集一次

LOGGENERATIONS=7 #保留时间7天

重启服务生效:

systemctl restart atop

#atop 分析

atop -r 打开/var/log/atop 监控文件,通过指定时间点或者t/T 跳转上下文来抓取历史记录

t:跳转到下一个监控采集点。

T:跳转到上一个监控采集点

b:指定时间点,格式为 YYYYMMDDhhmm。

-s 显示调度特点:每个进程的以下字段所示:进程的ID,运行状态(R)的线程数、中断状态的睡眠线程S(TLSPI)和不可中断睡眠线程D (TSLPU) 数,调度策略(分时调度策略,实时时间片轮转策略,实时调度策略FIFO),nice值,优先级(PRI),实时优先级(RTPR),当前的处理器,状态,退出代码,进程状态,cpu利用率和进程名。

-v 显示各种进程特性:每个进程的以下字段所示:进程ID(PID),父进程ID(PPID)、用户名(USERNAME)和组(GROUP),开始日期和时间,状态(例如,退出代码,如果该进程已完成),进程状态(ST)(D:不可终止进程、 R:正在运行进程 、 T:暂停进程、S:休眠进程、Z:僵尸进程……),CPU占用率和进程名。

-c 以命令行command-line的形式显示:每个进程有以下字段所示:进程的ID,所选资源占用百分比和命令行参数,

原因核实:存在中断状态的睡眠线程S(TLSPI)和不可中断睡眠线程D (TSLPU) 数 ,看了内核 /proc/loadavg的实现,负载主要是有运行的进程个数和D住的进程个数组成,每5秒会衰减一次,如果D的进程多,负载会异常升高

前面说了通过atop分析到系统进程级别的负载上涨的原因,那么如何看到进程级别到用的函数级别的变化,那么接下来在perf里面有详情讲解到,且看第二篇

剑客二 perf

系统级性能优化通常包括两个阶段:性能剖析(performance profiling)和代码优化。

性能剖析的目标是寻找性能瓶颈,查找引发性能问题的原因及热点代码。

代码优化的目标是针对具体性能问题而优化代码或编译选项,以改善软件性能。

perf是一款Linux性能分析工具,通过perf,应用程序可以利用PMU、tracepoint和内核中的计数器来进行性能统计。它不但可以分析制定应用程序的性能问题(per thread),也可以用来分析内核的性能问题,当然也可以同时分析应用程序和内核,从而全面理解应用程序中的性能瓶颈。

一、perf 使用方法

perf --help之后可以看到perf的二级命令。

序号

命令

作用

1

annotate

解析perf record生成的perf.data文件,显示被注释的代码。

2

archive

根据数据文件记录的build-id,将所有被采样到的elf文件打包。利用此压缩包,可以再任何机器上分析数据文件中记录的采样数据。

3

bench

perf中内置的benchmark,目前包括两套针对调度器和内存管理子系统的benchmark。

4

buildid-cache

管理perf的buildid缓存,每个elf文件都有一个独一无二的buildid。buildid被perf用来关联性能数据与elf文件。

5

buildid-list

列出数据文件中记录的所有buildid。

6

diff

对比两个数据文件的差异。能够给出每个符号(函数)在热点分析上的具体差异。

7

evlist

列出数据文件perf.data中所有性能事件。

8

inject

该工具读取perf record工具记录的事件流,并将其定向到标准输出。在被分析代码中的任何一点,都可以向事件流中注入其它事件。

9

kmem

针对内核内存(slab)子系统进行追踪测量的工具

10

kvm

用来追踪测试运行在KVM虚拟机上的Guest OS。

11

list

列出当前系统支持的所有性能事件。包括硬件性能事件、软件性能事件以及检查点。

12

lock

分析内核中的锁信息,包括锁的争用情况,等待延迟等。

13

mem

内存存取情况

14

record

收集采样信息,并将其记录在数据文件中。随后可通过其它工具对数据文件进行分析。

15

report

读取perf record创建的数据文件,并给出热点分析结果。

16

sched

针对调度器子系统的分析工具。

17

script

执行perl或python写的功能扩展脚本、生成脚本框架、读取数据文件中的数据信息等。

18

stat

执行某个命令,收集特定进程的性能概况,包括CPI、Cache丢失率等。

19

test

perf对当前软硬件平台进行健全性测试,可用此工具测试当前的软硬件平台是否能支持perf的所有功能。

20

timechart

针对测试期间系统行为进行可视化的工具

21

top

类似于linux的top命令,对系统性能进行实时分析。

22

trace

关于syscall的工具。

23

probe

用于定义动态检查点。

二、常用命令

全局性概况:

perf list查看当前系统支持的性能事件;

perf bench对系统性能进行摸底;

perf test对系统进行健全性测试;

perf stat对全局性能进行统计;

全局细节:

perf top可以实时查看当前系统进程函数占用率情况;

perf probe可以自定义动态事件;

特定功能分析:

perf kmem针对slab子系统性能分析;

perf kvm针对kvm虚拟化分析;

perf lock分析锁性能;

perf mem分析内存slab性能;

perf sched分析内核调度器性能;

perf trace记录系统调用轨迹;

最常用功能perf record,可以系统全局,也可以具体到某个进程,更甚具体到某一进程某一事件;可宏观,也可以很微观。

pref record记录信息到perf.data;

perf report生成报告;

perf diff对两个记录进行diff;

perf evlist列出记录的性能事件;

perf annotate显示perf.data函数代码;

perf archive将相关符号打包,方便在其它机器进行分析;

perf script将perf.data输出可读性文本;

三,案例分析

运行命令perf record ,并将其数据保存到perf.data中。随后,可以使用perf report进行分析。

perf record和perf report可以更精确的分析一个应用,perf record可以精确到函数级别。并且在函数里面混合显示汇编语言和代码。

常用选项

-e record指定PMU事件

--filter event事件过滤器

-a 录取所有CPU的事件

-p 录取指定pid进程的事件

-o 指定录取保存数据的文件名

-g 使能函数调用图功能

-C 录取指定CPU的事件

分析进程函数组成部分和消耗情况

##提前部署atop

压测过程提前把时间间隔调整为10S(根据业务敏感度可以再调整),压测完成及时停止atop,防止磁盘爆

LOGINTERVAL=1 #10S采集一次

LOGGENERATIONS=7 #保留时间7天

重启服务生效:

systemctl restart atop

##使用perf 分析进程状态栈

sampling在某些情况下会引入非常大的负荷;bpf可以有效缩减负荷,针对sampling,可以通过挂在建立在RAM上的文件系统来有效降低读写I/O引入的负荷。

#mkdir /tmpfs &&mount -t tmpfs tmpfs /tmpfs

#perf top 查看实时的进程情况

初步分析得出:nginx 写文件等mutex锁进入D状态栈,用户态栈解释不出来 ,并发写同1个文件的情况.怀疑机器NGINX在高峰期写日志可能触发了互斥锁 osq_lock

# 业务通过 ./perf-monitor task-state -D --than 100 --filter nginx -g >log.txt 确认锁确实存在

perf-monitor

##使用 strace分析进程耗时情况

#同时使用 strace -o strace.txt -Tt -Ff -v -p xx //xx替换为业务 pid 分析

业务确认nginx请求日志写本地确认是本地文件太大了影响,基本都是几十毫秒,从而产生了D进程

##业务措施

nginx正常是2G就会自动切割压缩的,现在是超过2G还没切割压缩,清完之后立马耗时降下来了,D进程和负载随着下降

0 人点赞