原文链接: http://www.dbaleet.org/how_to_troubleshooting_cell_node_high_cpu_issue/
事实上，Exadata Cell节点CPU占用率高的情况并不常见。主要是原因有两点：
一是当前Exadata smart scan发生的条件限制较多，通常情况下能够offload到cell节点进行运算的任务并不占绝大多数。
二是当前Cell节点CPU的运算能力实际上已经完全足够，在正常的情况下Cell节点CPU的空闲率都是比较高的。
而Cell节点CPU占用率高也分为所有的Cell节点CPU占用率都很高，还是只有一台或几台Cell节点占用率很高。这两者通常是不一样的，因为正常情况下，一个offloading的任务会均匀分布到所有的Cell节点上，如果所有Cell节点都很高的时候，通常说明当前系统负载较高。但是如果只有一台或者几台Cell节点CPU占用率高，那么这个大多数情况下不是正常的。本文讨论的情况属于后者。
那么如何诊断这一问题呢？可以试着按照以下步骤来解决：
是否为硬件的问题?
系统硬件的问题通常比较好判断，可以通过以下方式进行。（如果确定不是硬件问题，可以跳过这一步。）
- 查看操作系统的/var/log/messages和dmesg，看是否有任何报错信息；
- 登陆到ilom的faulty shell查看是否有faulty的信息：
->show /SP/faultmgmt ->start /SP/faultmgmt/shell Are you sure you want to start /SP/faultmgmt/shell (y/n)? y faultmgmtsp> faultmgmtsp> fmadm faulty -a No faults found faultmgmtsp> exit ->
- 运行Linux命令sosreport收集硬件的诊断信息。
exachk是否有帮助?
exachk is your friend.
在Exadata中，出现任何与数据库无关的问题的时候最好都运行exachk进行健康检查。exachk收集的信息很全，省去大量人工收集的繁琐步骤。并且收集完成以后，可以在整体上对系统的健康状况做一个评估，从中发现一些可疑点，进而缩小范围进行下一步的诊断。
通过操作系统的命令查看进程信息？
如果问题在当前环境下还存在，那么可以直接从操作系统中获取有用的信息。
- 在cell上运行top命令来查看当前最消耗CPU资源的是哪个/哪些进程。然后获取其pid。
- 如果是cellsrv进程占用cpu很高，可以考虑对其做一个systemstate dump。方法可以参考我之前的一篇文章。
- 如果是java进程，可以使用jstack来查看和分析其thread dump。jstack的语法如下：
jstack [-l] <pid> (to connect to running process) jstack -F [-m] [-l] <pid> (to connect to a hung process)
如果问题已经消失并且无法重现，那么则可以通过OSW来查看问题时候操作系统资源占用的情况。我们可以使用sundiag来收集OSW信息，收集方式如下：
# /opt/oracle.SupportTools/sundiag.sh osw
收集完成以后，可以通过osw中的top来确认当时占用系统cpu高的进程，然后再进行下一步计划。
cell的日志中是否有报错信息？
因为cell软件的缺陷是一个比较大的怀疑点，所以这个cell节点的alert也是必需的，请查看问题时间段，以下日志中是否存在错误信息。
/opt/oracle/cell/log/diag/asm/cell/*/trace/alert.log /opt/oracle/cell/log/diag/asm/cell/*/trace/ms-odl.trc /opt/oracle/cell/log/diag/asm/cell/*/trace/
如果问题发生时刻出现过rs-600或者rs-7445，请同时收集其trace文件。如果出现类似错误，可以考虑使用adrci来收集错误信息，如何通过incident来收集这一类错误日志，请参考
http://www.dbaleet.org/collect_exadata_diagnostic_info_via_ips/
RS- 600和RS-7445通常跟cell软件的内存泄露有关系，很多情况下会导致这些进程的挂起。而restart server会将挂起的进程自动重启，但是某些情况下可能存在失灵的情况。
以上仅仅为诊断这Exadata Cell节点上CPU高这一类问题的思路，仅供参考。
Comment