首页 » ORACLE, 系统相关 » 如何在 Linux 上诊断高 Sys CPU

如何在 Linux 上诊断高 Sys CPU

Linux中CPU负载高必须引起关注,通常需要先查看CPU使用类型,CPU使用分为us(用户进程)还是sy(内核调用), sys通常不应该超过user , 数据库专用主机主要来自用户级的 CPU 时间(无论是“user”还是“nice”)。因此,当 CPU 时间的大部分时间花在内核(sys)中时,这表明出现了问题, %sys一般也不超过10%, 但是%sys超高这样的问题遇到好多次,原因有:NFS4 bug、 swap IO、安装了linux杀毒如卡巴斯基、3rd party modules、NUMA、cpu 中断、内核参数配置错误等,查看方法如TOP

top - 15:06:12 up 100 days, 19:37, 28 users,  load average: 142.57, 143.03, 126.
Tasks: 10637 total, 106 running, 10531 sleeping,   0 stopped,   0 zombie
%Cpu(s): 17.7 us, 39.4 sy,  0.0 ni, 40.9 id,  1.0 wa,  0.0 hi,  1.0 si,  0.0 st
 
KiB Mem : 10561102+total, 18588532 free, 69364883+used, 34387289+buff/cache
KiB Swap: 16777212 total, 16715004 free,    62208 used. 32979763+avail Mem
 
   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  5294 oracle    20   0  518.5g  62236  43484 R 100.0  0.0   0:22.10 oracle_52+
119947 oracle    20   0  518.5g  57024  41288 R 100.0  0.0  30:52.57 oracle_11+
128631 oracle    20   0  518.5g  44424  31992 R 100.0  0.0   0:07.68 oracle_12+
 45650 oracle    20   0  518.5g  65336  48492 R  99.3  0.0   2:50.30 oracle_45+
 79648 oracle    20   0  518.5g  68044  49720 R  99.3  0.0  11:01.96 oracle_79+
117514 oracle    20   0  518.8g 149480  87108 S  99.3  0.0   1182:26 ora_scmn_+
117566 oracle    20   0  518.8g 150252  88152 S  99.3  0.0   1173:29 ora_scmn_+
117618 oracle    20   0  518.8g 152764  88040 S  99.3  0.0   1191:01 ora_scmn_+

其它还有vmstat,pidstat、dstat、mpstat,SAR等

什么是SYS CPU 时间?

这个“sys”CPU 时间是多少?它指的是 CPU 在内核模式下运行的时间——通常是这个系统调用列表中列出的函数之一。

如何诊断原因

使用strace和gdb排查程序消耗sys的原因

我们想找出特定进程导致系统 CPU 时间异常高的原因。最上面的工具将说明哪个进程正在使用大部分 CPU——但是您可能需要选择一个单独的线程来挖掘。要在 Linux 上列出进程中的线程,请使用以下命令:
ps -AL |grep进程名

strace工具对于确定特定调用是否过多非常有用。该工具对调试很有用,因为它记录了进程正在进行的系统调用。计数选项 ( -c ) 提供有关进程的一些性能信息,以查看哪个调用占用了多少系统 CPU 时间:

anbob.com# strace -c -p xxx
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 69.16    0.764598           4    214801           getrusage
 25.20    0.278548         142      1959           poll
  3.67    0.040564          13      3101           write

另一种技术是转储异常进程中所有线程的运行堆栈:

anbob.com# for i in `ps -AL |grep process_name |cut -c 7-12`; do \
    echo === $i ===; \
    gdb --q --n --ex bt --batch --pid $i; \
  done 2>&1 |tee /tmp/stacks.txt

通过perf分析

anbob.com# perf record -agT -- sleep 10
anbob.com# perf archive
anbob.com# perf report --sort=comm --stdio

通过crash分析

如果系统crash并且dump出了vmcore(vmcore是通过kdump这样的工具dump出内存),可以参考crash来排查vmcore

与ORACLE性能相关的案例

案例1

因为启用NUMA 分配了过多的共享内存段, 而session的创建与退出需要操作共享内存段,因为共享内存段数目过多,退出时间变长, 如果再遇到logon storm 大量的短连接,就可能会出现这样的%sys 内核调用。可以使用strace -c或truss -d去记录调用时间。

案例2

因为配置了不合理的kernel.sem 信号量,配置过大,而导致SCMN后台线程使用sys 增加, perf  发现semtimedop调用较多如下:

      start_thread                                                                                                                                              
     skgp_thread_async_main                                                                                                                                    
     ssthrdmain                                                                                                                                                
     opirip                                                                                                                                                    
     ksbdispatch                                                                                                                                               
     ksvrdp_cbk                                                                                                                                                
     ksvrdp_int                                                                                                                                                
   - kjblcrspslmain                                                                                                                                            
      - 6.79% kjblcrslmain                                                                                                                                     
         - 6.77% kslwaitctx                                                                                                                                    
            - 6.77% ksliwat                                                                                                                                    
               - 6.76% skgpwwait                                                                                                                               
                  - 6.75% semtimedop                                                                                                                           
                     - 6.74% system_call_fastpath                                                                                                              
                        - 6.74% sys_semtimedop                                                                                                                 
                           - 6.74% SYSC_semtimedop                                                                                                             
                              - 6.72% _raw_qspin_lock                                                                                                          
                                 - 6.72% queued_spin_lock_slowpath                                                                                             
                                      6.58% native_queued_spin_lock_slowpath                                                                                   
+    6.79%     0.00%  ora_cr00_scsbgj  oracle                   [.] skgp_thread_async_main   

在High SYS CPU Usage ON LMS Thread (SCMN/CR00/RS01) During High Workload (Doc ID 2707048.1) 和 http://www.minniebaby.tech/2022/06/10/%e6%a1%88%e4%be%8b%ef%bc%9atroubleshooting-high-sys-cpu-usage-on-19c-rac/ 记录了这个问题。

打赏

目前这篇文章还没有评论(Rss)

我要评论