Ⅰ 伺服器cpu佔用率高怎麼解決
當CPU使用率過高的時候，由於CPU資源不足，往往很容易出現電腦卡或者無響應的等情況，最後的結果往往就是死機，只能重啟，但重要文件沒有保存就很麻煩了。那麼針對電腦cpu佔用過高怎麼辦呢?其實都是從兩個方面去考慮，一個是軟體方面，另外一個則是硬體方面，其中硬體方面其決定性因素。
要解決CPU使用率過高，首先我們要明白CPU過高是什麼原因造成的，我們主要從軟體與硬體入手：
原因一、硬體方面導致的CPU使用率高
電腦cpu佔用過高怎麼辦？其實硬體方面決定著比較大的關系，比如如果電腦還是老爺機，採用最初的單核賽揚級處理器，那麼這樣的電腦，在多開啟幾個網頁的情況下就容易導致CPU使用率過高，不管你怎麼優化系統，這個問題始終無法很好解決，這主要是因為硬體本身過低造成的。
原因二、軟體方面導致的CPU使用率高
這方面主要涉及到的是系統問題，比如系統過於臃腫，開啟過多程序以及電腦中病毒木馬等等都會產生CPU使用率過高，而導致電腦速度慢。解決辦法主要是圍繞系統優化，優化開機啟動項、盡量避免開啟太多程序等等，以下我們會詳細介紹。
不過如今電腦均已經達到了雙核以上，即便入門處理器在滿足上網與辦公也會有非常流暢的運行速度，因此如果是老電腦經常出現CPU使用率過高，那麼建議大家最好升級處理器或者換電腦從根本上解決問題。對於如今入門雙核處理器盡管滿足基本上網與辦公流暢，但運行大型應用也同樣會存在CPU使用率高的問題，因此在DIY裝機中我們一定要了解電腦的用途與需求，選擇合適的電腦配置。
最後我們再來重點與大家介紹下關於電腦cpu佔用過高怎麼辦的解決辦法。由於硬體方面，我們只能採取硬體升級來解決，所以這里不過多介紹，下面我們主要針對系統以及軟體優化的方式，來盡量釋放CPU使用率，這種方法適合CPU使用高並不是很嚴重的情況，過於嚴重建議還是從硬體升級入手。
(1).排除病毒感染
如果電腦中病毒或馬的情況下，木馬惡意程序很可能會大量佔用CPU資源，尤其是一些頑固病毒木馬，一直都在惡意循環活動，感染各類系統文件，大量佔用CPU資源，這種情況就很容易出現CPU使用率過高，即便是較高的CPU也經不起反復大量的惡意程序運行，因此如果發現CPU使用過高，我們首先應高想下是否是電腦中病毒了，建議大家安裝如金山殺毒進行全面查殺。
⑵.排除病毒感染後，下面我們就需要從系統優化入手了，首先建議大家優化開啟啟動項，盡量讓不需要使用到的軟體不開機自動啟動，比如一些播放器軟體、銀行安全插件等，這些完全可以需要的時候再開啟，沒必要開機啟動。
⑶關閉不需要的程序進程
如果發現CPU使用率較高，我們可以進入任務管理器，關閉一些不需要的程序與進程，如下圖：
通過注冊表進行服務項優化，也可以一定程度優化CPU資源使用，比如當系統檢查到開啟視頻相關服務，就會把CPU多分配一些供其使用，我們就是要禁用這個機制，方法如下：
我們首先進入電腦注冊表。
如上圖，接著將數值數據中，僅保留AudioEndpointBuilder和RpcSs，其他一概刪除，然後退出即可，如下圖：
以上就是簡單的介紹了一條關於開啟視頻相關服務的優化，通過禁用該無用功能，也可以微微提升CPU資源，另外我們還可以優化注冊表其它項目。
Ⅱ 如何處理阿里雲ECS伺服器CPU利用率過高
如果你選擇的是t5類型的主機，那麼這個問題是無解的，因為這個類型本身就是限制了CPU性能基線在10%~15%，不能超過這個數字。
也有一種可能用的是共享型實例，特點是多台小雞共享一個母雞的系統資源，小雞之間存在了資源爭搶。
關於這個內容有一些解釋，長期建站和 windows 遠程桌面慎用阿里雲突發性能 t5 實例，我覺得寫的挺實在的，建議怎麼操作都有提供了
Ⅲ 在阿里雲的伺服器上運行一個服務程序半天時間數據返回變慢，cpu佔用變大，內存沒有長，什麼原因導致的
有事情乾的時候，如果Sleep時間太長，就會導致有足夠的CPU，卻不幹活。查一下有沒有什麼地方使用到了遍歷。如果有存在就需要進行優化。有一個程序，一個數組也不大，也就五十個元素，但是當多次調用的時候，由於遍歷，明顯導致CPU無故地被佔用在遍歷過程當中。另外一個就是多線程當中的同步。線程並不是越多越好，線程越多所導致的碰撞越大，反倒會阻礙其它線程的工作。
Ⅳ 阿里雲主機從6號起CPU一直99%，不知道怎麼回事
CPU跑滿如果
雲伺服器
ECS實例的#CPU跑滿，考慮以下因素：檢查程序最大線程數不夠程序代碼不夠優化，存在
死循環
、
死鎖
Web
配置文件
的參數不夠優化檢查Web和
系統日誌
存在訪問異常網站被
盜鏈
當時有
搜索引擎爬蟲
大面積爬取網站受到了小型
網路攻擊
；
進程有異常實例中毒或中木馬Linux實例可以通過系統日誌和Web日誌，和一些top，free，uptime，sar，ps命令查詢原因。
Windows實例可以通過資源
監控器
分析。
Ⅳ 阿里雲cpu檢測進程mysql太高怎麼解決
一台伺服器解決了 Mysql cpu 佔用 100% 的問題。稍整理了一下，將經驗記錄在這篇文章里。
朋友主機(Windows 2003 + IIS + PHP + MYSQL )近來 MySQL 服務進程 (mysqld-nt.exe) CPU 佔用率總為 100% 高居不下。此主機有10個左右的 database, 分別給十個網站調用。據朋友測試，導致 mysqld-nt.exe cpu 佔用奇高的是網站A，一旦在 IIS 中將此網站停止服務，CPU 佔用就降下來了。一啟用，則馬上上升。
MYSQL CPU 佔用 100% 的解決過程
今天早上仔細檢查了一下。目前此網站的七日平均日 IP 為2000，PageView 為 3萬左右。網站A 用的 database 目前有39個表，記錄數 60.1萬條，占空間 45MB。按這個數據，MySQL 不可能佔用這么高的資源。於是在伺服器上運行命令，將 mysql 當前的環境變數輸出到文件 output.txt：
d:\web\mysql> mysqld.exe --help >output.txt發現 tmp_table_size 的值是默認的 32M，於是修改 My.ini, 將 tmp_table_size 賦值到 200M:
d:\web\mysql> notepad c:\windows\my.ini
[mysqld]
tmp_table_size=200M
然後重啟 MySQL 服務。CPU 佔用有輕微下降，以前的CPU 佔用波形圖是 100% 一根直線，現在則在 97%~100%之間起伏。這表明調整 tmp_table_size 參數對 MYSQL 性能提升有改善作用。但問題還沒有完全解決。
於是進入 mysql 的 shell 命令行，調用 show processlist, 查看當前 mysql 使用頻繁的 sql 語句：
mysql> show processlist;
反復調用此命令，發現網站 A 的兩個 SQL 語句經常在 process list 中出現，其語法如下：
SELECT t1.pid, t2.userid, t3.count, t1.dateFROM _mydata AS t1
LEFT JOIN _myuser AS t3 ON t1.userid=t3.useridLEFT JOIN _mydata_body AS t2 ON t1.pid=t3.pidORDER BY t1.pid
LIMIT 0,15
調用 show columns 檢查這三個表的結構 :
mysql> show columns from _myuser;
mysql> show columns from _mydata;
mysql> show columns from _mydata_body;
終於發現了問題所在：_mydata 表，只根據 pid 建立了一個 primary key，但並沒有為 userid 建立索引。而在這個 SQL 語句的第一個 LEFT JOIN ON 子句中：
LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid_mydata 的 userid 被參與了條件比較運算。於是我為給 _mydata 表根據欄位 userid 建立了一個索引：
mysql> ALTER TABLE `_mydata` ADD INDEX ( `userid` )建立此索引之後，CPU 馬上降到了 80% 左右。看到找到了問題所在，於是檢查另一個反復出現在 show processlist 中的 sql 語句：
SELECT COUNT(*)
FROM _mydata AS t1, _mydata_key AS t2
WHERE t1.pid=t2.pid and t2.keywords = '孔雀'
經檢查 _mydata_key 表的結構，發現它只為 pid 建了了 primary key, 沒有為 keywords 建立 index。_mydata_key 目前有 33 萬條記錄，在沒有索引的情況下對33萬條記錄進行文本檢索匹配，不耗費大量的 cpu 時間才怪。看來就是針對這個表的檢索出問題了。於是同樣為 _mydata_key 表根據欄位 keywords 加上索引:
mysql> ALTER TABLE `_mydata_key` ADD INDEX ( `keywords` )建立此索引之後，CPU立刻降了下來，在 50%~70%之間震盪。
再次調用 show prosslist，網站A 的sql 調用就很少出現在結果列表中了。但發現此主機運行了幾個 Discuz 的論壇程序， Discuz 論壇的好幾個表也存在著這個問題。於是順手一並解決，cpu佔用再次降下來了。(2007.07.09 附註：關於 discuz 論壇的具體優化過程，我後來另寫了一篇文章，詳見：千萬級記錄的 Discuz! 論壇導致 MySQL CPU 100% 的 優化筆記 http://www.xiaohui.com/dev/server/20070701-discuz-mysql-cpu-100-optimize.htm)解決 MYSQL CPU 佔用 100% 的經驗總結
增加 tmp_table_size 值。mysql 的配置文件中，tmp_table_size 的默認大小是 32M。如果一張臨時表超出該大小，MySQL產生一個 The table tbl_name is full 形式的錯誤，如果你做很多高級 GROUP BY 查詢，增加 tmp_table_size 值。 這是 mysql 官方關於此選項的解釋：
tmp_table_size
This variable determines the maximum size for a temporary table in memory. If the table becomes too large, a MYISAM table is created on disk. Try to avoid temporary tables by optimizing the queries where possible, but where this is not possible, try to ensure temporary tables are always stored in memory. Watching the processlist for queries with temporary tables that take too long to resolve can give you an early warning that tmp_table_size needs to be upped. Be aware that memory is also allocated per-thread. An example where upping this worked for more was a server where I upped this from 32MB (the default) to 64MB with immediate effect. The quicker resolution of queries resulted in less threads being active at any one time, with all-round benefits for the server, and available memory.
對 WHERE, JOIN, MAX(), MIN(), ORDER BY 等子句中的條件判斷中用到的欄位,應該根據其建立索引 INDEX。索引被用來快速找出在一個列上用一特定值的行。沒有索引，MySQL不得不首先以第一條記錄開始並然後讀完整個表直到它找出相關的行。表越大，花費時間越多。如果表對於查詢的列有一個索引，MySQL能快速到達一個位置去搜尋到數據文件的中間，沒有必要考慮所有數據。如果一個表有1000行，這比順序讀取至少快100倍。所有的MySQL索引(PRIMARY、UNIQUE和INDEX)在B樹中存儲。根據 mysql 的開發文檔:
索引 index 用於：
快速找出匹配一個WHERE子句的行
當執行聯結(JOIN)時，從其他表檢索行。
對特定的索引列找出MAX()或MIN()值
如果排序或分組在一個可用鍵的最左面前綴上進行(例如，ORDER BY key_part_1,key_part_2)，排序或分組一個表。如果所有鍵值部分跟隨DESC，鍵以倒序被讀取。
在一些情況中，一個查詢能被優化來檢索值，不用咨詢數據文件。如果對某些表的所有使用的列是數字型的並且構成某些鍵的最左面前綴，為了更快，值可以從索引樹被檢索出來。假定你發出下列SELECT語句：
mysql> SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;如果一個多列索引存在於col1和col2上，適當的行可以直接被取出。如果分開的單行列索引存在於col1和col2上，優化器試圖通過決定哪個索引將找到更少的行並來找出更具限制性的索引並且使用該索引取行。
開發人員做 SQL 數據表設計的時候，一定要通盤考慮清楚。