数据库服务器CPU 100%,怎么办...--技术人生系列第六十六期-我和数据中心的故事

　　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微信以及公益问诊群（三群）的二维码如下