概览
    文章
    评论
    关注
    评论于：『5、案例篇：系统的 CPU 使用率很高，但为啥却找不到高 CPU 的应用？』

    分析步骤： 1，在top中，可见用户态cpu使用率很高，但未见相关有问题的进程； 2，尝试pidstat 1 找出问题进程，无果； 3，再次top,从load average 可见负载高，shift + f ，然后选择以s (进程状态）排序，按R倒序，可见running的进程主要就是几个stress进程，观察发现，running的stress进程的pid一直在变化； 4，watch -d 'ps aux | grep stress | grep -v grep' 发现多个stress进程在不断生成，由R变S再变Z（由于watch的时间间隔是1秒，所以只是看到有多个stress进程，有的状态是R有的是S有的是Z，所以我推断其生命周期是如此） 5，进程Pid再不断变化，有以下两个原因： 5.1，进程在不断崩溃重启，如因为段错误，配置错误等，这时进程在退出后又被监控系统自动重启 5.2，这些都是短进程，即在应用内部通过exec调用外部命令。这些命令一般只运行很短的时间就会结束，很难用时间间隔长的工具，如top去发现 6，用pstress去找其父进程 7，发现是php容器，故查看php源码 # 拷贝源码到本地 $ docker cp phpfpm:/app . # grep 查找看看是不是有代码在调用 stress 命令 $ grep stress -r app 8，从源代码中找相关字段 9，stress -t 1 -d 1 是模拟IO压力的，但在之前的top中，未见%iowait异常； 10，通过代码中的判断字段，手动赋值访问 curl http://192.168.0.10:10000?verbose=1 Server internal error: Array ( [0] => stress: info: [19607] dispatching hogs: 0 cpu, 0 io, 0 vm, 1 hdd [1] => stress: FAIL: [19608] (563) mkstemp failed: Permission denied [2] => stress: FAIL: [19607] (394) <-- worker 19608 returned error 1 [3] => stress: WARN: [19607] (396) now reaping child worker processes [4] => stress: FAIL: [19607] (400) kill error: No such process [5] => stress: FAIL: [19607] (451) failed run completed in 0s ) 11，从这里可以猜测，由于权限错误，大量的stress进程在启动时初始化失败，结合第4点，我认为CPU消耗在进程上下文切换，从vmstat可见cs由问题出现前的100多骤升并稳定维持在3000多 [root@master ~]# vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 9 0 0 6932288 2160 790400 0 0 20 24 44 71 8 5 87 0 0 8 0 0 6932784 2160 790560 0 0 0 0 4027 3512 71 27 3 0 0 11 0 0 6934920 2160 790488 0 0 0 0 4170 3646 72 28 1 0 0 但pidstat -w |grep stress 却未见异常，因为同名进程一直在更换，所以用pidstat -w在这里是不太适用的 [root@master ~]# pidstat -w 2 | grep stress 09:55:29 AM 1 18583 0.50 0.50 stress 09:55:29 AM 1 18584 0.50 0.50 stress 09:55:29 AM 1 18586 0.50 0.00 stress

    • 橙子柠檬
      • 9月前
    去看看
    评论于：『5、案例篇：系统的 CPU 使用率很高，但为啥却找不到高 CPU 的应用？』

    关于使用perf工具分析docker容器共用3种可行的办法，详见：https://www.cnblogs.com/luoahong/p/10833689.html #下载execsnoop# cd /usr/bin wget https://raw.githubusercontent.com/brendangregg/perf-tools/master/execsnoop chmod 755 execsnoop

    • 橙子柠檬
      • 9月前
    去看看
    评论于：『4、基础篇：Linux应用CPU使用率100%，该如何处理？』

    ✨TOP命令解释： 第三行cpu使用率解释： √ us: user（通常缩写为 us），代表用户态 CPU 时间。注意，它不包括下面的 nice 时间，但包括了 guest 时间。 √ ni: nice（通常缩写为 ni），代表低优先级用户态 CPU 时间，也就是进程的 nice 值被调整为 1-19 之间时的 CPU 时间。这里注意，nice 可取值范围是 -20 到 19，数值越大，优先级反而越低。 √ sy: system（通常缩写为 sys），代表内核态 CPU 时间。 √ di: idle（通常缩写为 id），代表空闲时间。注意，它不包括等待 I/O 的时间（iowait）。 √ wa: iowait（通常缩写为 wa），代表等待 I/O 的 CPU 时间。 √ hi: irq（通常缩写为 hi），代表处理硬中断的 CPU 时间。 √ si: softirq（通常缩写为 si），代表处理软中断的 CPU 时间。 √ st: steal（通常缩写为 st），代表当系统运行在虚拟机中的时候，被其他虚拟机占用的 CPU 时间。 √ guest: guest（通常缩写为 guest），代表通过虚拟化运行其他操作系统的时间，也就是运行虚拟机的 CPU 时间。 √ gnice: guest_nice（通常缩写为 gnice），代表以低优先级运行虚拟机的时间。 ✨ top 默认显示的是所有 CPU 的平均值，这个时候你只需要按下数字 1 ，就可以切换到每个 CPU 的使用率了。 ✨ top命令所有进程的实时统计信息： 其中的%CPU，表示进程的 CPU 使用率。它是用户态和内核态 CPU 使用率的总和，包括： ※ 进程用户空间使用的CPU ※ 通过系统调用执行的内核空间CPU ※ 以及在就绪队列等待运行的CPU ※ 在虚拟化环境中，它还包括了运行虚拟机占用的CPU ✨pidstat分析进程cpu详细使用情况 top 并没有细分进程的用户态 CPU 和内核态 CPU，使用pidstat可以分析每个进程 CPU 详细使用情况。 ※ 用户态 CPU 使用率 （%usr）； ※ 内核态 CPU 使用率（%system）； ※ 运行虚拟机 CPU 使用率（%guest）； ※ 等待 CPU 使用率（%wait）； ※ 以及总的 CPU 使用率（%CPU） ✨占用 CPU 的到底是代码里的哪个函数 办法一： GDB 调试程序的过程会中断程序运行，这在线上环境往往是不允许的。 所以，GDB 只适合用在性能分析的后期，当你找到了出问题的大致函数后，线下再借助它来进一步调试函数内部的问题。 办法二：通过perf第一时间分析进程CPU问题。 perf 是 Linux2.6.31以后内置的性能分析工具。它以性能事件采样为基础，不仅可以分析系统的各种事件和内核性能， 还可以用来分析指定应用程序的性能问题。 ① 第一种常见用法是 perf top，类似于 top，它能够实时显示占用 CPU 时钟最多的函数或者指令，因此可以用来查找热点函数。 * Samples：采样数 * event：事件类型 * Event count：事件总数量 表格解释： * 第一列 Overhead ，是该符号的性能事件在所有采样中的比例，用百分比来表示。 * 第二列 Shared ，是该函数或指令所在的动态共享对象（Dynamic Shared Object），如内核、进程名、动态链接库名、内核模块名等。 * 第三列 Object ，是动态共享对象的类型。比如 [.] 表示用户空间的可执行程序、或者动态链接库，而 [k] 则表示内核空间。 * 第四列 Symbol 是符号名，也就是函数名。当函数名未知时，用十六进制的地址来表示。 perf top 缺点： 虽然实时展示了系统的性能信息，但它的缺点是并不保存数据，也就无法用于离线或者后续的分析 ② 第二种用法是：perf record 则提供了保存数据的功能，保存后的数据，需要你用 perf report 解析展示，perf record执行后，可以在当前目录下生成：perf.data 然后使用perf report直接执行生成跟perf top一样的报告。 ⭕️ perf top调用关系分析 # -g开启调用关系分析，-p指定php-fpm的进程号21515 $ perf top -g -p 21515 可以查看到进程中具体的函数调用关系来帮助排查问题。 ✨ ab工具使用方式 ab（apache bench）是一个常用的 HTTP 服务性能测试工具 # 并发10个请求测试Nginx性能，总共测试100个请求 $ ab -c 10 -n 100 http://localhost:10000/

    • 橙子柠檬
      • 9月前
    去看看
    评论于：『4、基础篇：Linux应用CPU使用率100%，该如何处理？』

    课代表的笔记：https://www.zybuluo.com/Gugoole/note/1354842

    • 橙子柠檬
      • 9月前
    去看看
    加载更多
    没有更多内容了
    繁
    • 复制图片
    • 复制图片地址
    按住ctrl可打开默认菜单
    音乐已暂停
    首页 搜索 菜单
    繁 体 顶部
    • 波浪 波浪
    • 波浪 波浪
    • 波浪 波浪
    • 波浪 波浪

    本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、违规、不妥请联系本站删除，文章中出现的商标及图像版权属于其合法持有人，只供传递信息之用，非商务用途。

    Copyright © 2023  橙子柠檬s' Blog 版权所有 | 自豪的采用 emlog pro 2.2.5 驱动 | 主题：Cherish V1.7.0 | 勉强运行： 近8年 |   桂ICP备16010384号-1 桂ICP备16010384号-1