伺服器出現由內存問題引發的故障，例如系統內部服務響應速度變慢、伺服器登錄不上、系統觸發 OOM（Out Of Memory）等。通常情況下當實例內存使用率持續高於90%時，可判斷為實例內存使用率過高。CPU/內存使用率過高的問題原因可能由硬體因素、系統進程、業務進程或者木馬病毒等因素導致。
筆者以前寫過一篇文章- Linux 下的 60 秒分析的檢查清單 ，適用於 任何性能問題 的分析工作，這一篇文章是關於CPU/內存使用率的具體的排查思路總結。
執行 top 命令後按 M ，根據駐留內存大小進行排序，查看 「RES」 及 「SHR」 列是否有進程佔用內存過高。按 P，以 CPU 佔用率大小的順序排列進程列表，查看是否有進程佔用cpu過高。
如果有異常進程佔用了大量 CPU 或內存資源，記錄需要終止的進程 PID，輸入k，再輸入需要終止進程的 PID ，按 Enter。
另外說明一下，top 運行中可以通過 top 的內部命令對進程的顯示方式進行控制，最常用的是M和P。
CPU 空閑但高負載情況，Load average 是 CPU 負載的評估，其值越高，說明其任務隊列越長，處於等待執行的任務越多。執行ps -axjf命令，查看進程狀態，並檢查是否存在 D 狀態進程。D 狀態指不可中斷的睡眠狀態，該狀態進程無法被殺死，也無法自行退出。若出現較多 D 狀態進程，可通過恢復該進程依賴資源或重啟系統進行解決。
Linux 系統通過分頁機制管理內存的同時，將磁碟的一部分劃出來作為虛擬內存。而 kswapd0 是 Linux 系統虛擬內存管理中負責換頁的進程。當系統內存不足時，kswapd0 會頻繁的進行換頁操作。換頁操作非常消耗 CPU 資源，導致該進程持續佔用高 CPU 資源。
執行top命令，找到 kswapd0 進程。觀察 kswapd0 進程狀態，若持續處於非睡眠狀態，且運行時間較長並持續佔用較高 CPU 資源，執行 vmstat ，free，ps 等指令，查詢系統內進程的內存佔用情況，重啟系統或終止不需要且安全的進程。如果 si，so 的值也比較高，則表示系統存在頻繁的換頁操作，當前系統的物理內存已經不能滿足您的需要。 si 表示每秒從交換區寫入內存的大小(單位:kb/s) ， so 每秒從內存寫到交換區的大小。
執行cat/proc/meminfo |grep-i shmem命令查看共享內存。
buddy可以以頁為單位獲取連續的物理內存了，即4K為單位。slab負責需要頻繁的獲取/釋放並不大的連續物理內存，比如幾十位元組。執行cat /proc/meminfo | grep -i SUnreclaim命令查看slab 內存。
標準的 4KB 大小的頁面外，內存大頁管理內存中的巨大的頁面，處理較少的頁面映射表，從而減少訪問/維護它們的開銷。執行cat /proc/meminfo | grep -iE "HugePages_Total|Hugepagesize" 查看內存大頁。
內存使用率計算：
(Total - available)100% / Total
（Total - Free - Buffers - Cached - SReclaimable + Shmem）* 100% / Total
cat /proc/meminfo查看信息含義：
㈡ 如何查看Linux 伺服器的負載信息
方法一：
通過top命令來查看伺服器負載
再對此Linux伺服器性能分析之前，先了解下Linux系統Load average負載的知識，負載均值在 uptime 或者top 命令中可以看到
方法二：輸入 iostat -x -k -t
說明：%util: 一秒中有百分之多少的時間用於 I/O 操作，或者說一秒中有多少時間 I/O 隊列是非空的。
即 delta(use)/s/1000 (因為use的單位為毫秒)
如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁碟可能存在瓶頸。
方法三：
如果玩游戲很卡，可以用hdparm –t /dev/磁碟名稱來測試磁碟性能是否達標
說明：sd表示硬碟是SATA，SCSI或者SAS，a表示串口的第一塊硬碟
㈢ 在linux 中使用uptime 所看到的負載數怎麼判斷負載高
uptime gives a one line display of the following information. The current time, how long the system has been running, how many users are currently logged
on, and the system load averages for the past 1, 5, and 15 minutes.
uptime會列印出過去1/5/15 分鍾的負載，負載值越大負載越高。
如果只有一個CPU，負載為1代表CPU為100%
㈣ 如何查看linux伺服器負載
做壓力測試的時候想看看Linux伺服器當前負載如何，性能怎樣，可以使用下面這些命令
uptime
顯示當前用戶數，以及最近1
分鍾內、5分鍾內、15
分鍾內系統的平均負載
cat
/proc/loadavg
用於顯示系統1秒鍾平均負載、5秒鍾平均負載、15秒鍾平均負載、總作業數、正在運行的作業總數
cat
/proc/stat
這個顯示的內容較多，具體的就不一一列舉了，需要的朋友可以自己查閱相關資料
㈤ Linux裡面iptables怎麼實現負載均衡
1. iptables實現負載均衡的方式：
在Linux中使用iptables完成tcp的負載均衡有兩種模式：隨機、輪詢
The statistic mole support two different modes:
random:(隨機)
the rule is skipped based on a probability
nth:（輪詢）
the rule is skipped based on a round robin algorithm
2. example
㈥ linux伺服器的平均負載問題
如果可以抄進入linux系統的話，襲用top查看系統的負載，
我們可以通過load avg來分析當前cpu的使用情況。
比如1顆cpu 在load avg里代表一個1.00 2顆cpu那麼他的負載就不應該長時間保持在2.00
你可以再top里按1查看每顆cpu的使用情況
按照你上述的情況。如果WDCP面板里顯示的是4個核心，那麼他的load avg長時間保持在3.00-4.00之間就應該屬於高負載了。
㈦ Linux 平均負載
1、查看Linux系統CPU個數
2、每次發現系統變慢時，我們通常做的第一件事，就是執行top或者uptime命令
2.1、如果1分鍾、5分鍾、15分鍾的三個值基本相同，或者相差不大，那就說明系統負載很平穩。
2.2、但如果1分鍾的值遠小於15 分鍾的值，就說明系統最近1分鍾的負載在減少，而過去15分鍾內卻有很大的負載。
2.3、反過來，如果1分鍾的值遠大於 15 分鍾的值，就說明最近1分鍾的負載在增加，這種增加有可能只是臨時性的，也有可能還會持續增加下去，所以就需要持續觀察。一旦1分鍾的平均負載接近或超過了CPU的個數，就意味著系統正在發生過載的問題，這時就得分析調查是哪裡導致的問題，並要想辦法優化了。
eg：假設我們在一個單 CPU 系統上看到平均負載為 1.73，0.60，7.98，那麼說明在過去 1 分鍾內，系統有 73% 的超載，而在 15 分鍾內，有 698% 的超載，從整體趨勢來看，系統的負載在降低。
2.4、當平均負載高於 CPU 數量70%的時候，你就應該分析排查負載高的問題了。一旦負載過高，就可能導致進程響應變慢，進而影響服務的正常功能。
2.5、CPU 使用率，是單位時間內 CPU 繁忙情況的統計，跟平均負載並不一定完全對應
2.5.1、CPU 密集型進程，使用大量 CPU 會導致平均負載升高，此時這兩者是一致的；
2.5.2、I/O 密集型進程，等待 I/O 也會導致平均負載升高，但 CPU 使用率不一定很高；
2.5.3、大量等待 CPU 的進程調度也會導致平均負載升高，此時的CPU使用率也會比較高。
3、使用工具iostat（stress）、mpstat、pidstat 等工具，找出平均負載升高的根源
3.1、stress 是一個 Linux 系統壓力測試工具，這里我們用作異常進程模擬平均負載升高的場景
3.2、而 sysstat 包含了常用的 Linux 性能工具，用來監控和分析系統的性能。我們的案例會用到這個包的兩個命令 mpstat 和 pidstat。
3.2.1、mpstat 是一個常用的多核 CPU 性能分析工具，用來實時查看每個 CPU 的性能指標，以及所有CPU的平均指標。
3.2.2、pidstat 是一個常用的進程性能分析工具，用來實時查看進程的 CPU、內存、I/O 以及上下文切換等性能指標
首先，在第一個終端運行 stress 命令，模擬一個 CPU 使用率 100% 的場景
接著，在第二個終端運行uptime查看平均負載的變化情況
最後，在第三個終端運行mpstat查看 CPU 使用率的變化情況
那麼到底是哪個進程，導致 iowait 這么高呢？我們還是用 pidstat 來查詢
首先還是運行 stress 命令，但這次模擬 I/O 壓力，即不停地執行 sync
還是在第二個終端運行uptime查看平均負載的變化情況
然後，第三個終端運行mpstat查看 CPU 使用率的變化情況
那麼到底是哪個進程，導致 iowait 這么高呢？我們還是用 pidstat 來查詢
當系統中運行進程超出 CPU 運行能力時，就會出現等待 CPU 的進程。比如，我們還是使用 stress，但這次模擬的是 4 個進程
由於系統只有 1 個CPU，明顯比 4 個進程要少得多，因而，系統的 CPU 處於嚴重過載狀態，平均負載高達3.71
接著再運行pidstat來看一下進程的情況
㈧ 如何理解Linux下的負載均衡
我空間裡面有
㈨ linux伺服器的平均負載問題
如果是web伺服器，用到程序與資料庫交互的伺服器，您報出的硬體配置，負載6以內可以穩定運行，負載12以內可以正常運行，負載高於15運行吃力，負載18以上明顯感覺變慢，更高可能就運行出錯了。我指的是一般情況下。
如果是特殊情況，內部機制導致的服務宕機假死，那麼負載值的呈現可能不高的，但是有問題的服務已經不能正常工作了，需要重啟這個服務，一旦重啟這個假死的服務進程，系統負載就會立刻隨之升高，因為可能隨著重啟這個服務進程之後，服務突然能響應了堆積的並發請求，導致突發性升高，然後可能迅速降低負載。 所以負載是表示系統的綜合運行載荷，不完全是cpu的佔用率。 在linux系統里，幾種情況都可以導致負載高：1.系統進程佔用時間過長 2.應用程序的進程佔用cpu時間過長 3.磁碟讀寫I/O的進程佔用cpu的時間過長。 是否穩定運行，不能單單以負載值作為評估標准，只能作為大概的參考。負載高的原因要從我之前說的3個原因方面去查，查到了問題後，就可以改進改善，從而實現穩定運行。
其實有很多特例的，據我所知，某些大型的知名網站伺服器原來採用lamp架構的，在負載100以上都能正常運行，這么高的負載其實在某些情況下特別是大規模並發情況下，只要把控好軟硬體的協作關系，照樣可以正常運作。
我從事linux網站運維數年了，希望我的回答你能滿意。
㈩ Linux的負載均衡詳解
Linux的負載均衡常用的有三種技術：中國人搞出來的大神級產品 LVS Linux Virtual Server，俄羅斯的Nginx，來發法國的HAProxy。都是基於Linux的開源免費的負載均衡軟體。
1. 抗負載能力強，性能高，能達到F5的60%，對內存和CPU資源消耗比較低
2. 工作在網路4層，通過VRRP協議(僅作代理之用)，具體的流量是由linux內核來處理，因此沒有流量的產生。
3. 穩定，可靠性高，自身有完美的熱備方案(Keepalived+lvs)
4. 不支持正則處理，不能做動靜分離。
5. 支持多種負載均衡演算法：rr(輪詢)，wrr(帶權輪詢)、lc(最小連接)、wlc(帶權最小連接)
6. 配置相對復雜，對網路依賴比較大，穩定性很高。
7. LVS工作模式有4種：
(1) nat 地址轉換
(2) dr 直接路由
(3) tun 隧道
(4) full-nat
1. 工作在網路7層，可以針對http應用做一些分流的策略，比如針對域名，目錄結構
2. Nginx對網路的依賴較小，理論上能ping通就能進行負載功能
3. Nginx安裝配置比較簡單，測試起來很方便
4. 也可以承擔較高的負載壓力且穩定，nginx是為解決c10k問題而誕生的
5. 對後端伺服器的健康檢查，只支持通過埠來檢測，不支持通過url來檢測
6. Nginx對請求的非同步處理可以幫助節點伺服器減輕負載壓力
7. Nginx僅能支持http、https和Email協議，這樣就在適用范圍較小。
8. 不支持Session的直接保持，但能通過ip_hash來解決。對Big request header的支持不是很好。
9. Nginx還能做Web伺服器即Cache功能。
1.支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機；
2.能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作
3.支持url檢測後端的伺服器出問題的檢測會有很好的幫助。
4.更多的負載均衡策略比如：動態加權輪循(DynamicRoundRobin)，加權源地址哈希(Weighted SourceHash)，加權URL哈希和加權參數哈希(WeightedParameterHash)已經實現
5.單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。
6.HAProxy可以對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。
7.支持負載均衡演算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie）
8.不能做Web伺服器即Cache。
1. 負載能力
lvs抗負載能力最強，因為僅作分發不處理請求，相當於只作轉發不做進一步處理直接在內核中完成，對系統資源消耗低（LVS DR模式）；
nginx和haproxy相對來說會弱，但是日PV2000萬也沒什麼問題，因為不僅接受客戶端請求，還與後端upstream節點進行請求並獲取響應，再把響應返回給客戶端，對系統資源和網路資源消耗高；
註：建議如果公司網站流量日PV在2000萬以上，並發在7，8萬以上才考慮用lvs+keepalived架構
2. 功能性
lvs僅支持4層tcp負載均衡，haproxy可以支持4層tcp和7層http負載均衡，nginx可以支持7層http負載均衡（新版本也支持7層負載均衡）；
nginx功能強大，配置靈活，可做web靜態站點，靜態緩存加速，動靜分離，並支持域名，正則表達式，Location匹配，rewrite跳轉，配置簡單直觀明了，還可以結合etc或consule做發布自動化上下線等等；
haproxy相對nginx的7層負載均衡會弱一些，靈活性不足，個人建議一般用haproxy做TCP負載均衡更合適一些；
3. 運維復雜度
lvs相對來說部署架構更復雜一些，lvs對網路是有要求，lvs必須與real server在同一個網段，也更費資源，需要多2台伺服器成本；
nginx和haproxy部署架構更簡單，對網路也沒要求，更便於後續維護；
像對於大型的，需要進行高並發的網站或者對網路不太嚴格的時候，可以使用nginx；
對於大型的Web伺服器的時候可以使用haproxy；
對性能有嚴格要求的時候可以使用lvs，就單純從負載均衡的角度來說，lvs也許會成為主流，更適合現在大型的互聯網公司。
註：lvs,nginx,haproxy要實現高可用，都需要藉助keepalived軟體