阿里云服務(wù)器一直100cpu 阿里云服務(wù)器一直啟動(dòng)中

阿里云服務(wù)器cpu使用率100怎么辦

提升cpu配置，另外注意占用cpu的資源是哪些。還有一點(diǎn)，看您選擇的是那種系列cpu

堅(jiān)守“ 做人真誠(chéng) · 做事靠譜 · 口碑至上 · 高效敬業(yè) ”的價(jià)值觀，專(zhuān)業(yè)網(wǎng)站建設(shè)服務(wù)10余年為成都成都酒樓設(shè)計(jì)小微創(chuàng)業(yè)公司專(zhuān)業(yè)提供企業(yè)網(wǎng)站制作營(yíng)銷(xiāo)網(wǎng)站建設(shè)商城網(wǎng)站建設(shè)手機(jī)網(wǎng)站建設(shè)小程序網(wǎng)站建設(shè)網(wǎng)站改版，從內(nèi)容策劃、視覺(jué)設(shè)計(jì)、底層架構(gòu)、網(wǎng)頁(yè)布局、功能開(kāi)發(fā)迭代于一體的高端網(wǎng)站建設(shè)服務(wù)。

阿里云服務(wù)器CPU經(jīng)常跑滿(mǎn)怎么回事

應(yīng)該是你網(wǎng)站被攻擊了，如DDOS/CC攻擊這些都是消耗你服務(wù)器資源的。解決辦法是購(gòu)買(mǎi)阿里云高防IP，防火墻。不過(guò)阿里云的價(jià)格貴死。推薦你用百度云加速的吧。

百度云加速是百度旗下為網(wǎng)站提供一站式加速、安全防護(hù)和搜索引擎優(yōu)化的產(chǎn)品。百度云加速是市場(chǎng)占有率最高的云加速產(chǎn)品之一，正為數(shù)十萬(wàn)用戶(hù)的近百萬(wàn)網(wǎng)站提供CDN、網(wǎng)絡(luò)安全和SEO服務(wù)。每天處理十億級(jí)的PV流量及數(shù)百億TB的數(shù)據(jù)流量，并提供市場(chǎng)頂尖水平的穩(wěn)定性和抗攻擊能力。

百度云加速以部署于骨干網(wǎng)的數(shù)據(jù)中心為支撐，結(jié)合百度深度學(xué)習(xí)技術(shù)，為您的網(wǎng)站提供性能和流量?jī)?yōu)化，致力與廣大開(kāi)發(fā)者一起于打造開(kāi)放、安全的云服務(wù)生態(tài)系統(tǒng)。 我們希望更多的網(wǎng)站合作伙伴以及中小企業(yè)能受益于百度云加速帶來(lái)的價(jià)值及紅利，從而使得云生態(tài)能夠更加良性的發(fā)展。

百度云加速為用戶(hù)提下以下三大類(lèi)功能：

1、網(wǎng)站加速

百度云加速節(jié)點(diǎn)遍布全中國(guó)，通過(guò)智能DNS解析等技術(shù)，將訪問(wèn)網(wǎng)站的用戶(hù)引導(dǎo)至最快的節(jié)點(diǎn)，通過(guò)動(dòng)靜態(tài)加速及頁(yè)面優(yōu)化技術(shù)，極大的提高網(wǎng)站的訪問(wèn)速度和用戶(hù)體驗(yàn)。此外，還可以大量節(jié)省網(wǎng)站自身的服務(wù)計(jì)算和帶寬資源。

2、安全防護(hù)

百度云加速可以同時(shí)防護(hù)包括SQL注入、XSS、Web服務(wù)器漏洞、應(yīng)用程序漏洞以及文件訪問(wèn)控制等問(wèn)題在內(nèi)的十多種黑客滲透攻擊和SYN Flood、UDP Flood、ICMP Flood、TCP Flood以及CC在內(nèi)的多種DDoS攻擊。

3、SEO

百度云加速的百度蜘蛛DNS同步功能，可以做到和百度蜘蛛實(shí)時(shí)同步DNS信息，保證百度蜘蛛的正常抓取，保證搜索引擎權(quán)重的穩(wěn)定性；通過(guò)死鏈自動(dòng)提交、sitemap自動(dòng)提交，及時(shí)收錄網(wǎng)站信息，提高網(wǎng)站索引量。

阿里云服務(wù)器win2008，有時(shí)候cpu占用率100% ，查找具體原因的方法

你好！

磁盤(pán)IO的問(wèn)題是一方面，另外高訪問(wèn)量的Web服務(wù)器也是不適宜在物理內(nèi)存不足的情況下通過(guò)虛擬內(nèi)存運(yùn)行，因?yàn)閮?nèi)存中基本上所有數(shù)據(jù)都是熱數(shù)據(jù)，所有數(shù)據(jù)被訪問(wèn)的幾率相等，一旦物理內(nèi)存不足，會(huì)引發(fā)大量頁(yè)面交換操作，如果磁盤(pán)IO不行，一下就卡死了。

我用的是小鳥(niǎo)云服務(wù)器 不懂的都是問(wèn)他們客服，客服還是比較專(zhuān)業(yè)的

希望我的回答能給你帶來(lái)幫助！有問(wèn)題請(qǐng)追問(wèn)

阿里云ECS的CPU100%排查

一、背景和現(xiàn)象

初創(chuàng)公司，架構(gòu)lanmp，web前端和后端分開(kāi)服務(wù)器，業(yè)務(wù)驅(qū)動(dòng)主要是nginx和apache，nginx主要是處理靜態(tài)文件和反向代理，前后端、搜索引擎、緩存、隊(duì)列等附加的服務(wù)都是用docker容器部署。因?yàn)楸容^初級(jí)，上傳文件和采集文件都是直接寫(xiě)在硬盤(pán)上，涉及到的目錄共享，就在其中一臺(tái)服務(wù)器存儲(chǔ)并且nfs共享。我們暫且分為ECS1（apache1）、ECS2（apache2）、ECS3（nginx）。某天網(wǎng)站業(yè)務(wù)中斷，但是沒(méi)有報(bào)錯(cuò)。一直在等待響應(yīng)，默認(rèn)響應(yīng)超時(shí)是一分鐘，所以很基礎(chǔ)高可用沒(méi)有起到作用。中斷10分鐘左右，重啟服務(wù)，提示“open too many files”，但是lsof統(tǒng)計(jì)沒(méi)幾個(gè)。因?yàn)槌跫?jí)處理不了，所以直接重啟服務(wù)器，一段時(shí)間后一切恢復(fù)正常，可是第二天又來(lái)一次這種情況。

二、第一次出現(xiàn)后的排查思路

本來(lái)第一次發(fā)現(xiàn)這種問(wèn)題的時(shí)候就要追查原因了，看了一下zabbix監(jiān)控圖像其中斷了十分鐘，包括網(wǎng)絡(luò)、內(nèi)存、CPU、硬盤(pán)、IO等監(jiān)控?cái)?shù)據(jù)。首先想到的是網(wǎng)絡(luò)問(wèn)題，結(jié)論是zabbix-servert獲取不到了zabbix-agent采集的數(shù)據(jù)，估計(jì)就是網(wǎng)絡(luò)不通了。

但是，這個(gè)結(jié)論站不住腳，因?yàn)槲冶旧硗ㄟ^(guò)ssh登錄服務(wù)器，并且命令輸入無(wú)卡頓，不至于頭文件都傳不過(guò)來(lái)。后來(lái)一看阿里云的云監(jiān)控，上面有數(shù)據(jù)，似乎也可以佐證網(wǎng)絡(luò)這個(gè)說(shuō)法，因?yàn)樵票O(jiān)控是阿里云內(nèi)部的監(jiān)控，可以?xún)?nèi)網(wǎng)獲取到監(jiān)控?cái)?shù)據(jù)。直到看CPU的使用率這項(xiàng)，發(fā)現(xiàn)有一段時(shí)間的CPU使用率100%。并且我重啟的時(shí)候CPU恢復(fù)正常，不能說(shuō)網(wǎng)絡(luò)一定沒(méi)問(wèn)題，但系統(tǒng)肯定有問(wèn)題。也可以解釋因?yàn)镃PU使用已經(jīng)是100%，zabbix-agent和根本不能正常運(yùn)行，所以沒(méi)有監(jiān)控?cái)?shù)據(jù)。因?yàn)檫@個(gè)公司全部都是云服務(wù)器，沒(méi)有使用IDC所以我們也沒(méi)有安裝smokeping來(lái)監(jiān)控，接著我們就不把重心在網(wǎng)絡(luò)上了。

目前掌握的信息就是:在毫無(wú)征兆的情況下，CPU暴漲到100%，重啟之前一直保留，重啟之后恢復(fù)原樣。匆忙之中又看了一下系統(tǒng)各日志，因?yàn)樘颐?，沒(méi)有總結(jié)，沒(méi)有找到什么有價(jià)值的東西?，F(xiàn)在有下面幾種猜想：第一，程序的bug或者部署不當(dāng)，觸發(fā)之后耗盡資源。第二、docker容器的bug。第三、網(wǎng)絡(luò)攻擊。第四、病毒入侵。第五、阿里云方系統(tǒng)不穩(wěn)定。

小總結(jié)了一下，現(xiàn)在問(wèn)題還沒(méi)有找出來(lái)。下次還有這個(gè)問(wèn)題的可能，所以先盡量防范，但是又不能重啟一刀切。所以在zabbix上面設(shè)置了自動(dòng)化，當(dāng)檢測(cè)到ECS1獲取不到數(shù)據(jù)的時(shí)候馬上操作ECS3標(biāo)記后端為ECS1的apache為down。保留異?，F(xiàn)場(chǎng)。（請(qǐng)求停止的時(shí)候，CPU100%還在）

三、現(xiàn)場(chǎng)排查

1、相應(yīng)的排查計(jì)劃（想到這些信息需要獲取的，實(shí)際上沒(méi)有嚴(yán)格按照這樣的步驟）

1）用htop和top命令監(jiān)控CPU、內(nèi)存使用大的進(jìn)程。先看看哪個(gè)進(jìn)程消耗資源較多,用戶(hù)態(tài)、內(nèi)核態(tài)、內(nèi)存、IO……同時(shí)sar -b查io的 歷史 定時(shí)抽樣。

2）統(tǒng)計(jì)tcp連接數(shù)，看看有沒(méi)有DDOS攻擊。netstat -anp |grep tcp |wc -l 。用iftop-i eth1看看通訊。同時(shí)用tail -n 1200 /var/log/messages查看內(nèi)核日志。

3）用pstree查看打開(kāi)進(jìn)程，ps aux|wc-l看看有沒(méi)有特別多的進(jìn)程。雖然zabbix監(jiān)控上說(shuō)沒(méi)有，但是我們要檢查一下看看有沒(méi)有異常的進(jìn)程名字。

4）查看全部容器的資源使用docker stats $(docker ps -a -q)，看看能不能從容器上排查。

5）有了“too many open files”的啟發(fā)，計(jì)算打開(kāi)文件數(shù)目lsof|wc -l，根據(jù)進(jìn)程看看ll /proc/PID/fd文件描述符有沒(méi)有可疑的打開(kāi)文件、文件描述符。

6）關(guān)于用lsof打開(kāi)文件數(shù)找到的線索，排序打開(kāi)文件找出進(jìn)程號(hào) lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more

7）關(guān)于用lsof打開(kāi)文件數(shù)找到的線索，用lsof -p PID查看進(jìn)程打開(kāi)的句柄。直接查看打開(kāi)的文件。

8）啟動(dòng)容器的時(shí)候又總是“open too many files"。那就是打開(kāi)文件數(shù)的問(wèn)題，因?yàn)镃PU的使用率是CPU的使用時(shí)間和空閑時(shí)間比，有可能因?yàn)榇蜷_(kāi)文件數(shù)阻塞而導(dǎo)致CPU都在等待。針對(duì)連接數(shù)的問(wèn)題，大不了最后一步試試echo 6553500 /proc/sys/fs/file-max 測(cè)試打開(kāi)文件對(duì)CPU的影響。

9）玩意測(cè)出來(lái)了消耗CPU的進(jìn)程，可以使用strace最終程序。用戶(hù)態(tài)的函數(shù)調(diào)用跟蹤用「ltrace」，所以這里我們應(yīng)該用「strace」-p PID

10）從程序里面看到調(diào)用系統(tǒng)底層的函數(shù)可以跟蹤。跟蹤操作 strace -T -e * -p PID，主要看看代碼調(diào)用的函數(shù)有沒(méi)有問(wèn)題。

2、現(xiàn)場(chǎng)排查

第二天同樣時(shí)間，ECS果然暴漲了CPU。這是時(shí)候zabbix的工作如希望進(jìn)行保留了一臺(tái)故障的ECS1給我。

1）用htop看到資源使用最大是，搜索引擎下我寫(xiě)的一個(gè)判斷腳本xunsearch.sh。腳本里面很簡(jiǎn)單，判斷索引和搜索服務(wù)缺一個(gè)就全部重啟。就當(dāng)是我的容器有問(wèn)題我直接關(guān)掉搜索引擎容器。httpd頂上，我又關(guān)掉apache容器。rabbitmq相關(guān)進(jìn)程又頂上。這時(shí)候我沒(méi)心情周旋了，肯定不也是這個(gè)原因。sar -b查看的 歷史 io也沒(méi)有異常。

2）統(tǒng)計(jì)tcp連接，幾百。先不用著重考慮攻擊了。用tail -n 1200 /var/log/messages查看內(nèi)核日志，是TCP TIME WAIT的錯(cuò)誤?？梢岳斫鉃镃PU使用100%，程序無(wú)響應(yīng)外面的tcp請(qǐng)求超時(shí)。這是結(jié)果，還是沒(méi)有找到根本原因。

接著往下看系統(tǒng)內(nèi)核日志，發(fā)現(xiàn)了和“open too many files”呼應(yīng)的錯(cuò)誤，“file-max limit 65535 reached”意思是，已到達(dá)了文件限制瓶頸。這里保持懷疑，繼續(xù)收集其他信息。

3）查看進(jìn)程數(shù)量，數(shù)量幾百。列出來(lái)也看到都是熟悉的進(jìn)程，可以先排除異常進(jìn)程。

4）監(jiān)控容器的資源使用，里面很不穩(wěn)定，首先是xunsearch容器使用80%的CPU，關(guān)掉xunsearch，又變成了其他容器使用CPU最高。很大程度上可以排查容器的問(wèn)題和執(zhí)行程序的問(wèn)題。

5）查看了最大連接數(shù)cat /proc/sys/fs/file-max是65535但是用lsof查到的連接數(shù)是10000多，完全沒(méi)有達(dá)到連接數(shù)。

6）各項(xiàng)參數(shù)都正常，現(xiàn)在聚焦在打開(kāi)的文件數(shù)這個(gè)問(wèn)題上面。也可以用另外同一種方式查看一下內(nèi)核統(tǒng)計(jì)文件 /proc/sys/fs/file-nr，比較一下差異，看看能不能找出問(wèn)題。cat了一下，打開(kāi)文件數(shù)是66080，果然超了！內(nèi)核日志就以這個(gè)為標(biāo)準(zhǔn)。

但是看lsof怎么統(tǒng)計(jì)不出來(lái)，ll /proc/PID/fd也沒(méi)幾個(gè)。這個(gè)問(wèn)題放在后面，先按照步驟echo 6553500 /proc/sys/fs/file-max給連接數(shù)提高到100倍，CPU果然降了下來(lái)。原因確認(rèn)了，但是必須找到根源，為什么忽然有這么大的打開(kāi)文件數(shù)。關(guān)掉全部docker容器和docker引擎，打開(kāi)文件數(shù)是少了一點(diǎn)，但是仍然在65535差不多。我就先排除一下業(yè)務(wù)的影響，把ECS3的nginx直接指向視頻ECS2的apache，就等同于在ECS2上實(shí)現(xiàn)了ECS1的場(chǎng)景。查看一下ECS2的句柄數(shù)，才4000多，排除了業(yè)務(wù)相關(guān)應(yīng)用對(duì)服務(wù)器的影響。那就能下個(gè)小結(jié)論，ECS1被神秘程序打開(kāi)了6萬(wàn)多句柄數(shù)，打開(kāi)業(yè)務(wù)就多了2000多的句柄數(shù)，然后就崩潰了。不過(guò)這個(gè)現(xiàn)象有點(diǎn)奇怪，ECS2和ECS1在一樣的機(jī)房一樣的配置一樣的網(wǎng)絡(luò)環(huán)境，一樣的操作系統(tǒng)，一樣的服務(wù)，一樣的容器，為什么一個(gè)有問(wèn)題，一個(gè)沒(méi)問(wèn)題呢？不同的只是有一臺(tái)是共享nfs。難道是靜態(tài)文件共享了，其他人讀了，也算是本服務(wù)器打開(kāi)的？

7）現(xiàn)在程序找不到，沒(méi)法繼續(xù)lsof -p了。排查之前的猜想。帶著排查得到對(duì)的結(jié)論往下想。

程序的bug和部署不當(dāng)，那是不可能的，因?yàn)橹饕獑?wèn)題來(lái)自于打開(kāi)句柄數(shù)，當(dāng)部署到ECS2那里，一切正常。docker容器的bug，那也不可能的，每個(gè)都是我親自寫(xiě)腳本，親自編譯，親自構(gòu)建的，關(guān)鍵是我關(guān)掉了docker容器和引擎都沒(méi)有很大改善。網(wǎng)絡(luò)攻擊也排除，因?yàn)榫W(wǎng)絡(luò)連接數(shù)沒(méi)幾個(gè)，流量也不變。那就只剩下病毒入侵也不是，沒(méi)有異常進(jìn)程?？紤]到ECS的穩(wěn)定性問(wèn)題了。這方面就協(xié)助阿里云工程師去排查。

8）阿里云工程師用的排查手段和我差不多，最終也是沒(méi)能看到什么。也只是給了我一些治標(biāo)不治本的建議。后來(lái)上升到專(zhuān)家排查，專(zhuān)家直接在阿里云后端抓取了coredump文件分析打開(kāi)的文件是圖片，程序是nfsd。

好像印證了我剛才后面的猜想，應(yīng)該就是ECS1使用了nfs共享其他服務(wù)器打開(kāi)了然后算在ECS1頭上。那問(wèn)題又來(lái)了，我們的業(yè)務(wù)已經(jīng)到達(dá)了可以影響服務(wù)器的程度嗎？

9）既然問(wèn)題解決到這一步，先不管程序有沒(méi)有關(guān)閉打開(kāi)的文件和nfs的配置。我們架構(gòu)上面的圖片應(yīng)該是歸nginx讀取，難道是linux的內(nèi)存機(jī)制讓它緩存了。帶著緩存的問(wèn)題，首先去ECS3上釋放內(nèi)存echo 3 /proc/sys/vm/drop_caches，釋放之后，發(fā)現(xiàn)沒(méi)什么改善，有點(diǎn)失落。總是覺(jué)得還有一臺(tái)后端是PHP主導(dǎo)，但是邏輯上是寫(xiě)入，沒(méi)有打開(kāi)文件之說(shuō)。后來(lái)從程序員中了解到，PHP也有打開(kāi)圖片。我猛然去ECS2釋放一下內(nèi)存，果然，句柄數(shù)降下來(lái)。（這里大家一定有個(gè)疑問(wèn)，為什么我直接想到內(nèi)存緩存而不是目前打開(kāi)的文件呢。其一，這是生產(chǎn)環(huán)境，web前端只有一個(gè)，不能亂來(lái)停服務(wù)。其二，第一次遇到問(wèn)題的時(shí)候，重啟之后沒(méi)有問(wèn)題，過(guò)了一天之后積累到一定的程度才爆發(fā)，這里已經(jīng)引導(dǎo)了我的思路是積累的問(wèn)題，那就是緩存不斷積累了）

10）因?yàn)镋CS2的調(diào)用ECS1的nfs共享文件，所以lsof也有讀不到那么多句柄數(shù)的理由。如果說(shuō)是nfs的服務(wù)本身就有緩存，導(dǎo)致問(wèn)題的話(huà)，我查看了配置文件，還是默認(rèn)值允許緩存，30S過(guò)期，根本不會(huì)因?yàn)閚fs的緩存造成打開(kāi)文件過(guò)多。如果我們的后端程序打開(kāi)之后沒(méi)好好處理的話(huà)，那倒有可能。然后嘗試排除：我改了ECS3的配置，使程序只讀ECS1后端，從ECS1上面卻看不到有什么異常表現(xiàn)，說(shuō)明PHP程序已經(jīng)好好處理了打開(kāi)的文件。也不是docker掛載了nfs的共享的問(wèn)題，因?yàn)閚ginx也有掛載。排查到這里也很大程度上解決問(wèn)題，而且緩存了nfs的全部共享文件，句柄并沒(méi)有增加，也算合理，所以就增加了打開(kāi)文件數(shù)的限制。

11）現(xiàn)在排查的結(jié)果是跟后端和nfs共享有關(guān)。就是說(shuō)，后端掛載了nfs的網(wǎng)絡(luò)共享，被程序讀取。而程序釋放之后，在正常背景的硬盤(pán)文件是沒(méi)有緩存的。但是在nfs掛載的環(huán)境下，緩存并沒(méi)有得到釋放。

12）總結(jié)：很多問(wèn)題的排查和我們的猜想結(jié)果一樣，但是有些例外的情況。比如這次我想到的原因都一一排除，但是問(wèn)題也是在一步步排查中，逐步被發(fā)現(xiàn)的。

文章題目：阿里云服務(wù)器一直100cpu 阿里云服務(wù)器一直啟動(dòng)中
文章網(wǎng)址：http://muchs.cn/article24/dohhgje.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供面包屑導(dǎo)航、小程序開(kāi)發(fā)、網(wǎng)站內(nèi)鏈、網(wǎng)站設(shè)計(jì)、外貿(mào)網(wǎng)站建設(shè)、搜索引擎優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)