cpu占用過高解決方法如下：
網(wǎng)站建設(shè)、網(wǎng)站設(shè)計服務(wù)團隊是一支充滿著熱情的團隊，執(zhí)著、敏銳、追求更好，是創(chuàng)新互聯(lián)的標(biāo)準(zhǔn)與要求，同時竭誠為客戶提供服務(wù)是我們的理念。創(chuàng)新互聯(lián)把每個網(wǎng)站當(dāng)做一個產(chǎn)品來開發(fā)，精雕細琢，追求一名工匠心中的細致，我們更用心！
1、同時按住鍵盤上Ctrl+Alt+Delete，點擊“啟用任務(wù)管理器（T）”就可以看到CPU使用率是多少了。（這里只有27%,因為沒有運行游戲，后臺程序也沒有打開很多。）
2、按組合鍵Win+R進入運行窗口輸入“msconfig”點擊“啟動”，把不需要的程序禁用掉，程序不要打開太多，就可以減少CPU的使用率了。
你是不是用mysqld_safe起的mysql？這是個守護進程，用它起數(shù)據(jù)庫的話，直接kill它會檢測到數(shù)據(jù)庫非正常關(guān)閉，會自動嘗試起數(shù)據(jù)庫。你可以選擇先kill掉mysqld_safe的進程然后再kill mysql；或者使用這個命令：kill -9 `ps -ef | grep 'mysqld'
服務(wù)器內(nèi)存占用過高的解決方法：
1，首先通過任務(wù)管理器進行進程排序，查找占用內(nèi)存較大的程序進程。一般占用內(nèi)存較大的進程有W3WP、sqlserver、mysqld-nt.exe；
2， 站點進程w3wp 可以在cmd命令行中通過 iisapp 命令來對應(yīng)是那個網(wǎng)站占用內(nèi)存較大。可以通過設(shè)置回收時間、內(nèi)存最大使用值或共用進程池來減少內(nèi)存的占用，但是如果要保證網(wǎng)站的訪問質(zhì)量，還是建議升級至更高型號來解決；
3，數(shù)據(jù)庫 sql server 也可以通過數(shù)據(jù)庫的企業(yè)管理器來設(shè)置最大內(nèi)存占用，但是如果網(wǎng)站程序必須要占用較大內(nèi)存的話，設(shè)置后會發(fā)生頁面報錯、打不開等問題；
4，MYSQL本身會占用較大虛擬內(nèi)存，如果不使用mysql數(shù)據(jù)庫的話，可以將其停止。
我的主機內(nèi)存只有100G，現(xiàn)在要全表掃描一個200G大表，會不會把DB主機的內(nèi)存用光？
邏輯備份時，可不就是做整庫掃描嗎？若這樣就會把內(nèi)存吃光，邏輯備份不是早就掛了？
所以大表全表掃描，看起來應(yīng)該沒問題。這是為啥呢？
假設(shè)，我們現(xiàn)在要對一個200G的InnoDB表db1. t，執(zhí)行一個全表掃描。當(dāng)然，你要把掃描結(jié)果保存在客戶端，會使用類似這樣的命令：
InnoDB數(shù)據(jù)保存在主鍵索引上，所以全表掃描實際上是直接掃描表t的主鍵索引。這條查詢語句由于沒有其他判斷條件，所以查到的每一行都可以直接放到結(jié)果集，然后返回給客戶端。
那么，這個“結(jié)果集”存在哪里呢？
服務(wù)端無需保存一個完整結(jié)果集。取數(shù)據(jù)和發(fā)數(shù)據(jù)的流程是這樣的：
查詢結(jié)果發(fā)送流程
可見：
所以MySQL其實是“邊讀邊發(fā)”。這意味著，若客戶端接收得慢，會導(dǎo)致MySQL服務(wù)端由于結(jié)果發(fā)不出去，這個事務(wù)的執(zhí)行時間變長。
比如下面這個狀態(tài)，就是當(dāng)客戶端不讀 socket receive buffer 內(nèi)容時，在服務(wù)端show processlist看到的結(jié)果。
若看到State一直是“Sending to client”，說明服務(wù)器端的網(wǎng)絡(luò)棧寫滿了。
若客戶端使用–quick參數(shù)，會使用mysql_use_result方法：讀一行處理一行。假設(shè)某業(yè)務(wù)的邏輯較復(fù)雜，每讀一行數(shù)據(jù)以后要處理的邏輯若很慢，就會導(dǎo)致客戶端要過很久才取下一行數(shù)據(jù)，可能就會出現(xiàn)上圖結(jié)果。
因此，對于正常的線上業(yè)務(wù)來說，若一個查詢的返回結(jié)果不多，推薦使用mysql_store_result接口，直接把查詢結(jié)果保存到本地內(nèi)存。
當(dāng)然前提是查詢返回結(jié)果不多。如果太多，因為執(zhí)行了一個大查詢導(dǎo)致客戶端占用內(nèi)存近20G，這種情況下就需要改用mysql_use_result接口。
若你在自己負責(zé)維護的MySQL里看到很多個線程都處于“Sending to client”，表明你要讓業(yè)務(wù)開發(fā)同學(xué)優(yōu)化查詢結(jié)果，并評估這么多的返回結(jié)果是否合理。
若要快速減少處于這個狀態(tài)的線程的話，可以將net_buffer_length設(shè)置更大。
有時，實例上看到很多查詢語句狀態(tài)是“Sending data”，但查看網(wǎng)絡(luò)也沒什么問題，為什么Sending data要這么久？
一個查詢語句的狀態(tài)變化是這樣的：
即“Sending data”并不一定是指“正在發(fā)送數(shù)據(jù)”，而可能是處于執(zhí)行器過程中的任意階段。比如，你可以構(gòu)造一個鎖等待場景，就能看到Sending data狀態(tài)。
讀全表被鎖：
Sending data狀態(tài)
可見session2是在等鎖，狀態(tài)顯示為Sending data。
所以，查詢的結(jié)果是分段發(fā)給客戶端，因此掃描全表，查詢返回大量數(shù)據(jù)，并不會把內(nèi)存打爆。
以上是server層的處理邏輯，在InnoDB引擎里又是怎么處理？
InnoDB內(nèi)存的一個作用，是保存更新的結(jié)果，再配合redo log，避免隨機寫盤。
內(nèi)存的數(shù)據(jù)頁是在Buffer Pool (簡稱為BP)管理，在WAL里BP起加速更新的作用。
BP還能加速查詢。
而BP對查詢的加速效果，依賴于一個重要的指標(biāo)，即：內(nèi)存命中率。
可以在show engine innodb status結(jié)果中，查看一個系統(tǒng)當(dāng)前的BP命中率。一般情況下，一個穩(wěn)定服務(wù)的線上系統(tǒng)，要保證響應(yīng)時間符合要求的話，內(nèi)存命中率要在99%以上。
執(zhí)行show engine innodb status ，可以看到“Buffer pool hit rate”字樣，顯示的就是當(dāng)前的命中率。比如下圖命中率，就是100%。
若所有查詢需要的數(shù)據(jù)頁都能夠直接從內(nèi)存得到，那是最好的，對應(yīng)命中率100%。
InnoDB Buffer Pool的大小是由參數(shù) innodb_buffer_pool_size確定，一般建議設(shè)置成可用物理內(nèi)存的60%~80%。
在大約十年前，單機的數(shù)據(jù)量是上百個G，而物理內(nèi)存是幾個G；現(xiàn)在雖然很多服務(wù)器都能有128G甚至更高的內(nèi)存，但是單機的數(shù)據(jù)量卻達到了T級別。
所以，innodb_buffer_pool_size小于磁盤數(shù)據(jù)量很常見。若一個 Buffer Pool滿了，而又要從磁盤讀入一個數(shù)據(jù)頁，那肯定是要淘汰一個舊數(shù)據(jù)頁的。
使用的最近最少使用 (Least Recently Used, LRU)算法，淘汰最久未使用數(shù)據(jù)。
InnoDB管理BP的LRU算法，是用鏈表實現(xiàn)的：
最終就是最久沒有被訪問的數(shù)據(jù)頁Pm被淘汰。
若此時要做一個全表掃描，會怎樣？若要掃描一個200G的表，而這個表是一個歷史數(shù)據(jù)表，平時沒有業(yè)務(wù)訪問它。
那么，按此算法掃描，就會把當(dāng)前BP里的數(shù)據(jù)全部淘汰，存入掃描過程中訪問到的數(shù)據(jù)頁的內(nèi)容。也就是說BP里主要放的是這個歷史數(shù)據(jù)表的數(shù)據(jù)。
對于一個正在做業(yè)務(wù)服務(wù)的庫，這可不行呀。你會看到，BP內(nèi)存命中率急劇下降，磁盤壓力增加，SQL語句響應(yīng)變慢。
所以，InnoDB不能直接使用原始的LRU。InnoDB對其進行了優(yōu)化。
InnoDB按5:3比例把鏈表分成New區(qū)和Old區(qū)。圖中LRU_old指向的就是old區(qū)域的第一個位置，是整個鏈表的5/8處。即靠近鏈表頭部的5/8是New區(qū)域，靠近鏈表尾部的3/8是old區(qū)域。
改進后的LRU算法執(zhí)行流程：
該策略，就是為了處理類似全表掃描的操作量身定制。還是掃描200G歷史數(shù)據(jù)表：
可以看到，這個策略最大的收益，就是在掃描這個大表的過程中，雖然也用到了BP，但對young區(qū)完全沒有影響，從而保證了Buffer Pool響應(yīng)正常業(yè)務(wù)的查詢命中率。
MySQL采用的是邊算邊發(fā)的邏輯，因此對于數(shù)據(jù)量很大的查詢結(jié)果來說，不會在server端保存完整的結(jié)果集。所以，如果客戶端讀結(jié)果不及時，會堵住MySQL的查詢過程，但是不會把內(nèi)存打爆。
而對于InnoDB引擎內(nèi)部，由于有淘汰策略，大查詢也不會導(dǎo)致內(nèi)存暴漲。并且，由于InnoDB對LRU算法做了改進，冷數(shù)據(jù)的全表掃描，對Buffer Pool的影響也能做到可控。
全表掃描還是比較耗費IO資源的，所以業(yè)務(wù)高峰期還是不能直接在線上主庫執(zhí)行全表掃描的。
在對MySQL 8.0.26 vs GreatSQL 8.0.25的對比測試過程中，有一個環(huán)節(jié)是人為制造磁盤滿的場景，看看MGR是否還能正常響應(yīng)請求。
在實測過程中，最后發(fā)現(xiàn)磁盤滿的那個節(jié)點，持續(xù)時間足夠久后，會因為內(nèi)存消耗過大而最終被OS給OOM Kill。
這個問題我已報告BUG（#104979），下面是該過程的詳細記錄。
首先，直接利用dd復(fù)制空文件填滿磁盤。
disk full報告過程及何時被oom killed
來看下MySQL 8.0.26遇到disk full時日志都輸出哪些內(nèi)容：
從disk full時刻開始，大約過了2.5小時，mysqld進程內(nèi)存消耗持續(xù)上升，最終引發(fā)oom kill
在這期間某個時刻抓到的待認證事務(wù)堆積，在被oom kill前實際不止這么多：
關(guān)注mysqld進程內(nèi)存消耗變化
下面是mysqld進程內(nèi)存消耗變化情況
OS層oom-killer相關(guān)日志：
GreatSQL 8.0.25測試過程
作為對比，我用GreatSQL 8.0.25也做了同樣的測試。
從日志詳情中可以看到，當(dāng)磁盤空間滿了之后，GreatSQL會將那個節(jié)點主動退出集群，對整個集群的影響非常小。
此外，從集群退出后，也不會再接收認證事務(wù)了，所以也沒發(fā)生內(nèi)存持續(xù)暴漲最終被oom killed的情況，實際觀察過程中發(fā)現(xiàn)內(nèi)存反倒還下降了
這樣對比來看，GreatSQL的可靠性還真是可以的，官方的MySQL MGR的可靠性還有待進一步加強呀。
Enjoy GreatSQL :)
OOM Killer(Out of Memory Killer) 是當(dāng)系統(tǒng)內(nèi)存嚴重不足時 linux 內(nèi)核采用的殺掉進程，釋放內(nèi)存的機制。
OOM Killer 通過檢查所有正在運行的進程，然后根據(jù)自己的算法給每個進程一個 badness 分數(shù)，擁有最高 badness 分數(shù)的進程將會在內(nèi)存不足時被殺掉。
它打分的算法如下:
某一個進程和它所有的子進程都占用了很多內(nèi)存的將會打一個高分。
為了釋放足夠的內(nèi)存來解決這種情況，將殺死最少數(shù)量的進程（最好是一個進程）。
內(nèi)核進程和其他較重要的進程會被打成相對較低的分。
上面打分的標(biāo)準(zhǔn)意味著，當(dāng) OOM killer 選擇殺死的進程時，將選擇一個使用大量內(nèi)存，有很多子進程且不是系統(tǒng)進程的進程。
簡單來講，oom-killer 的原則就是損失最小、收益最大，因此它會讓殺死的進程數(shù)盡可能小、釋放的內(nèi)存盡可能大。在數(shù)據(jù)庫服務(wù)器上，MySQL 被分配的內(nèi)存一般不會小，因此容易成為 oom-killer 選擇的對象。
“既然發(fā)生了 OOM，那必然是內(nèi)存不足，內(nèi)存不足這個問題產(chǎn)生原因很多。
首先第一個就是 MySQL 自身內(nèi)存的規(guī)劃有問題，這就涉及到 mysql 相應(yīng)的配置參數(shù)。
另一個可以想到的原因就是一般部署 MySQL 的服務(wù)器，都會部署很多的監(jiān)控和定時任務(wù)腳本，而這些腳本往往缺少必要的內(nèi)存限制，導(dǎo)致在高峰期的時候占用大量的內(nèi)存，導(dǎo)致觸發(fā) Linux 的 oom-killer 機制，最終 MySQL 無辜躺槍犧牲。”
重慶分公司
重慶分公司
