數據庫服務器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微信以及公益問診群（三群）的二維碼如下