検索
ホームページ運用・保守Linuxの運用と保守Linuxの運用とメンテナンスのトラブルシューティングのアイデア、この記事で十分です~


#1. 背景

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

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

#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 分析ツール

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

##注:

  • 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 分析工具

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

说明:

  • 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 分析工具

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

    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 分析工具

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

    8.3 使用方式

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

    9. 火焰图

    9.1 说明

    火焰图(Flame Graph是 Bredan Gregg 创建的一种性能分析图表,因为它的样子近似 ?而得名。
    火焰图主要是用来展示 CPU的调用栈。
    轴表示调用栈,每一层都是一个函数。调用栈越深,火焰就越高,顶部就是正在执行的函数,下方都是它的父函数。
    轴表示抽样数,如果一个函数在 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火焰图:

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

    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:

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

    9.5 内存级别火焰图

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

    使用方式:

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

    官网DEMO:

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

    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红蓝差分火焰图:

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

    10. 事例分析

    10.1 nginx クラスターのアクセス層の異常

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

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

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

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

    結論:

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

    ###

    b) #nginx 応答時間の分析
    Linuxの運用とメンテナンスのトラブルシューティングのアイデア、この記事で十分です~

    結論:

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

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

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

    ##結論:

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

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

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

    トップ

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

    #結論:

    #nginx ワーカーの CPU が比較的高いことがわかります

    b)

    ##nginx プロセスの内部 CPU 状況を分析する

    perf top -p pid

    <p style="outline: 0px;caret-color: rgb(34, 34, 34);color: rgb(34, 34, 34);letter-spacing: 0.544px;white-space: normal;text-size-adjust: auto;font-family: -apple-system-font, BlinkMacSystemFont, " helvetica neue sc sans gb yahei ui arial sans-serif rgb><span style="outline: 0px;font-size: 15px;">结论:</span></p> <p style="outline: 0px;caret-color: rgb(34, 34, 34);color: rgb(34, 34, 34);letter-spacing: 0.544px;white-space: normal;text-size-adjust: auto;font-family: -apple-system-font, BlinkMacSystemFont, " helvetica neue sc sans gb yahei ui arial sans-serif rgb><span style="outline: 0px;font-size: 15px;">发现主要开销在free,malloc,json解析上面</span></p> <p style="outline: 0px;caret-color: rgb(34, 34, 34);color: rgb(34, 34, 34);letter-spacing: 0.544px;white-space: normal;text-size-adjust: auto;font-family: -apple-system-font, BlinkMacSystemFont, " helvetica neue sc sans gb yahei ui arial sans-serif rgb><span style="outline: 0px;font-size: 15px;">10.4 火焰图分析cpu<br style="outline: 0px;">a) <em style="outline: 0px;">**</em>生成用户态cpu火焰图</span></p> <section class="code-snippet__fix code-snippet__js"><pre class='brush:php;toolbar:false;'>//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</pre></section><p style="outline: 0px;caret-color: rgb(34, 34, 34);color: rgb(34, 34, 34);letter-spacing: 0.544px;white-space: normal;text-size-adjust: auto;font-family: -apple-system-font, BlinkMacSystemFont, " helvetica neue sc sans gb yahei ui arial sans-serif rgb center><img src="/static/imghwm/default1.png" data-src="https://img.php.cn/upload/article/001/275/013/773360b92e15f55feee12c3ea49ff2be-14.jpg?x-oss-process=image/resize,p_40" class="lazy" alt="Linuxの運用とメンテナンスのトラブルシューティングのアイデア、この記事で十分です~" ></p> <p style="margin-bottom: 0px;outline: 0px;caret-color: rgb(34, 34, 34);color: rgb(34, 34, 34);letter-spacing: 0.544px;white-space: normal;text-size-adjust: auto;font-family: -apple-system-font, BlinkMacSystemFont, " helvetica neue sc sans gb yahei ui arial sans-serif rgb><span style="outline: 0px;color: rgb(68, 68, 68);font-size: 15px;"><strong style="outline: 0px;">结论:</strong></span></p> <p style="margin-bottom: 0px;outline: 0px;caret-color: rgb(34, 34, 34);color: rgb(34, 34, 34);letter-spacing: 0.544px;white-space: normal;text-size-adjust: auto;font-family: -apple-system-font, BlinkMacSystemFont, " helvetica neue sc sans gb yahei ui arial sans-serif rgb><span style="outline: 0px;font-size: 15px;color: rgb(68, 68, 68);">发现代码里面有频繁的解析json操作,并且发现这个json库性能不高,占用cpu挺高。</span></p> <h3 id="span-style-outline-px-color-rgb-案例总结-span"><span style="outline: 0px;color: rgb(68, 68, 68);">10.5 案例总结</span></h3> <p style="outline: 0px;caret-color: rgb(34, 34, 34);color: rgb(34, 34, 34);letter-spacing: 0.544px;white-space: normal;text-size-adjust: auto;font-family: -apple-system-font, BlinkMacSystemFont, " helvetica neue sc sans gb yahei ui arial sans-serif rgb><span style="outline: 0px;font-size: 15px;color: rgb(68, 68, 68);"><strong style="outline: 0px;">a) </strong>分析请求流量异常,得出nginx upstream后端机器响应时间拉长</span></p> <p style="outline: 0px;caret-color: rgb(34, 34, 34);color: rgb(34, 34, 34);letter-spacing: 0.544px;white-space: normal;text-size-adjust: auto;font-family: -apple-system-font, BlinkMacSystemFont, " helvetica neue sc sans gb yahei ui arial sans-serif rgb><span style="outline: 0px;font-size: 15px;color: rgb(68, 68, 68);"><strong style="outline: 0px;">b) </strong>nginx プロセスの高 CPU を分析した結果、nginx の内部モジュール コードには時間のかかる json 解析、メモリ割り当て、リサイクル操作が含まれていると結論づけられました</span></p> <h4 id="span-style-outline-px-color-rgb-詳細な分析-span"><span style="outline: 0px;color: rgb(68, 68, 68);">10.5 .1 詳細な分析</span></h4> <p style="outline: 0px;caret-color: rgb(34, 34, 34);color: rgb(34, 34, 34);letter-spacing: 0.544px;white-space: normal;text-size-adjust: auto;font-family: -apple-system-font, BlinkMacSystemFont, " helvetica neue sc sans gb yahei ui arial sans-serif rgb><span style="outline: 0px;font-size: 15px;color: rgb(68, 68, 68);">上記 2 点の分析の結論に基づいて、さらに詳細な分析を行っていきます。 </span></p> <p style="outline: 0px;caret-color: rgb(34, 34, 34);color: rgb(34, 34, 34);letter-spacing: 0.544px;white-space: normal;text-size-adjust: auto;font-family: -apple-system-font, BlinkMacSystemFont, " helvetica neue sc sans gb yahei ui arial sans-serif rgb><span style="outline: 0px;font-size: 15px;color: rgb(68, 68, 68);">バックエンドのアップストリーム応答が長くなり、最大で nginx の処理能力に影響を与える可能性があります。ただし、CPU オペレーションを過剰に消費する nginx 内部モジュールに影響を与える可能性は低いです。そして、当時多くの CPU を占有していたモジュールは、要求された場合にのみ実行されました。アップストリーム バックエンドが nginx を抑制し、それによってこの時間のかかる CPU 操作がトリガーされる可能性は低いです。 </span></p> <h3 id="span-style-outline-px-color-rgb-解決策-span"><span style="outline: 0px;color: rgb(68, 68, 68);">10.5.2 解決策</span></h3> <p style="outline: 0px;caret-color: rgb(34, 34, 34);color: rgb(34, 34, 34);letter-spacing: 0.544px;white-space: normal;text-size-adjust: auto;font-family: -apple-system-font, BlinkMacSystemFont, " helvetica neue sc sans gb yahei ui arial sans-serif rgb><span style="outline: 0px;font-size: 15px;color: rgb(68, 68, 68);">この種の問題が発生した場合、既知の明確な問題を解決することを優先します。それがCPUの性能が高い場合の問題です。解決策は、CPU を過剰に消費するモジュールをダウングレードして閉じてから観察することです。モジュールをダウングレードしてシャットダウンした後、CPU が低下し、nginx リクエストのトラフィックが正常になりました。上り時間が長くなる理由は、上りバックエンドサービスから呼び出されるインターフェースがループとなり、再度nginxに戻る可能性があるためです。 </span></p> <h2 id="参考資料">11.参考資料</h2> <ul class="list-paddingleft-1" style="outline: 0px;caret-color: rgb(34, 34, 34);color: rgb(34, 34, 34);letter-spacing: 0.544px;white-space: normal;text-size-adjust: auto;width: 577.417px;font-family: -apple-system-font, BlinkMacSystemFont, " helvetica neue sc sans gb yahei ui arial sans-serif rgb> <li style="outline: 0px;font-size: 15px;"><p style="outline: 0px;"><span style="outline: 0px;">http://www.brendangregg.com/index.html</span></p></li> <li style="outline: 0px;font-size: 15px;"><p style="outline: 0px;"> <span style="outline: 0px;">http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html</span></p></li> <li style="outline: 0px;font-size: 15px;"><p style="outline: 0px;"><span style="outline: 0px;">http://www.brendangregg.com/FlameGraphs/memoryflamegraphs。 html</span></p></li> <li style="outline: 0px;font-size: 15px;"><p style="outline: 0px;"><span style="outline: 0px;">http://www.brendangregg.com/FlameGraphs/offcpuflamegraphs.html</span></p></li> <li style="outline: 0px;font-size: 15px;"><p style="outline: 0px;"><span style="outline: 0px;"> ##http://www.brendangregg.com/blog/2014-11-09/fferential-flame-graphs.html</span></p></li> <li style="outline: 0px;font-size: 15px;"><p style="outline: 0px;"><span style="outline: 0px;">https://github .com/openresty/openresty-systemtap-toolkit</span></p></li> <li style="outline: 0px;font-size: 15px;"><p style="outline: 0px;"><span style="outline: 0px;">https://github.com/brendangregg/FlameGraph</span></p></li> <li style="outline: 0px;font-size: 15px;"><section style="margin-bottom: 10px;outline: 0px;"><span style="outline: 0px;">https://www.slideshare.net/brendangregg/blazing-performance-with-flame-graphs</span></section></li> </ul> <p style="display: none;"><mp-style-type data-value="10000"></mp-style-type> </p>##

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

声明
この記事はLinux中文社区で複製されています。侵害がある場合は、admin@php.cn までご連絡ください。
Linuxの重要なコンポーネント:初心者向けに説明されていますLinuxの重要なコンポーネント:初心者向けに説明されていますApr 17, 2025 am 12:08 AM

Linuxのコアコ​​ンポーネントには、カーネル、ファイルシステム、シェル、および共通ツールが含まれます。 1.カーネルはハードウェアリソースを管理し、基本的なサービスを提供します。 2。ファイルシステムはデータを整理して保存します。 3.シェルは、ユーザーがシステムと対話するインターフェイスです。 4.一般的なツールは、毎日のタスクを完了するのに役立ちます。

Linux:その基本構造を見てくださいLinux:その基本構造を見てくださいApr 16, 2025 am 12:01 AM

Linuxの基本構造には、カーネル、ファイルシステム、およびシェルが含まれます。 1)カーネル管理ハードウェアリソースとUname-Rを使用してバージョンを表示します。 2)ext4ファイルシステムは、大きなファイルとログをサポートし、mkfs.ext4を使用して作成されます。 3)シェルは、BASHなどのコマンドラインインタラクションを提供し、LS-Lを使用してファイルをリストします。

Linux操作:システム管理とメンテナンスLinux操作:システム管理とメンテナンスApr 15, 2025 am 12:10 AM

Linuxシステムの管理とメンテナンスの重要な手順には、次のものがあります。1)ファイルシステム構造やユーザー管理などの基本的な知識をマスターします。 2)システムの監視とリソース管理を実行し、TOP、HTOP、その他のツールを使用します。 3)システムログを使用してトラブルシューティング、JournalCtlおよびその他のツールを使用します。 4)自動化されたスクリプトとタスクのスケジューリングを作成し、Cronツールを使用します。 5)セキュリティ管理と保護を実装し、iPtablesを介してファイアウォールを構成します。 6)パフォーマンスの最適化とベストプラクティスを実行し、カーネルパラメーターを調整し、良い習慣を開発します。

Linuxのメンテナンスモードの理解:必需品Linuxのメンテナンスモードの理解:必需品Apr 14, 2025 am 12:04 AM

Linuxメンテナンスモードは、起動時にinit =/bin/bashまたは単一パラメーターを追加することにより入力されます。 1.メンテナンスモードの入力:GRUBメニューを編集し、起動パラメーターを追加します。 2。ファイルシステムを読み取りおよび書き込みモードに再マウントします:Mount-Oremount、RW/。 3。ファイルシステムの修復:FSCK/dev/sda1などのFSCKコマンドを使用します。 4.データをバックアップし、データの損失を避けるために慎重に動作します。

DebianがHadoopデータ処理速度を改善する方法DebianがHadoopデータ処理速度を改善する方法Apr 13, 2025 am 11:54 AM

この記事では、DebianシステムのHadoopデータ処理効率を改善する方法について説明します。最適化戦略では、ハードウェアのアップグレード、オペレーティングシステムパラメーターの調整、Hadoop構成の変更、および効率的なアルゴリズムとツールの使用をカバーしています。 1.ハードウェアリソースの強化により、すべてのノードが一貫したハードウェア構成、特にCPU、メモリ、ネットワーク機器のパフォーマンスに注意を払うことが保証されます。高性能ハードウェアコンポーネントを選択することは、全体的な処理速度を改善するために不可欠です。 2。オペレーティングシステムチューニングファイル記述子とネットワーク接続:/etc/security/limits.confファイルを変更して、システムによって同時に開くことができるファイル記述子とネットワーク接続の上限を増やします。 JVMパラメーター調整:Hadoop-env.shファイルで調整します

Debian syslogを学ぶ方法Debian syslogを学ぶ方法Apr 13, 2025 am 11:51 AM

このガイドでは、Debian SystemsでSyslogの使用方法を学ぶように導きます。 Syslogは、ロギングシステムとアプリケーションログメッセージのLinuxシステムの重要なサービスです。管理者がシステムアクティビティを監視および分析して、問題を迅速に特定および解決するのに役立ちます。 1. syslogの基本的な知識Syslogのコア関数には以下が含まれます。複数のログ出力形式とターゲットの場所(ファイルやネットワークなど)をサポートします。リアルタイムのログ表示およびフィルタリング機能を提供します。 2。syslog(rsyslogを使用)をインストールして構成するDebianシステムは、デフォルトでrsyslogを使用します。次のコマンドでインストールできます:sudoaptupdatesud

DebianでHadoopバージョンを選択する方法DebianでHadoopバージョンを選択する方法Apr 13, 2025 am 11:48 AM

Debianシステムに適したHadoopバージョンを選択する場合、次の重要な要因を考慮する必要があります。1。安定性と長期的なサポート:安定性とセキュリティを追求するユーザーにとって、Debian11(Bullseye)などのDebianの安定したバージョンを選択することをお勧めします。このバージョンは完全にテストされており、最大5年のサポートサイクルがあり、システムの安定した動作を確保できます。 2。パッケージの更新速度:最新のHadoop機能と機能を使用する必要がある場合は、DebianのUnstableバージョン(SID)を検討できます。ただし、不安定なバージョンには互換性の問題と安定性のリスクがあることに注意する必要があります。 3。コミュニティのサポートとリソース:Debianには、豊富なドキュメントを提供できるコミュニティサポートが大きくなり、

debianのtigervnc共有ファイルメソッドdebianのtigervnc共有ファイルメソッドApr 13, 2025 am 11:45 AM

この記事では、Tigervncを使用してDebian Systemsでファイルを共有する方法について説明します。最初にtigervncサーバーをインストールしてから構成する必要があります。 1. TigerVNCサーバーをインストールし、端末を開きます。ソフトウェアパッケージリストの更新リスト:sudoaptupdate tigervnc server:sudoaptinstaltaltigervnc-standalone-servertigervnc-common2。tigervncサーバーを構成するVNCサーバーパスワードを設定します。

See all articles

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

AtomエディタMac版ダウンロード

AtomエディタMac版ダウンロード

最も人気のあるオープンソースエディター

PhpStorm Mac バージョン

PhpStorm Mac バージョン

最新(2018.2.1)のプロフェッショナル向けPHP統合開発ツール

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

WebStorm Mac版

WebStorm Mac版

便利なJavaScript開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)