线程CPU异常定位分析

简介: 【10月更文挑战第3天】开发过程中会出现一些CPU异常升高的问题,想要定位到具体的位置就需要一系列的分析,记录一些分析手段。

CPU异常定位手段

  • 获取线程cpu占用

    top 获取pid为18234进程的线程cpu占用,其pid为374037

    [root@ceph ~]# top -H -p 18234 -n 1
    top - 10:20:42 up 8 days,  1:08,  1 user,  load average: 13.09, 13.17, 12.68
    Threads: 10742 total,   1 running, 10741 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  5.3 us,  8.0 sy,  0.0 ni, 84.0 id,  1.8 wa,  0.0 hi,  0.8 si,  0.0 st
    KiB Mem : 19752244+total, 16810388 free, 12193627+used, 58775792 buff/cache
    KiB Swap:        0 total,        0 free,        0 used. 74628448 avail Mem
    
        PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
     374037 ceph      20   0   13.9g   1.5g   8484 R 96.8  0.8   2431:07 ms_pipe_read
      18236 ceph      20   0   13.9g   1.5g   8484 S  3.2  0.8 183:29.12 log
      22685 ceph      20   0   13.9g   1.5g   8484 S  3.2  0.8  48:15.72 journal_wrt_fin
      28838 ceph      20   0   13.9g   1.5g   8484 S  3.2  0.8  62:48.29 tp_osd_tp
     789508 ceph      20   0   13.9g   1.5g   8484 S  3.2  0.8   0:02.36 ms_pipe_write
      18234 ceph      20   0   13.9g   1.5g   8484 S  0.0  0.8   0:10.38 ceph-osd
      18238 ceph      20   0   13.9g   1.5g   8484 S  0.0  0.8   0:02.04 service
      18239 ceph      20   0   13.9g   1.5g   8484 S  0.0  0.8   0:00.03 admin_socket
      18240 ceph      20   0   13.9g   1.5g   8484 S  0.0  0.8   0:02.68 ceph-osd
      18241 ceph      20   0   13.9g   1.5g   8484 S  0.0  0.8   4:18.44 ms_reaper
      18242 ceph      20   0   13.9g   1.5g   8484 S  0.0  0.8   0:00.01 ms_reaper
      18243 ceph      20   0   13.9g   1.5g   8484 S  0.0  0.8   0:00.01 ms_reaper
      18244 ceph      20   0   13.9g   1.5g   8484 S  0.0  0.8   0:00.01 ms_reaper
      18245 ceph      20   0   13.9g   1.5g   8484 S  0.0  0.8   0:00.04 ms_reaper
      18246 ceph      20   0   13.9g   1.5g   8484 S  0.0  0.8   0:00.00 ms_reaper
      18247 ceph      20   0   13.9g   1.5g   8484 S  0.0  0.8   0:26.90 safe_timer
      18248 ceph      20   0   13.9g   1.5g   8484 S  0.0  0.8  12:45.89 safe_timer
      18249 ceph      20   0   13.9g   1.5g   8484 S  0.0  0.8   0:00.00 safe_timer
    

    ps获取18234线程的cpu使用率排序

    [root@ceph ~]# ps -p 18234 -Lo pid,%cpu,command | sort -r -k 1| head
        PID %CPU COMMAND
      18234 99.7 /usr/bin/ceph-osd -f --cluster ceph --id 48 --setuser ceph --setgroup ceph
      18234  1.5 /usr/bin/ceph-osd -f --cluster ceph --id 48 --setuser ceph --setgroup ceph
      18234  1.1 /usr/bin/ceph-osd -f --cluster ceph --id 48 --setuser ceph --setgroup ceph
      18234  1.1 /usr/bin/ceph-osd -f --cluster ceph --id 48 --setuser ceph --setgroup ceph
      18234  0.6 /usr/bin/ceph-osd -f --cluster ceph --id 48 --setuser ceph --setgroup ceph
      18234  0.6 /usr/bin/ceph-osd -f --cluster ceph --id 48 --setuser ceph --setgroup ceph
      18234  0.6 /usr/bin/ceph-osd -f --cluster ceph --id 48 --setuser ceph --setgroup ceph
      18234  0.6 /usr/bin/ceph-osd -f --cluster ceph --id 48 --setuser ceph --setgroup ceph
      18234  0.5 /usr/bin/ceph-osd -f --cluster ceph --id 48 --setuser ceph --setgroup ceph
    

    获取cpu排序的进程,-o为排序,-b为特定输出,-c为输出command,-U过滤用户

    [root@ceph ~]# top -o +%CPU -bn 1 -U ceph -c
    top - 14:07:29 up 8 days,  4:55,  2 users,  load average: 9.89, 10.91, 10.78
    Tasks: 925 total,   7 running, 918 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  5.6 us, 10.2 sy,  0.0 ni, 80.7 id,  2.5 wa,  0.0 hi,  0.9 si,  0.0 st
    KiB Mem : 19752244+total, 14998000 free, 12188595+used, 60638496 buff/cache
    KiB Swap:        0 total,        0 free,        0 used. 74681224 avail Mem
    
        PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
      18234 ceph      20   0   14.2g   1.5g   7180 S 123.7  0.8   5066:26 /usr/bin/ceph-osd -f --cluster ceph --id 48 --setuser ceph --setgroup ceph
      17749 ceph      20   0   14.8g   1.4g  12868 S  31.3  0.7   1599:14 /usr/bin/ceph-osd -f --cluster ceph --id 53 --setuser ceph --setgroup ceph
      40350 ceph      20   0   16.2g   1.6g   6880 S  31.3  0.9   2030:31 /usr/bin/ceph-osd -f --cluster ceph --id 42 --setuser ceph --setgroup ceph
      44611 ceph      20   0   16.1g   1.7g   7248 S  28.2  0.9   2264:00 /usr/bin/ceph-osd -f --cluster ceph --id 39 --setuser ceph --setgroup ceph
      12407 ceph      20   0   16.2g   1.6g   7792 S  25.2  0.8   1941:31 /usr/bin/ceph-osd -f --cluster ceph --id 40 --setuser ceph --setgroup ceph
      12652 ceph      20   0   16.6g   1.7g   7764 S  25.2  0.9   2218:45 /usr/bin/ceph-osd -f --cluster ceph --id 47 --setuser ceph --setgroup ceph
      18010 ceph      20   0   15.8g   1.6g   7120 S  25.2  0.8   1972:40 /usr/bin/ceph-osd -f --cluster ceph --id 45 --setuser ceph --setgroup ceph
      42458 ceph      20   0   16.7g   1.7g   7744 S  23.7  0.9   2448:25 /usr/bin/ceph-osd -f --cluster ceph --id 37 --setuser ceph --setgroup ceph
      37105 ceph      20   0   16.4g   1.7g   7660 S  22.9  0.9   2367:21 /usr/bin/ceph-osd -f --cluster ceph --id 43 --setuser ceph --setgroup ceph
      20591 ceph      20   0   16.8g   1.8g   7272 S  22.1  1.0   2387:48 /usr/bin/ceph-osd -f --cluster ceph --id 46 --setuser ceph --setgroup ceph
      13612 ceph      20   0   16.5g   1.6g   7632 S  19.8  0.9   2104:41 /usr/bin/ceph-osd -f --cluster ceph --id 49 --setuser ceph --setgroup ceph
      34286 ceph      20   0 8933948   1.3g   6464 S  18.3  0.7   1716:12 /usr/bin/ceph-osd -f --cluster ceph --id 41 --setuser ceph --setgroup ceph
      36056 ceph      20   0   16.4g   1.6g   7792 S  17.6  0.8   1899:13 /usr/bin/ceph-osd -f --cluster ceph --id 52 --setuser ceph --setgroup ceph
      20992 ceph      20   0 9320296   1.1g   6040 S  16.8  0.6   1573:35 /usr/bin/ceph-osd -f --cluster ceph --id 36 --setuser ceph --setgroup ceph
      20124 ceph      20   0   16.2g   1.5g   5852 S  16.0  0.8   1612:22 /usr/bin/ceph-osd -f --cluster ceph --id 38 --setuser ceph --setgroup ceph
      33121 ceph      20   0   15.6g   1.5g   6200 S  16.0  0.8   1687:48 /usr/bin/ceph-osd -f --cluster ceph --id 51 --setuser ceph --setgroup ceph
      17547 ceph      20   0   16.2g   1.5g   7172 S  15.3  0.8   1906:07 /usr/bin/ceph-osd -f --cluster ceph --id 44 --setuser ceph --setgroup ceph
       5898 ceph      20   0   10.0g 772900  80752 S  13.7  0.4   2102:06 /usr/bin/ceph-mon -f --cluster ceph --id ceph --setuser ceph --setgroup ceph
      46355 ceph      20   0 9500172   1.1g   7512 S  11.5  0.6   1573:49 /usr/bin/ceph-osd -f --cluster ceph --id 50 --setuser ceph --setgroup ceph
       5895 ceph      20   0  560660 239940   2688 S   0.0  0.1   0:58.61 /usr/bin/ceph-mds -f --cluster ceph --id ceph --setuser ceph --setgroup ceph
    

    获取cpu大于100的进程

    top -o +%CPU -bn 1 -U ceph -c | sed -n '8,$p' | awk '$9>100{print $0}'
     18234 ceph      20   0   14.3g   1.6g   7056 S 150.0  0.8   5139:56 /usr/bin/ceph-osd -f --cluster ceph --id 48 --setuser ceph --setgroup ceph
    
  • 使用pstack获取进程调用栈,并查找374037所在线程

    pstack 18234 > osd_48.pstack
    
    Thread 9079 (Thread 0x7f5294d19700 (LWP 374037)):
    #0  0x00007f55c0458aab in recv () from /lib64/libpthread.so.0
    #1  0x00005648458a057d in Pipe::do_recv(char*, unsigned long, int) ()
    #2  0x00005648458a0937 in Pipe::buffered_recv(char*, unsigned long, int) ()
    #3  0x00005648458a0a33 in Pipe::tcp_read_nonblocking(char*, unsigned int) ()
    #4  0x00005648458a0d0d in Pipe::tcp_read(char*, unsigned int) ()
    #5  0x00005648458ab058 in Pipe::accept() ()
    #6  0x00005648458b22ff in Pipe::reader() ()
    #7  0x00005648458baf1d in Pipe::Reader::entry() ()
    #8  0x00007f55c0451e65 in start_thread () from /lib64/libpthread.so.0
    #9  0x00007f55bead688d in clone () from /lib64/libc.so.6
    
相关文章
|
2月前
|
存储 NoSQL Redis
Redis 新版本引入多线程的利弊分析
【10月更文挑战第16天】Redis 新版本引入多线程是一个具有挑战性和机遇的改变。虽然多线程带来了一些潜在的问题和挑战,但也为 Redis 提供了进一步提升性能和扩展能力的可能性。在实际应用中,我们需要根据具体的需求和场景,综合评估多线程的利弊,谨慎地选择和使用 Redis 的新版本。同时,Redis 开发者也需要不断努力,优化和完善多线程机制,以提供更加稳定、高效和可靠的 Redis 服务。
65 1
|
2月前
|
消息中间件 Java 应用服务中间件
我是如何通过火焰图分析让应用CPU占用下降近20%的
分享作者在使用Arthas火焰图工具进行Java应用性能分析和优化的经验。
|
1月前
|
存储 缓存 算法
面试官:单核 CPU 支持 Java 多线程吗?为什么?被问懵了!
本文介绍了多线程环境下的几个关键概念,包括时间片、超线程、上下文切换及其影响因素,以及线程调度的两种方式——抢占式调度和协同式调度。文章还讨论了减少上下文切换次数以提高多线程程序效率的方法,如无锁并发编程、使用CAS算法等,并提出了合理的线程数量配置策略,以平衡CPU利用率和线程切换开销。
面试官:单核 CPU 支持 Java 多线程吗?为什么?被问懵了!
|
24天前
|
调度 开发者
核心概念解析:进程与线程的对比分析
在操作系统和计算机编程领域,进程和线程是两个基本而核心的概念。它们是程序执行和资源管理的基础,但它们之间存在显著的差异。本文将深入探讨进程与线程的区别,并分析它们在现代软件开发中的应用和重要性。
42 4
|
1月前
|
Java
.如何根据 CPU 核心数设计线程池线程数量
IO 密集型:核心数*2 计算密集型: 核心数+1 为什么加 1?即使当计算密集型的线程偶尔由于缺失故障或者其他原因而暂停时,这个额外的线程也能确保 CPU 的时钟周期不会被浪费。
47 4
|
2月前
|
监控 Java
在实际应用中选择线程异常捕获方法的考量
【10月更文挑战第15天】选择最适合的线程异常捕获方法需要综合考虑多种因素。没有一种方法是绝对最优的,需要根据具体情况进行权衡和选择。在实际应用中,还需要不断地实践和总结经验,以提高异常处理的效果和程序的稳定性。
30 3
|
2月前
|
监控 Java
捕获线程执行异常的多种方法
【10月更文挑战第15天】捕获线程执行异常的方法多种多样,每种方法都有其特点和适用场景。在实际开发中,需要根据具体情况选择合适的方法或结合多种方法来实现全面有效的线程异常捕获。这有助于提高程序的健壮性和稳定性,减少因线程异常带来的潜在风险。
31 1
|
2月前
|
监控 API
Hook 线程与捕获线程执行异常
【10月更文挑战第11天】Hook 线程和捕获线程执行异常是多线程编程中不可或缺的技术。通过深入理解和掌握这些方法,我们可以提高程序的稳定性和可靠性,更好地应对各种异常情况。同时,在实际应用中要注意平衡性能和准确性,制定合理的异常处理策略,以确保程序的正常运行。
38 1
|
2月前
|
Java
Java面试题之cpu占用率100%,进行定位和解决
这篇文章介绍了如何定位和解决Java服务中CPU占用率过高的问题,包括使用top命令找到高CPU占用的进程和线程,以及使用jstack工具获取堆栈信息来确定问题代码位置的步骤。
157 0
Java面试题之cpu占用率100%,进行定位和解决
|
25天前
|
存储 缓存 监控
Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
本文介绍了Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
64 7