Linux 운영 및 유지보수 문제 해결 아이디어는 이 글이면 충분합니다~

1. 배경

때때로 어렵고 복잡한 질병에 직면하게 되는데, 모니터링 플러그인으로는 문제의 근본 원인을 한눈에 바로 찾을 수 없습니다. 이때 문제의 근본 원인을 자세히 분석하려면 서버에 로그인해야 합니다. 그러면 문제를 분석하려면 어느 정도의 기술적 경험 축적이 필요하고, 어떤 문제는 문제를 찾아내기 위해 매우 넓은 영역을 포함합니다. 그러므로 문제를 분석하고 함정에 빠져드는 것은 개인의 성장과 자기계발을 위한 훌륭한 훈련입니다. 좋은 분석 도구 세트가 있다면 절반의 노력으로 두 배의 결과를 얻을 수 있으며, 모든 사람이 문제를 신속하게 찾을 수 있도록 돕고 더 심층적인 작업을 수행하는 데 많은 시간을 절약할 수 있습니다.

2. 설명

이 글에서는 주로 다양한 문제 위치 파악 도구를 소개하고 사례별로 문제를 분석합니다.

3. 문제 분석 방법론

5W2H 방법을 적용하면 성능 분석에 대한 여러 가지 질문을 할 수 있습니다

• 현상은 어떤가요
• 언제 발생합니까?
• 왜-왜 일어났나요
• 문제가 발생한 곳-어디에서
• 얼마나-얼마나 많은 리소스가 소모되었는지
• 방법-방법 해결하다 문제

4.cpu

4.1 설명

애플리케이션의 경우 일반적으로 커널 CPU 스케줄러 기능 및 성능에 중점을 둡니다.

스레드 상태 분석은 주로 스레드 시간이 사용되는 곳을 분석하며 스레드 상태의 분류는 일반적으로

1. on-CPU: 실행으로 나뉘며, 실행되는 시간은 일반적으로 사용자 모드 시간 사용자와 시스템 상태 시간 sys.

2. off-CPU: 다음 CPU 라운드를 기다리거나 I/O, 잠금, 페이지 변경 등을 기다리는 중입니다. 상태는 실행 가능, 익명 페이지 변경, 절전, 잠금, 유휴, 등. .

CPU에 많은 시간이 소요되는 경우 CPU를 프로파일링하면 원인을 빠르게 설명할 수 있습니다. 시스템이 CPU가 꺼진 상태에서 많은 시간을 소비하는 경우 문제를 찾는 데 많은 시간이 걸립니다. 그러나 여전히 명확해야 할 몇 가지 개념이 있습니다.

• Processor
• Core
• 하드웨어 스레드
• CPU 메모리 C 아파
• 시계 주파수
• CPI 및 주기당 지침 IPC
• CPU 지침
• Usage
• 사용자 시간/커널 시간
• 스케줄러
• 실행 대기열
• 선점
• 멀티 프로세스
• 멀티 스레딩
• W ord length

4.2 분석 도구

참고:

• uptime, vmstat, mpstat, top, pidstat는 CPU 사용량과 로드만 쿼리할 수 있습니다.
• perf는 프로세스 내에서 특정 기능의 시간이 많이 걸리는 상태를 추적할 수 있으며 통계를 위한 커널 기능을 지정하고 이에 따라 대상을 지정할 수 있습니다.

4.3 사용 방법

//查看系统cpu使用情况top
//查看所有cpu核信息mpstat -P ALL 1
//查看cpu使用情况以及平均负载vmstat 1
//进程cpu的统计信息pidstat -u 1 -p pid
//跟踪进程内部函数级cpu使用情况 perf top -p pid -e cpu-clock

5. 메모리

5.1 설명

메모리 문제는 실제로 문제를 분석할 때 성능에만 영향을 미치는 것이 아닙니다. , 서비스에 영향을 미치거나 다른 문제를 일으킵니다.同样对于内存有些概念需要清楚：

牛逼啊！接私活必备的 N 个开源项目！赶快收藏

• 主存
• 虚拟内存
• 常驻内存
• 地址空间
• OOM
• 页缓存
• 缺页
• 换页
• 交换空间
• 交换
• 用户分配器libc、glibc、libmalloc和mtmalloc
• LINUX内核级SLUB分配器

5.2 分析工具

说明：

• free，vmstat，top，pidstat，pmap只能统计内存信息以及进程的内存使用情况。

• valgrind 可以分析内存泄漏问题。

• dtrace 动态跟踪。需要对内核函数有很深入的了解，通过D语言编写脚本完成跟踪。

5.3 使用方式

//查看系统内存使用情况free -m//虚拟内存统计信息vmstat 1//查看系统内存情况top//1s采集周期，获取内存的统计信息pidstat -p pid -r 1//查看进程的内存映像信息pmap -d pid//检测程序内存问题valgrind --tool=memcheck --leak-check=full --log-file=./log.txt  ./程序名

6. 磁盘IO

6.1 说明

磁盘通常是计算机最慢的子系统，也是最容易出现性能瓶颈的地方，因为磁盘离 CPU 距离最远而且 CPU 访问磁盘要涉及到机械操作，比如转轴、寻轨等。访问硬盘和访问内存之间的速度差别是以数量级来计算的，就像1天和1分钟的差别一样。要监测 IO 性能，有必要了解一下基本原理和 Linux 是如何处理硬盘和内存之间的 IO 的。

在理解磁盘IO之前，同样我们需要理解一些概念，例如：

• 파일 시스템
• VFS
• 파일 시스템 캐시
• 페이지 캐시 페이지 캐시
• 버퍼 캐시 버퍼 캐시
• 디렉토리 캐시
• inode
• inode 캐시
• noop 호출 전략

6.2 분석 도구

6.3 使用方式

//查看系统io信息iotop//统计io详细信息iostat -d -x -k 1 10//查看进程级io的信息pidstat -d 1 -p  pid//查看系统IO的请求，比如可以在发现系统IO异常时，可以使用该命令进行调查，就能指定到底是什么原因导致的IO异常perf record -e block:block_rq_issue -ag^Cperf report

7. 网络

7.1 说明

网络的监测是所有 Linux 子系统里面最复杂的，有太多的因素在里面，比如：延迟、阻塞、冲突、丢包等，更糟的是与 Linux 主机相连的路由器、交换机、无线信号都会影响到整体网络并且很难判断是因为 Linux 网络子系统的问题还是别的设备的问题，增加了监测和判断的复杂度。现在我们使用的所有网卡都称为自适应网卡，意思是说能根据网络上的不同网络设备导致的不同网络速度和工作模式进行自动调整。

7.2 分析工具

7.3 使用方式

//显示网络统计信息netstat -s//显示当前UDP连接状况netstat -nu//显示UDP端口号的使用情况netstat -apu//统计机器中网络连接各个状态个数netstat -a | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'//显示TCP连接ss -t -a//显示sockets摘要信息ss -s//显示所有udp socketsss -u -a//tcp,etcp状态sar -n TCP,ETCP 1//查看网络IOsar -n DEV 1//抓包以包为单位进行输出tcpdump -i eth1 host 192.168.1.1 and port 80 //抓包以流为单位显示数据内容tcpflow -cp host 192.168.1.1

8. 系统负载

8.1 说明

Load 就是对计算机干活多少的度量（WikiPedia：the system Load is a measure of the amount of work that a compute system is doing）简单的说是进程队列的长度。Load Average 就是一段时间（1分钟、5分钟、15分钟）内平均Load。

8.2 分析工具

8.3 使用方式

//查看负载情况uptimetopvmstat//统计系统调用耗时情况strace -c -p pid//跟踪指定的系统操作例如epoll_waitstrace -T -e epoll_wait -p pid//查看内核日志信息dmesg

9. 火焰图

9.1 说明

火焰图（Flame Graph是 Bredan Gregg 创建的一种性能分析图表，因为它的样子近似 ?而得名。

火焰图主要是用来展示 CPU的调用栈。

y 轴表示调用栈，每一层都是一个函数。调用栈越深，火焰就越高，顶部就是正在执行的函数，下方都是它的父函数。

x 轴表示抽样数，如果一个函数在 x 轴占据的宽度越宽，就表示它被抽到的次数多，即执行的时间长。注意，x 轴不代表时间，而是所有的调用栈合并后，按字母顺序排列的。

火焰图就是看顶层的哪个函数占据的宽度最大。只要有”平顶”（plateaus），就表示该函数可能存在性能问题。颜色没有特殊含义，因为火焰图表示的是 CPU 的繁忙程度，所以一般选择暖色调。

常见的火焰图类型有 On-CPU、Off-CPU、Memory、Hot/Cold、Differential等等。

9.2 安装依赖库

//安装systemtap，默认系统已安装yum install systemtap systemtap-runtime//内核调试库必须跟内核版本对应，例如：uname -r 2.6.18-308.el5kernel-debuginfo-2.6.18-308.el5.x86_64.rpmkernel-devel-2.6.18-308.el5.x86_64.rpmkernel-debuginfo-common-2.6.18-308.el5.x86_64.rpm//安装内核调试库debuginfo-install --enablerepo=debuginfo search kerneldebuginfo-install --enablerepo=debuginfo  search glibc

9.3 安装

git clone https://github.com/lidaohang/quick_location.gitcd quick_location

9.4 CPU级别火焰图

cpu占用过高，或者使用率提不上来，你能快速定位到代码的哪块有问题吗？

一般的做法可能就是通过日志等方式去确定问题。现在我们有了火焰图，能够非常清晰的发现哪个函数占用cpu过高，或者过低导致的问题。另外，搜索公众号Linux就该这样学后台回复“猴子”，获取一份惊喜礼包。

9.4.1 on-CPU

cpu占用过高，执行中的时间通常又分为用户态时间user和系统态时间sys。

使用方式：

//on-CPU usersh ngx_on_cpu_u.sh pid//进入结果目录 cd ngx_on_cpu_u//on-CPU kernelsh ngx_on_cpu_k.sh pid//进入结果目录 cd ngx_on_cpu_k//开一个临时端口 8088 python -m SimpleHTTPServer 8088//打开浏览器输入地址127.0.0.1:8088/pid.svg

DEMO：

#include <stdio.h>#include <stdlib.h>
void foo3(){  }
void foo2(){    int i;    for(i=0 ; i < 10; i++)           foo3();}
void foo1(){    int i;  for(i = 0; i< 1000; i++)      foo3();}
int main(void){    int i;    for( i =0; i< 1000000000; i++) {          foo1();          foo2();    }}

DEMO火焰图：

9.4.2 off-CPU

cpu过低，利用率不高。等待下一轮CPU，或者等待I/O、锁、换页等等，其状态可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。

使用方式：

// off-CPU usersh ngx_off_cpu_u.sh pid//进入结果目录cd ngx_off_cpu_u//off-CPU kernelsh ngx_off_cpu_k.sh pid//进入结果目录cd ngx_off_cpu_k//开一个临时端口8088python -m SimpleHTTPServer 8088//打开浏览器输入地址127.0.0.1:8088/pid.svg

官网DEMO：

9.5 内存级别火焰图

如果线上程序出现了内存泄漏，并且只在特定的场景才会出现。这个时候我们怎么办呢？有什么好的方式和工具能快速的发现代码的问题呢？同样内存级别火焰图帮你快速分析问题的根源。

使用方式：

sh ngx_on_memory.sh pid//进入结果目录cd ngx_on_memory//开一个临时端口8088python -m SimpleHTTPServer 8088//打开浏览器输入地址127.0.0.1:8088/pid.svg

官网DEMO：

9.6 性能回退-红蓝差分火焰图

你能快速定位CPU性能回退的问题么？如果你的工作环境非常复杂且变化快速，那么使用现有的工具是来定位这类问题是很具有挑战性的。当你花掉数周时间把根因找到时，代码已经又变更了好几轮，新的性能问题又冒了出来。主要可以用到每次构建中，每次上线做对比看，如果损失严重可以立马解决修复。

通过抓取了两张普通的火焰图，然后进行对比，并对差异部分进行标色：红色表示上升，蓝色表示下降。差分火焰图是以当前（“修改后”）的profile文件作为基准，形状和大小都保持不变。因此你通过色彩的差异就能够很直观的找到差异部分，且可以看出为什么会有这样的差异。

使用方式：

cd quick_location//抓取代码修改前的profile 1文件perf record -F 99 -p pid -g -- sleep 30perf script > out.stacks1//抓取代码修改后的profile 2文件perf record -F 99 -p pid -g -- sleep 30perf script > out.stacks2//生成差分火焰图:./FlameGraph/stackcollapse-perf.pl ../out.stacks1 > out.folded1./FlameGraph/stackcollapse-perf.pl ../out.stacks2 > out.folded2./FlameGraph/difffolded.pl out.folded1 out.folded2 | ./FlameGraph/flamegraph.pl > diff2.svg

DEMO：

//test.c#include <stdio.h>#include <stdlib.h>
void foo3(){  }
void foo2(){    int i;    for(i=0 ; i < 10; i++)      foo3();}
void foo1(){    int i;    for(i = 0; i< 1000; i++)       foo3();}
int main(void){    int i;  for( i =0; i< 1000000000; i++) {      foo1();      foo2();    }}
//test1.c#include <stdio.h>#include <stdlib.h>
void foo3(){
}
void foo2(){  int i;  for(i=0 ; i < 10; i++)         foo3();}
void foo1(){    int i;    for(i = 0; i< 1000; i++)         foo3();}
void add(){    int i;    for(i = 0; i< 10000; i++)       foo3();}
int main(void){    int i;    for( i =0; i< 1000000000; i++) {    foo1();    foo2();    add();  }}

DEMO红蓝差分火焰图：

10. 사례 분석

10.1 액세스 계층에서 nginx 클러스터의 이상 현상

19:00에 nginx 클러스터 요청 트래픽에 499 및 5xx 상태 코드가 대량으로 나타나는 것이 모니터링 플러그인을 통해 발견되었습니다. 2017년 9월 25일. 그리고 머신의 CPU 사용량이 증가한 것으로 나타났으며, 이는 계속됩니다. 또한, 공식 계정 상위 알고리즘 배경을 검색해 '알고리즘'이라고 답하시면 깜짝 선물을 받으실 수 있습니다.

10.2 nginx 관련 지표 분석

a) **nginx 요청 트래픽 분석:

결론:

위 그림을 통해 트래픽이 증가하지 않음을 확인했습니다. 갑자기, 대신 감소, 팔로우 요청 트래픽이 갑자기 증가해도 문제가 되지 않습니다.

b) **nginx 응답 시간 분석

결론:

위 그림에서 nginx 응답 시간의 증가는 nginx 자체 또는 백엔드와 관련이 있을 수 있음을 알 수 있습니다. 업스트림 응답 시간.

c) **nginx 업스트림 응답 시간 분석

결론:

위 그림을 보면 nginx 업스트림 응답 시간이 증가한 것으로 추측됩니다. 백엔드 업스트림 응답 시간으로 인해 nginx가 지연되어 nginx에 비정상적인 요청 트래픽이 발생할 수 있습니다.

10.3 시스템 CPU 상황 분석

a) **상단을 통해 시스템 표시 관찰

상단top

结论：

发现nginx worker cpu比较高

b) **分析nginx进程内部cpu情况

perf top -p pid

🎜🎜🎜결론:🎜🎜🎜🎜nginx 작업자 CPU가 상대적으로 높다는 것을 발견했습니다🎜🎜🎜🎜 b) 🎜**🎜nginx 프로세스의 내부 CPU 상황 분석🎜🎜🎜perf top -p pid🎜

结论：

发现主要开销在free,malloc,json解析上面

10.4 火焰图分析cpu
a) **生成用户态cpu火焰图

//on-CPU usersh ngx_on_cpu_u.sh pid//进入结果目录cd ngx_on_cpu_u//开一个临时端口8088python -m SimpleHTTPServer 8088//打开浏览器输入地址127.0.0.1:8088/pid.svg

结论：

发现代码里面有频繁的解析json操作，并且发现这个json库性能不高，占用cpu挺高。

10.5 案例总结

a) 分析请求流量异常，得出nginx upstream后端机器响应时间拉长

b) nginx 프로세스의 높은 CPU를 분석한 결과, nginx 내부 모듈 코드에는 json 구문 분석 및 메모리 할당 및 재활용 작업에 시간이 많이 걸리는 것으로 결론지었습니다.

10.5.1 심층 분석

위의 두 가지 사항에 대한 분석을 바탕으로 결론을 내리고, 더 심층적으로 분석합니다.

백엔드 업스트림 응답이 확장되어 nginx의 처리 기능에 기껏해야 영향을 미칠 수 있습니다. 그러나 너무 많은 CPU 작업을 차지하는 nginx 내부 모듈에는 영향을 미치지 않을 것입니다. 그리고 당시 CPU를 많이 점유하고 있던 모듈들은 요청이 있을 때만 실행되었습니다. 업스트램 백엔드가 nginx를 보류하여 CPU의 시간 소모적인 작업을 트리거할 가능성은 거의 없습니다.

10.5.2 솔루션

이런 종류의 문제가 발생하면 알려지고 매우 명확한 문제를 해결하는 데 우선 순위를 둘 것입니다. CPU가 높을수록 문제가 됩니다. 해결 방법은 CPU를 너무 많이 소모하는 모듈을 다운그레이드하고 닫은 후 관찰하는 것입니다. 모듈을 다운그레이드하고 종료한 후 CPU가 저하되고 nginx 요청 트래픽이 정상화되었습니다. 업스트림 시간이 길어지는 이유는 업스트림 백엔드 서비스에서 호출한 인터페이스가 루프가 되어 다시 nginx로 돌아갈 수 있기 때문입니다.

11.参考资料

• http://www.brendangregg.com/index.html

• http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html

• http://www.brendangregg.com/FlameGraphs/memoryflamegraphs.html

• http://www.brendangregg.com/FlameGraphs/offcpuflamegraphs.html

• http://www.brendangregg. com/blog/2014-11-09/ Differential-flame-graphs.html

• https://github.com/openresty/openresty-systemtap-toolkit

• https://github.com com/brendangregg/FlameGraph

• https://www.slideshare.net/brendangregg/blazing-performance-with-flame-graphs

위 내용은 Linux 운영 및 유지보수 문제 해결 아이디어는 이 글이면 충분합니다~의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!