CPU佔用過高診斷思路
mpstat -P ALL 1，查看cpu使用情況，主要消耗在sys即os系統調用上
2. MySQL CPU佔用過高怎麼辦
cpu佔用過高解決方法如下：
1、同時按住鍵盤上Ctrl+Alt+Delete，點擊「啟用任務管理器（T）」就可以看到CPU使用率是多少了。（這里只有27%,因為沒有運行游戲，後台程序也沒有打開很多。）
3. 資料庫導致伺服器CPU過高怎麼優化
解決方案
將mysqld的內存庫函數替換成tcmalloc，相比ptmalloc，tcmalloc可以更好的支持高並發調用。
修改my.cnf，添加如下參數並重啟
[mysqld_safe]malloc-lib=tcmalloc
上周五早上7點執行的操作，到現在超過72小時，期間該實例沒有再出現cpu長期飆高的情形。
以下是修改前後cpu使用率對比
4. mysql伺服器cpu高的原因
CPU高主要是因為內存的問題，這樣你要考慮兩點，一是伺服器配置太低了不能承載當前的用戶量，這樣的話你升級就可以解決！二是有人在用流量攻擊你的網站這樣你就要考慮怎麼抵禦，一般情況下故意有人刷流量的可能性不是很大，
5. ORACLE資料庫導致cpu使用率高的原因
Oracle使用過程中的CPU高說明有資源消耗，你看看創建資料庫後，是否創建的有短時間內刷新的物化視圖？而物化視圖的SQL性能又比較低，也會造成CPU不穩定。再就是是否存在周期性的I/O問題？I/O擁塞也會導致CPU高。
另外，關於你的SQL的優化，首先考慮在Where中不要使用子查詢，其次，看看執行計劃，只貼語句是很難進行調優的。
6. 資料庫cpu很高,io很低
cpu高估計還是sql語句有問題,我也是新手,轉帖一個給你參考參考
1-- 檢查系統
sar -u 5 5
2-- 看誰在用CPU
topas
ps -ef |grep ora #檢查第四列，C的大小（unit，100 per cpu）
3-- 檢查CPU數量
/usr/sbin/bindprocessor -q
lsattr El proc0
4-- 2種可能：
1) A Background (instance) process
2) An oracle (user) process ＃此種可能最大。
5-- 如果是用戶進程：那麼高CPU的主要原因有：
Large Queries, Procere compilation or execution, Space management and Sorting
5.1-- 查看每個Session的CPU利用情況：
select ss.sid,se.command,ss.value CPU ,se.username,se.program from v$sesstat ss, v$session se where ss.statistic# in (select statistic# from v$statname where name = 'CPU used by this session') and se.sid=ss.sid and ss.sid>6 order by ss.sid;
5.2-- 比較上述Session，看那個session的CPU使用時間最多，然後查看該Session的具體情況：
select s.sid, w.event, w.wait_time, w.seq#, q.sql_text from v$session_wait w, v$session s, v$process p, v$sqlarea q where s.paddr=p.addr and s.sid=&p and s.sql_address=q.address;
5.3-- 得到上述信息後，查看相應操作是否有hash joins 和 full table scans。如果有hash joins 和 full table scans那麼必須創建相應的Index或者檢查Index是否有效。
另外必須檢查是否有並行的查詢存在和同一時刻有多個用戶在執行相同的SQL語句，如果有必須關閉並行的查詢和任何類型的並行提示(hints);如果查詢使用intermedia數據，那麼為了減少總的Index大小，必須限制使用Intermedia的Worldlist。（try restricting the wordlist that intermedia uses to help rece the total indexsize）。
6-- 上述方案只能根據已經運行完成的操作，對於正在執行的長時間操作只能等操作完成後才能檢測得到。因此我們可以通過另外一個很好的工具來檢測正在運行的長時間操作語句。v$session_longops,這個視圖顯示那些操作正在被運行，或者已經完成。每個process完成後會刷新本視圖的信息。
7-- 怎樣尋找集中使用CPU的Process：
很多時候會發現有N個Process在平均分享著CPU的利用率，這種情況唯一的可能性就是這些Process在執行著相同的Package或者Query.
這種情況：建議通過statspack,在CPU高利用率額時候運行幾個快照，然後根據這些快照檢查Statspack報告，檢查報告中最TOP的 Query。然後使用 sql_trace and tkprof 工具去跟蹤一下。同時檢查buffer cache 的命中率是否大雨95％。
同時在報告中還需要檢查一下table scans (long tables)，看是否在報告生成期間有存在全表掃描。
8-- 另外還有一些不是特別重要的，但是也必須關心檢查的參數可能消耗CPU。
7. mysql中cpu負載很高，是什麼原因
mysql中cpu負載很高，是什麼原因
1、確定高負載的類型 htop，dstat命令看負載高是CPU還是IO
看具體是哪個用戶哪個進程佔用了相關系統資源，當前CPU、內存誰在使用
2、監控具體的sql語句，是insert update 還是 delete導致高負載
抓取mysql包分析，一般抓3306埠的數據 看出最繁忙的sql語句了
3、檢查mysql日誌
分析mysql慢日誌，查看哪些sql語句最耗時
檢查mysql配置參數是否有問題，引起大量的IO或者高CPU操作
innodb_flush_log_at_trx_commit 、innodb_buffer_pool_size 、key_buffer_size 等重要參數
4、檢查硬體問題
8. 資料庫cpu過高 排查方法
資料庫佔用CPU的使用率過高，有可能是你的資料庫中毒了，建議你重裝系統，然後讓資料庫重裝試一下。
9. win2012 sql2014資料庫 cpu佔用過高怎麼解決辦法
可以做如下考慮：
1.打開慢查詢日誌，查詢是否是某個SQL語句佔用過多資源，如果是的話，可以對SQL語句進行優化，比如優化 insert 語句、優化 group by 語句、優化 order by 語句、優化 join 語句等等；
2.考慮索引問題；
3.定期分析表，使用optimize table；
4.優化資料庫對象；
5.考慮是否是鎖問題；
6.調整一些MySQL Server參數，比如key_buffer_size、table_cache、innodb_buffer_pool_size、innodb_log_file_size等等；
7.如果數據量過大，可以考慮使用MySQL集群或者搭建高可用環境。
10. Mysql資料庫CPU佔用過高原因排查 show processlist
mysql伺服器最近偶爾出現cpu百分百居高不下的情況，所以需要進行分析
兄弟命令 show processlist;只列出前100條，如果想全列出請使用show full processlist;
先 簡單說一下各列的含義和用途：
正在將表中修改的數據刷新到磁碟中，同時正在關閉已經用完的表。這是一個很快的操作，如果不是這樣的話，就應該確認磁碟空間是否已經滿了或者磁碟是否正處於重負中。
Connect Out
復制從伺服器正在連接主伺服器。
Copying to tmp table on disk
由於臨時結果集大於 tmp_table_size，正在將臨時表從內存存儲轉為磁碟存儲以此節省內存。
Creating tmp table
正在創建臨時表以存放部分查詢結果。
deleting from main table
伺服器正在執行多表刪除中的第一部分，剛刪除第一個表。
deleting from reference tables
伺服器正在執行多表刪除中的第二部分，正在刪除其他表的記錄。
Flushing tables
正在執行 FLUSH TABLES，等待其他線程關閉數據表。
Killed
發送了一個kill請求給某線程，那麼這個線程將會檢查kill標志位，同時會放棄下一個kill請求。MySQL會在每次的主循環中檢查kill標志 位，不過有些情況下該線程可能會過一小段才能死掉。如果該線程程被其他線程鎖住了，那麼kill請求會在鎖釋放時馬上生效。
Locked
被其他查詢鎖住了。
Sending data
正在處理 SELECT 查詢的記錄，同時正在把結果發送給客戶端。
Sorting for group
正在為 GROUP BY 做排序。
Sorting for order
正在為 ORDER BY 做排序。
Opening tables
這個過程應該會很快，除非受到其他因素的干擾。例如，在執 ALTER TABLE 或 LOCK TABLE 語句行完以前，數據表無法被其他線程打開。 正嘗試打開一個表。
Removing plicates
正在執行一個 SELECT DISTINCT 方式的查詢，但是MySQL無法在前一個階段優化掉那些重復的記錄。因此，MySQL需要再次去掉重復的記錄，然後再把結果發送給客戶端。
Reopen table
獲得了對一個表的鎖，但是必須在表結構修改之後才能獲得這個鎖。已經釋放鎖，關閉數據表，正嘗試重新打開數據表。
Repair by sorting
修復指令正在排序以創建索引。
Repair with keycache
修復指令正在利用索引緩存一個一個地創建新索引。它會比 Repair by sorting 慢些。
Searching rows for update
正在講符合條件的記錄找出來以備更新。它必須在 UPDATE 要修改相關的記錄之前就完成了。
Sleeping
正在等待客戶端發送新請求.
System lock
正在等待取得一個外部的系統鎖。如果當前沒有運行多個 mysqld 伺服器同時請求同一個表，那麼可以通過增加 --skip-external-locking參數來禁止外部系統鎖。
U pgrading lock
INSERT DELAYED 正在嘗試取得一個鎖表以插入新記錄。
Updating
正在搜索匹配的記錄，並且修改它們。
User Lock
正在等待 GET_LOCK()。
Waiting for tables
該線程得到通知，數據表結構已經被修改了，需要重新打開數據表以取得新的結構。然後，為了能的重新打開數據表，必須等到所有其他線程關閉這個表。以下幾種 情況下會產生這個通知：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, 或 OPTIMIZE TABLE。
waiting for handler insert
INSERT DELAYED 已經處理完了所有待處理的插入操作，正在等待新的請求。
大部分狀態對應很快的操作，只要有一個線程保持同一個狀態好幾秒鍾，那麼可能是有問題發生了，需要檢查一下。
還有其他的狀態沒在上面中列出來，不過它們大部分只是在查看伺服器是否有存在錯誤是才用得著。
文章轉自： http://blog.csdn.net/gumanren/article/details/4658385