Linuxの運用とメンテナンスのトラブルシューティングのアイデア、この記事で十分です~

#1. 背景

困難で複雑な病気に遭遇すると、モニタリング プラグインでは対処できない場合があります。一目ですぐに使用できるようになります。 問題の根本を発見します。現時点では、問題の根本原因をさらに分析するためにサーバーにログインする必要があります。次に、問題を分析するには、ある程度の技術的経験の蓄積が必要であり、問​​題によっては、問題を特定するために非常に広範囲の領域が関与する必要があります。したがって、問題を分析し、落とし穴に足を踏み入れることは、成長と自己改善のための素晴らしい練習になります。優れた分析ツールのセットがあれば、半分の労力で 2 倍の結果が得られ、全員が問題を迅速に特定できるようになり、全員がより詳細な作業を行う時間を大幅に節約できます。

#2. 説明

この記事この記事では主に、さまざまな問題位置付けツールを紹介し、事例に基づいて問題を分析します。

3. 問題分析の方法論

5W2H メソッドを適用すると、パフォーマンス分析に関するいくつかの疑問が生じる可能性があります

• What-その現象はどのようなものですか
• いつ-いつ起こりますか
• なぜ-なぜそれが起こったのか
• どこ-どこで問題が起こったのか
• 消費されたリソースの量
• #方法-問題の解決方法

4. cpu

4.1 説明

アプリケーションについては、通常、カーネル CPU スケジューラの機能とパフォーマンスに焦点を当てます。

スレッド状態分析は主にスレッド時間がどこで使用されているかを分析し、スレッド状態の分類は一般に次のように分類されます。

1. CPU 上:実行中の時間は、通常、ユーザー モードの時間 user とシステム モードの時間 sys に分割されます。

2. off-CPU: CPU の次のラウンドを待機するか、I/O、ロック、ページ変更などを待機します。そのステータスは次のように細分化できます。実行可能ファイル、匿名ページング、スリープ、ロック、アイドル、その他の状態。

CPU に多くの時間が費やされている場合は、CPU をプロファイリングすることで原因をすぐに説明できます。システムがオフ CPU 状態に長時間費やしている場合は、問題の場所を特定できます。かなり時間がかかります。ただし、明確にしておく必要がある概念がまだいくつかあります。

• プロセッサ
• コア
• ハードウェア スレッド
• CPU メモリ キャッシュ
• クロック周波数
• CPI とサイクルごとの命令 IPC
• CPU 命令
• 使用率
• ユーザー時間/カーネル時間
• スケジューラ
• 実行キュー
• プリエンプション
• 複数のプロセス
• 複数のスレッド
• 単語長

##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 クラスターのアクセス層の異常

  監視プラグインにより、499 と 5xx が大量に発生していることが判明2017 年 9 月 25 日 19 時の nginx クラスターリクエストトラフィックのステータスコード。そして、マシンの CPU 使用率が増加し、それが続いていることが判明しました。さらに、公式アカウントのトップアルゴリズム背景を検索し、「アルゴリズム」と返信すると、サプライズギフトパッケージがプレゼントされます。

  10.2 nginx 関連のインジケーターの分析

  a) nginx リクエスト トラフィックの分析:

  

  結論:

  上の図から、トラフィックは急激に増加したのではなく、減少していることがわかります。これは急激な増加とは何の関係もありません。リクエストトラフィック中。

  ###

  b) #nginx 応答時間の分析
  

  結論:

  上の図から、nginx の応答時間の増加は nginx 自体、またはバックエンドのアップストリームの応答時間に関連している可能性があることがわかります。

  #c) ##nginx アップストリーム応答時間の分析

  

  ##結論:

  上記の図から、nginx のアップストリーム応答時間が増加していることがわかります。現在、バックエンドのアップストリーム応答時間が nginx を抑制し、nginx に異常なリクエストが発生している可能性があると推測されています。渋滞。

  10.3 システム CPU の状況を分析する

  a) **トップからシステム インジケーターを観察します

  トップ

  

  #結論:

  #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 詳細な分析

  上記 2 点の分析の結論に基づいて、さらに詳細な分析を行っていきます。

  バックエンドのアップストリーム応答が長くなり、最大で 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/fferential-flame-graphs.html

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

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

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

  ##

以上がLinuxの運用とメンテナンスのトラブルシューティングのアイデア、この記事で十分です~の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。