1. 问题来了
晚上快十点的时候，小y微信响了，兴致一下就上来了！
随后看到了做主机和存储方向的同事发过来的top和dstat命令的截图，如下所示：
看完这幅图，注意红色部分，可能有同学顿感不妙！
也许大家处理的比较多的CPU 100%的问题都是USER CPU 100%的问题!（多数是SQL效率问题），而遇到SYS CPU 100%的故障，大家可能会手足无措！
随后，同事给小y大概讲了下这个问题的背景。
这是一个典型的综合性问题，涉及到Linux操作系统和Oracle数据库。目前客户购买了我们的主机、操作系统和存储维保服务，所以客户DBA判断是操作系统的问题时自然找到我们来处理了，而要想要客户以后也购买我们的数据库的第三方服务，我们必须在这次CASE处理上，体现出中亦科技一站式服务的超强综合能力。
2. 思考时间
文章到这里，大家不妨停一下，思考一下。
如果是你，接下来你打算分几步来分析，又需要哪些信息来帮助你找到问题的原因，并且如何解决呢…
思考时间
……
什么时候往下翻，由你决定…
……
3.头脑风暴和方法论
3.1 数据库等待事件
从方法论上讲，无论数据库出现什么故障，我们都需要看下数据库的等待事件。
sys cpu高，如果是数据库进程造成，则通常是因为latch/mutex竞争导致。
V$session.event检查结果如下图所示：
从上图似乎看不到异常，大部分都是一些空闲的等待事件。
3.2 SYSCALL占比
既然SYS CPU高，从方法论的角度，自然是要找到是哪些SYSCALL被调用比较多才能继续分析。Perf top结果如下所示：
可以看到，Native_queued_spin_lock_slowpath这个syscall的CPU贡献比最大。而这个调用在搜索引擎上，并没有找到有价值的线索以及相关case。
3.3 接下来怎么查，
还是无法突破自己么
走到这里，可能大家已经无法走下去了，接下来怎么查呢？应该如何突破自己呢…
4.真相即将揭晓
请关注上图中的视频号，并预约直播， 1月27日（周四）即晚上八点，小y将用半个小时为大家揭晓导致SYS CPU 100%的真相！记得帮转发并预约直播哦。
另外，小y《量化思维下的SQL优化》课程正在热卖，希望能给大家带来不一样的收获！
如果你想和小y成为同事，一起为各行各业的客户服务，欢迎加入我们。
//可添加公司HR同事的微信进行咨询
（1）Oracle DBA职位：
北京、上海、深圳、广州、呼和浩特、昆明
（2）MySQL DBA职位：
北京、上海、长春、杭州
更多实战分享和风险提示，请关注“中亦安图”公众号和小y视频号！
也可以加小y微信，shadow-huang-bj，进微信群探讨技术。喜欢就转发吧，您的转发是我们持续分享的动力！
小y微信以及公益问诊群（三群）的二维码如下
