簡介Linux壓力測試工具stress 1.0.1源碼資源包面向系統管理員、運維工程師與嵌入式開發者用于模擬CPU、內存、線程/進程等負載評估系統在極限場景下的穩定性與性能表現。壓縮包整體約199KB共32個文件以C源碼、configure配置腳本、Makefile構建文件為主兼有texinfo文檔、man手冊及ChangeLog等說明材料目錄沿用標準GNU工程結構便于編譯、安裝與二次開發。該工具支持通過命令行靈活指定負載類型與線程數量可模擬計算密集、內存緊張及高并發進程創建等場景。目前已有3031人學習下載適合需要驗證服務器承載力、排查資源瓶頸或開展性能調優的工程師。借助該包可收獲完整源碼與配套文檔既能直接用于壓測環境搭建也能深入研讀stress的核心實現為自行編寫輕量級負載工具提供參考。linux壓力測試工具stress實戰從裝庫到拷機一條龍做Linux運維和系統性能驗證的朋友一定繞不開一個場景新買的服務器到了要驗證硬件穩不穩內核打了一個補丁要確認系統不會跑著跑著就崩部署容器之前要看看資源隔離到底靠不靠譜。這些場景都有一個共同的底子需求——給系統施加一個可控的壓力然后在壓力下觀察它的表現。stress就是干這個的一個輕量、純粹、用來給Linux系統制造負載的小工具我用它做過不少次拷機和穩定性驗證這篇就來聊聊它的完整玩法。1. 工具選型與核心概念1.1 stress到底是個什么工具stress是Amos Waterland寫的一個C語言小工具它的設計目標非常純粹通過fork出大量子進程分別去消耗CPU、內存、磁盤I/O和資源分配能力從而讓系統進入一種可量化、可控的高負載狀態。說人話就是——你告訴它“給我壓出8個滿負荷CPU的負載”它就老老實實fork出8個進程每個進程拼命算數學題把CPU時間吃滿。很多人會把stress和stress-ng搞混。stress-ng是它的加強版包含幾百種壓測方法功能更強但復雜度也高。而stress的特點是參數簡單、行為直觀、結果容易判斷適合做快速驗證和日常拷機。我個人的習慣是快速驗證用stress深度專項壓測用stress-ng或sysbench但日常工作中stress出現的頻率其實更高因為它足夠輕量裝完即用不引入太多學習成本。1.2 為什么需要給系統制造壓力很多人會有疑問我的服務已經在線上跑了為什么還要額外制造壓力這里有個概念要分清線上跑業務是“實際負載”壓測工具制造的是“人工負載”。實際負載是隨機的、起伏的、不好控制的而人工負載是確定的、穩定的、可調節的。做穩定性驗證時你不希望負載忽高忽低導致結果無法解釋你希望CPU穩定在100%、內存穩定占用N個GB然后觀察系統在這種極端情況下是否還能正常工作。stress的價值就在這里它把負載變成了一個有刻度的儀器讓你能夠在“系統扛不住之前”就掌握系統的邊界在哪里。比如一臺8核機器先壓6個CPU看看是否穩定再壓8個再壓10個超賣觀察不同負載級別下的系統行為。這種測試在硬件驗收、性能基線采集、容器限制驗證中都屬于必備環節。1.3 適用場景梳理從我實際接觸過的使用場景來看stress主要適合以下幾種情況硬件拷機新裝機或購買二手服務器后用CPU和內存壓力驗證硬件是否有隱性故障。內核與驅動驗證打了補丁、升級了內核、更換了驅動需要在負載下確認系統不會panic或死鎖。性能調優前后對比調整內核參數、CPU調頻策略之前和之后用同樣的壓力對比系統表現。容器與虛擬化資源限制驗證確認cgroup的CPU限制、內存限制是否真正生效。教學和技術測試演示系統負載、觀察調度行為時stress是干凈利落的負載制造工具。2. 安裝部署與環境準備2.1 各主流發行版的安裝方法stress的安裝非常簡單官方源里基本都有現成的包。以最常見的幾個發行版為例# Debian / Ubuntu sudo apt-get install stress # CentOS / RHEL 7/8/9 sudo yum install stress # Fedora sudo dnf install stress # Arch Linux sudo pacman -S stress如果你用的是極其精簡的發行版或者沒有現成包也可以從源碼編譯安裝。stress的源碼包很小編譯過程依賴也很少wget https://downloads.your.org/stress/stress-1.0.7.tar.gz tar -xzf stress-1.0.7.tar.gz cd stress-1.0.7 ./configure make sudo make install安裝完成之后驗證一下是否成功stress --version能輸出版本號就說明OK了。我在編譯安裝時踩過一次坑某些精簡系統上缺少make和gcc需要先用包管理器裝好基礎編譯工具鏈再執行configure。2.2 壓測前的系統狀態確認在做壓力測試之前有一件小事經常被忽略確認CPU調頻策略。現在的CPU大多有自動調頻功能空閑時降頻省電負載高時自動升頻。如果你不做任何設置壓測過程中CPU頻率可能忽高忽低測試結果的一致性會受影響。建議在壓測前把CPU調到最大頻率或性能模式觀察一下當前頻率運行狀態# 查看當前CPU頻率 cat /proc/cpuinfo | grep MHz # 使用cpupower工具設置性能模式需要root權限 cpupower frequency-set -g performance如果發行版沒有cpupower命令也可以裝linux-cpupowerDebian/Ubuntu或kernel-toolsCentOS包。當然如果你測試的目的恰恰是要驗證調頻策略本身的行為那就不需要這一步反而應該保持默認策略去壓具體取決于你的目標。另外壓測前還要確認系統負載基線是干凈的。最好在一臺沒有業務的機器上做壓測或者至少確認當前top顯示的load average不高避免把別人業務的負載誤算進你的測試結果里。3. 壓測方案設計與核心參數3.1 CPU壓測--cpu參數詳解stress最常見的用法是CPU壓測命令格式如下stress --cpu 8這會在當前終端前臺fork出8個子進程每個進程執行一個計算平方根的死循環把CPU核心吃滿。根據我的實測每個--cpu進程會跑在單核上8個進程就能吃滿8個邏輯核心。機器有多少核心可以用nproc查看。這里有個決策點如果機器是超線程架構8核16線程要壓滿所有邏輯核心應該用--cpu 16還是只壓8個物理核心這取決于你的目的。如果你想驗證整機散熱和供電是否扛得住那就壓滿16個線程讓所有邏輯處理器都進入高負載狀態如果你想模擬“每個物理核心承載一個典型業務進程”的場景壓8個可能更貼近實際。CPU壓測默認會一直跑下去直到你按CtrlC終止。實際操作中通常需要限制時長用--timeout參數# 壓8個CPU核心持續60秒后自動退出 stress --cpu 8 --timeout 60s--timeout支持10s、1m、1h、1d這樣的時間后綴也支持純數字單位為秒。加上超時控制的最大好處是不用干等測試完自動退出適合寫進腳本里循環執行。3.2 內存壓測--vm參數詳解內存壓測用到--vm系列的參數# 啟動4個內存壓測進程每個分配512MB內存 stress --vm 4 --vm-bytes 512M每個--vm進程會調用malloc分配指定大小的內存然后循環寫入數據確保內存頁真實被觸達。這里我補充一個容易被忽視的細節malloc分配出來的內存在沒有寫入之前只是虛擬內存不會占據實際的物理內存頁。stress內部會通過寫入操作對這些內存頁進行實際觸達這也是它壓內存比較有效的原因。實際壓測時內存總量要算清楚。比如機器有8GB可用內存你啟動4個進程每個分配2GB總量就是8GB。如果分配總量超過實際可用內存系統會開始使用swap性能會驟降如果超過物理內存加swap的總量則可能觸發OOM Killer某個進程被內核殺掉測出來的結果就不具備參考意義。還有--vm-hang參數值得說明。它會指示子進程在分配并寫入內存后掛起一段時間而不是反復隨機讀寫。比如stress --vm 2 --vm-bytes 1G --vm-hang 30兩個進程各分配1GB內存并保持30秒不釋放。這種模式適合測試“系統在內存長期以高占用率運行時是否穩定”貼近數據庫緩存、JVM堆內存這類常駐內存場景。3.3 磁盤和I/O壓測--io與--hdd磁盤I/O壓測主要有兩個參數--io和--hdd。# 啟動4個I/O進程每個進程不斷執行sync系統調用 stress --io 4--io的做法是不斷fork新進程執行sync()把文件系統緩沖區刷入磁盤產生系統調用和I/O調度壓力。不過說實話這種壓測方式對現代SSD來說壓力并不大它更多是壓內核的I/O路徑和調度器不是直接壓磁盤帶寬。想要更直接的磁盤寫入壓力用--hdd# 啟動2個寫盤進程每個向文件中寫入1GB數據 stress --hdd 2 --hdd-bytes 1G--hdd進程會創建一個臨時文件默認在/var/tmp目錄下然后反復寫數據進去。這個測試會真實產生磁盤寫入流量可以用來驗證磁盤的穩定性和散熱。這里有一個我踩過的坑--hdd默認會在/var/tmp下生成臨時文件對于容量小的根分區1GB甚至幾GB的寫入很容易把根分區磁盤占滿。所以在跑--hdd之前一定先看看磁盤剩余空間同時建議用--hdd-bytes限制單次寫入上限或者指定文件路徑。3.4 組合壓測模擬真實混合負載前面的參數都是單一維度的但生產環境的負載從來不會只消耗一種資源。stress允許同時指定多個維度一次壓測模擬混合負載# 8個CPU進程 2個內存進程各1G 1個磁盤寫入進程持續5分鐘 stress --cpu 8 --vm 2 --vm-bytes 1G --hdd 1 --hdd-bytes 1G --timeout 5m這種組合壓測更適合在真實服務器上做整體穩定性驗證。比如你新部署了一個生產環境想確認在“CPU高負載、內存大量占用、磁盤持續寫入”的場景下業務進程還能不能穩定響應這種混合壓測就很有參考價值。我在實際做服務器驗收時幾乎都是用組合參數跑30分鐘以上而不僅僅是單測一個維度。3.5 核心參數速查表參數作用常用搭配備注--cpu N啟動N個CPU負載進程--timeout每個進程吃滿一個邏輯核心--vm N啟動N個內存負載進程--vm-bytes每個進程分配指定大小內存--vm-bytes SIZE指定每個內存進程分配的大小--vm N支持K/M/G后綴--vm-hang N內存分配后掛起N秒--vm模擬常駐內存負載--io N啟動N個I/O進程--timeout不斷執行sync系統調用--hdd N啟動N個寫盤進程--hdd-bytes真實產生磁盤寫入流量--timeout TIME指定總運行時長所有參數支持s/m/h/d后綴--verbose顯示詳細壓測日志任意配合調試使用4. 實操過程與數據觀察4.1 一個完整的壓測流程示例在真正壓測之前我先做一次基線采集也就是不做任何壓測時記錄系統初始狀態。這一步很重要因為后續判斷異常都需要和基線對比uptime free -h df -hT /var/tmp mpstat -P ALL 1 3假設我現在拿到一臺8核16G的服務器要做一次硬件穩定性驗收壓測方案分三步走第一步跑CPU壓力10分鐘確認所有邏輯核心都穩定在100%負載stress --cpu 16 --timeout 10m第二步跑內存壓力按70%內存占用設計16G機器留出系統余量分配12G占用stress --vm 6 --vm-bytes 2G --timeout 10m第三步混合壓測30分鐘模擬真實業務的高負載場景stress --cpu 16 --vm 4 --vm-bytes 2G --hdd 4 --hdd-bytes 2G --timeout 30m三個步驟跑完如果沒有出現進程被kill、系統死機、內核報錯等現象基本可以認為這臺機器的硬件和系統在合理的負載范圍內是穩定的。4.2 壓測過程中的數據觀察方法壓測啟動后記住一個原則不要只盯著黑色終端等結果要開另一個終端去觀察系統狀態。我最常用的觀察工具組合如下top/htop看整體CPU使用率、load average、內存占用判斷壓測進程是否達到預期負載。mpstat -P ALL 1逐核查看CPU使用率。這個非常關鍵能看出壓力是否均勻分布在所有核心上如果只有部分核心為100%說明壓測進程數量少了或者存在中斷綁核等問題。free -h查看內存與swap使用情況。如果內存壓測導致swap開始大量增長說明壓測內存分配過量不是理想狀態。iostat -x 1觀察磁盤使用率、吞吐量和I/O等待時間配合--hdd壓測使用。這里我舉個例子。用stress --cpu 8壓一臺8核機器在另一個終端跑mpstat -P ALL 1正常情況下每個CPU的%usr都接近100%。但如果發現其中某個CPU的%usr只有50%左右可能就是stress進程被調度到了中斷處理較多的CPU上或者系統本身有綁核配置。這種細節在高精度壓測中值得排查。4.3 壓測時的安全注意事項壓測說到底是在挑戰系統的極限所以要講究分寸。幾個我吃過虧的教訓分享給你第一不要在遠程連接的唯一會話里直接跑大壓力測試。如果你用的是SSH連服務器跑壓力測試壓力過大可能導致系統響應變慢甚至假死你的SSH連接有可能斷掉然后你就失去了對機器的控制。建議用tmux或screen起一個會話跑壓測即使連接斷了壓測進程還能繼續運行重新連上后還能看到之前的輸出。第二內存壓測總量一定要留余量。別把物理內存壓到100%給系統內核和基礎服務留出幾百MB甚至更多的余量否則OOM Killer啟動后可能把不該殺的系統服務給殺了測試結果會被嚴重污染。第三跑磁盤壓測前確認磁盤空間和磨損程度。如果是機械硬盤或老舊SSD的機器長時間--hdd壓測會加劇磁盤磨損。這種測試不是不能做但要有目的性不是為了測磁盤本身就沒必要長時間跑。5. 常見問題與排查技巧實錄5.1 壓測以后系統負載降不下來這個問題我遇到不只一次。明明按了CtrlC或者--timeout到了時間系統負載依然很高。排查步驟是這樣的先用top看是哪個進程在消耗CPU如果是stress的殘留子進程用pkill -f stress清理。注意stress的父進程退出后某些子進程可能會變成孤兒進程繼續運行。這時可以pgrep -l stress列出所有名字包含stress的進程逐個確認后清理pkill -9 stress另外如果CPU壓測跑完LOAD值依然很高但CPU使用率已經降下來了那可能是系統在刷臟頁或等待I/O完成這時候耐心等一下就好通常不會持續太久。5.2 內存壓測觸發OOM Killer內存壓測時系統報錯Out of memory: Kill process說明壓測配置和機器實際內存不匹配。比如一臺只有4G內存的機器你直接跑stress --vm 8 --vm-bytes 1G8個進程共需要8G內存遠超物理內存OOM Killer就會出手。解決方案是精確計算內存分配量。建議先看free -h確定可用內存最多用70%到80%的可用內存做壓測。假設機器有8G內存系統已用2G可用約6G那壓測內存量控制在4G到5G比較合適可以配置成stress --vm 4 --vm-bytes 1G還有一種情況你確實想壓到OOM看系統能不能正確殺掉內存超限進程從而保護主機不掛這種測試在容器環境驗證時其實是有效的驗證手段。但如果你的目標是驗證“系統在內存高負載下穩定運行”那就要避開OOM閾值。5.3 --hdd壓測后臨時文件沒清理干凈stress --hdd跑完后會在/var/tmp下留下臨時文件按我的經驗它會以類似stress.XXXXXX的命名方式寫入文件。如果不清理日積月累會占用不少磁盤空間。清理命令很簡單ls /var/tmp/ rm -f /var/tmp/stress.*為了避免這個問題更推薦的做法是在命令里就指定臨時文件路徑放到專門的測試目錄下測完直接刪目錄mkdir /tmp/stress-test stress --hdd 2 --hdd-bytes 1G --timeout 1m跑完以后刪除整個測試目錄干凈利落。5.4 壓測過程中SSH超時斷連這是一個很實際的運維場景你通過SSH連接服務器跑長時間壓測壓測到一半SSH連接斷了。排查思路是先確認是不是網絡側的會話超時限制同時建議所有長時間壓測都放進tmux會話中執行。我已經養成習慣凡是超過10分鐘的壓測一律先建tmux會話tmux new -s stress-test stress --cpu 16 --timeout 1h # 按 CtrlB 再按 D 脫離會話連接斷了也不影響壓測進程重新連接后用tmux attach -t stress-test回到壓測會話查看輸出情況。這個習慣幫我避免了多次遠程壓測斷連后無法確認結果的麻煩。5.5 壓測結果如何判斷是否成功最后聊一下怎么判斷壓測結果。stress本身不會輸出一個“通過/失敗”的結論你需要自己綜合判斷。我個人的判斷標準有三條壓測期間系統沒有出現嚴重錯誤日志dmesg中沒有OOM、panic、硬件報錯。壓測結束后SSH和基礎服務依然正常響應負載能回落到正常水平。壓測期間業務進程如果有沒有出現崩潰或者長時間無響應。這三條都滿足這臺機器基本可以認定在當前壓測配置下是穩定的。如果再嚴格一點可以對比壓測前后/proc/cpuinfo和smartctl的磁盤健康狀態確認沒有新增的硬件隱性故障。結尾我在實際使用stress過程中最大的體會是工具本身簡單到不行真正的復雜度在于你怎么設計壓測方案和解讀壓測結果。壓測之前先想清楚要驗證什么再動手跑數據才有參考價值。最后分享一個小技巧如果你需要定期做壓力測試可以寫一個腳本把stress和stress-ng配合使用先用stress做快速冒煙驗證確認基本功能正常后再用stress-ng做專項深度壓測這樣兼顧了效率與深度我在多個項目的服務器驗收中都是這么做的效果一直不錯。本文還有配套的精品資源點擊獲取 Linux壓力測試工具stress實戰：從安裝到拷機一條龍
簡介Linux壓力測試工具stress 1.0.1源碼資源包面向系統管理員、運維工程師與嵌入式開發者用于模擬CPU、內存、線程/進程等負載評估系統在極限場景下的穩定性與性能表現。壓縮包整體約199KB共32個文件以C源碼、configure配置腳本、Makefile構建文件為主兼有texinfo文檔、man手冊及ChangeLog等說明材料目錄沿用標準GNU工程結構便于編譯、安裝與二次開發。該工具支持通過命令行靈活指定負載類型與線程數量可模擬計算密集、內存緊張及高并發進程創建等場景。目前已有3031人學習下載適合需要驗證服務器承載力、排查資源瓶頸或開展性能調優的工程師。借助該包可收獲完整源碼與配套文檔既能直接用于壓測環境搭建也能深入研讀stress的核心實現為自行編寫輕量級負載工具提供參考。linux壓力測試工具stress實戰從裝庫到拷機一條龍做Linux運維和系統性能驗證的朋友一定繞不開一個場景新買的服務器到了要驗證硬件穩不穩內核打了一個補丁要確認系統不會跑著跑著就崩部署容器之前要看看資源隔離到底靠不靠譜。這些場景都有一個共同的底子需求——給系統施加一個可控的壓力然后在壓力下觀察它的表現。stress就是干這個的一個輕量、純粹、用來給Linux系統制造負載的小工具我用它做過不少次拷機和穩定性驗證這篇就來聊聊它的完整玩法。1. 工具選型與核心概念1.1 stress到底是個什么工具stress是Amos Waterland寫的一個C語言小工具它的設計目標非常純粹通過fork出大量子進程分別去消耗CPU、內存、磁盤I/O和資源分配能力從而讓系統進入一種可量化、可控的高負載狀態。說人話就是——你告訴它“給我壓出8個滿負荷CPU的負載”它就老老實實fork出8個進程每個進程拼命算數學題把CPU時間吃滿。很多人會把stress和stress-ng搞混。stress-ng是它的加強版包含幾百種壓測方法功能更強但復雜度也高。而stress的特點是參數簡單、行為直觀、結果容易判斷適合做快速驗證和日常拷機。我個人的習慣是快速驗證用stress深度專項壓測用stress-ng或sysbench但日常工作中stress出現的頻率其實更高因為它足夠輕量裝完即用不引入太多學習成本。1.2 為什么需要給系統制造壓力很多人會有疑問我的服務已經在線上跑了為什么還要額外制造壓力這里有個概念要分清線上跑業務是“實際負載”壓測工具制造的是“人工負載”。實際負載是隨機的、起伏的、不好控制的而人工負載是確定的、穩定的、可調節的。做穩定性驗證時你不希望負載忽高忽低導致結果無法解釋你希望CPU穩定在100%、內存穩定占用N個GB然后觀察系統在這種極端情況下是否還能正常工作。stress的價值就在這里它把負載變成了一個有刻度的儀器讓你能夠在“系統扛不住之前”就掌握系統的邊界在哪里。比如一臺8核機器先壓6個CPU看看是否穩定再壓8個再壓10個超賣觀察不同負載級別下的系統行為。這種測試在硬件驗收、性能基線采集、容器限制驗證中都屬于必備環節。1.3 適用場景梳理從我實際接觸過的使用場景來看stress主要適合以下幾種情況硬件拷機新裝機或購買二手服務器后用CPU和內存壓力驗證硬件是否有隱性故障。內核與驅動驗證打了補丁、升級了內核、更換了驅動需要在負載下確認系統不會panic或死鎖。性能調優前后對比調整內核參數、CPU調頻策略之前和之后用同樣的壓力對比系統表現。容器與虛擬化資源限制驗證確認cgroup的CPU限制、內存限制是否真正生效。教學和技術測試演示系統負載、觀察調度行為時stress是干凈利落的負載制造工具。2. 安裝部署與環境準備2.1 各主流發行版的安裝方法stress的安裝非常簡單官方源里基本都有現成的包。以最常見的幾個發行版為例# Debian / Ubuntu sudo apt-get install stress # CentOS / RHEL 7/8/9 sudo yum install stress # Fedora sudo dnf install stress # Arch Linux sudo pacman -S stress如果你用的是極其精簡的發行版或者沒有現成包也可以從源碼編譯安裝。stress的源碼包很小編譯過程依賴也很少wget https://downloads.your.org/stress/stress-1.0.7.tar.gz tar -xzf stress-1.0.7.tar.gz cd stress-1.0.7 ./configure make sudo make install安裝完成之后驗證一下是否成功stress --version能輸出版本號就說明OK了。我在編譯安裝時踩過一次坑某些精簡系統上缺少make和gcc需要先用包管理器裝好基礎編譯工具鏈再執行configure。2.2 壓測前的系統狀態確認在做壓力測試之前有一件小事經常被忽略確認CPU調頻策略。現在的CPU大多有自動調頻功能空閑時降頻省電負載高時自動升頻。如果你不做任何設置壓測過程中CPU頻率可能忽高忽低測試結果的一致性會受影響。建議在壓測前把CPU調到最大頻率或性能模式觀察一下當前頻率運行狀態# 查看當前CPU頻率 cat /proc/cpuinfo | grep MHz # 使用cpupower工具設置性能模式需要root權限 cpupower frequency-set -g performance如果發行版沒有cpupower命令也可以裝linux-cpupowerDebian/Ubuntu或kernel-toolsCentOS包。當然如果你測試的目的恰恰是要驗證調頻策略本身的行為那就不需要這一步反而應該保持默認策略去壓具體取決于你的目標。另外壓測前還要確認系統負載基線是干凈的。最好在一臺沒有業務的機器上做壓測或者至少確認當前top顯示的load average不高避免把別人業務的負載誤算進你的測試結果里。3. 壓測方案設計與核心參數3.1 CPU壓測--cpu參數詳解stress最常見的用法是CPU壓測命令格式如下stress --cpu 8這會在當前終端前臺fork出8個子進程每個進程執行一個計算平方根的死循環把CPU核心吃滿。根據我的實測每個--cpu進程會跑在單核上8個進程就能吃滿8個邏輯核心。機器有多少核心可以用nproc查看。這里有個決策點如果機器是超線程架構8核16線程要壓滿所有邏輯核心應該用--cpu 16還是只壓8個物理核心這取決于你的目的。如果你想驗證整機散熱和供電是否扛得住那就壓滿16個線程讓所有邏輯處理器都進入高負載狀態如果你想模擬“每個物理核心承載一個典型業務進程”的場景壓8個可能更貼近實際。CPU壓測默認會一直跑下去直到你按CtrlC終止。實際操作中通常需要限制時長用--timeout參數# 壓8個CPU核心持續60秒后自動退出 stress --cpu 8 --timeout 60s--timeout支持10s、1m、1h、1d這樣的時間后綴也支持純數字單位為秒。加上超時控制的最大好處是不用干等測試完自動退出適合寫進腳本里循環執行。3.2 內存壓測--vm參數詳解內存壓測用到--vm系列的參數# 啟動4個內存壓測進程每個分配512MB內存 stress --vm 4 --vm-bytes 512M每個--vm進程會調用malloc分配指定大小的內存然后循環寫入數據確保內存頁真實被觸達。這里我補充一個容易被忽視的細節malloc分配出來的內存在沒有寫入之前只是虛擬內存不會占據實際的物理內存頁。stress內部會通過寫入操作對這些內存頁進行實際觸達這也是它壓內存比較有效的原因。實際壓測時內存總量要算清楚。比如機器有8GB可用內存你啟動4個進程每個分配2GB總量就是8GB。如果分配總量超過實際可用內存系統會開始使用swap性能會驟降如果超過物理內存加swap的總量則可能觸發OOM Killer某個進程被內核殺掉測出來的結果就不具備參考意義。還有--vm-hang參數值得說明。它會指示子進程在分配并寫入內存后掛起一段時間而不是反復隨機讀寫。比如stress --vm 2 --vm-bytes 1G --vm-hang 30兩個進程各分配1GB內存并保持30秒不釋放。這種模式適合測試“系統在內存長期以高占用率運行時是否穩定”貼近數據庫緩存、JVM堆內存這類常駐內存場景。3.3 磁盤和I/O壓測--io與--hdd磁盤I/O壓測主要有兩個參數--io和--hdd。# 啟動4個I/O進程每個進程不斷執行sync系統調用 stress --io 4--io的做法是不斷fork新進程執行sync()把文件系統緩沖區刷入磁盤產生系統調用和I/O調度壓力。不過說實話這種壓測方式對現代SSD來說壓力并不大它更多是壓內核的I/O路徑和調度器不是直接壓磁盤帶寬。想要更直接的磁盤寫入壓力用--hdd# 啟動2個寫盤進程每個向文件中寫入1GB數據 stress --hdd 2 --hdd-bytes 1G--hdd進程會創建一個臨時文件默認在/var/tmp目錄下然后反復寫數據進去。這個測試會真實產生磁盤寫入流量可以用來驗證磁盤的穩定性和散熱。這里有一個我踩過的坑--hdd默認會在/var/tmp下生成臨時文件對于容量小的根分區1GB甚至幾GB的寫入很容易把根分區磁盤占滿。所以在跑--hdd之前一定先看看磁盤剩余空間同時建議用--hdd-bytes限制單次寫入上限或者指定文件路徑。3.4 組合壓測模擬真實混合負載前面的參數都是單一維度的但生產環境的負載從來不會只消耗一種資源。stress允許同時指定多個維度一次壓測模擬混合負載# 8個CPU進程 2個內存進程各1G 1個磁盤寫入進程持續5分鐘 stress --cpu 8 --vm 2 --vm-bytes 1G --hdd 1 --hdd-bytes 1G --timeout 5m這種組合壓測更適合在真實服務器上做整體穩定性驗證。比如你新部署了一個生產環境想確認在“CPU高負載、內存大量占用、磁盤持續寫入”的場景下業務進程還能不能穩定響應這種混合壓測就很有參考價值。我在實際做服務器驗收時幾乎都是用組合參數跑30分鐘以上而不僅僅是單測一個維度。3.5 核心參數速查表參數作用常用搭配備注--cpu N啟動N個CPU負載進程--timeout每個進程吃滿一個邏輯核心--vm N啟動N個內存負載進程--vm-bytes每個進程分配指定大小內存--vm-bytes SIZE指定每個內存進程分配的大小--vm N支持K/M/G后綴--vm-hang N內存分配后掛起N秒--vm模擬常駐內存負載--io N啟動N個I/O進程--timeout不斷執行sync系統調用--hdd N啟動N個寫盤進程--hdd-bytes真實產生磁盤寫入流量--timeout TIME指定總運行時長所有參數支持s/m/h/d后綴--verbose顯示詳細壓測日志任意配合調試使用4. 實操過程與數據觀察4.1 一個完整的壓測流程示例在真正壓測之前我先做一次基線采集也就是不做任何壓測時記錄系統初始狀態。這一步很重要因為后續判斷異常都需要和基線對比uptime free -h df -hT /var/tmp mpstat -P ALL 1 3假設我現在拿到一臺8核16G的服務器要做一次硬件穩定性驗收壓測方案分三步走第一步跑CPU壓力10分鐘確認所有邏輯核心都穩定在100%負載stress --cpu 16 --timeout 10m第二步跑內存壓力按70%內存占用設計16G機器留出系統余量分配12G占用stress --vm 6 --vm-bytes 2G --timeout 10m第三步混合壓測30分鐘模擬真實業務的高負載場景stress --cpu 16 --vm 4 --vm-bytes 2G --hdd 4 --hdd-bytes 2G --timeout 30m三個步驟跑完如果沒有出現進程被kill、系統死機、內核報錯等現象基本可以認為這臺機器的硬件和系統在合理的負載范圍內是穩定的。4.2 壓測過程中的數據觀察方法壓測啟動后記住一個原則不要只盯著黑色終端等結果要開另一個終端去觀察系統狀態。我最常用的觀察工具組合如下top/htop看整體CPU使用率、load average、內存占用判斷壓測進程是否達到預期負載。mpstat -P ALL 1逐核查看CPU使用率。這個非常關鍵能看出壓力是否均勻分布在所有核心上如果只有部分核心為100%說明壓測進程數量少了或者存在中斷綁核等問題。free -h查看內存與swap使用情況。如果內存壓測導致swap開始大量增長說明壓測內存分配過量不是理想狀態。iostat -x 1觀察磁盤使用率、吞吐量和I/O等待時間配合--hdd壓測使用。這里我舉個例子。用stress --cpu 8壓一臺8核機器在另一個終端跑mpstat -P ALL 1正常情況下每個CPU的%usr都接近100%。但如果發現其中某個CPU的%usr只有50%左右可能就是stress進程被調度到了中斷處理較多的CPU上或者系統本身有綁核配置。這種細節在高精度壓測中值得排查。4.3 壓測時的安全注意事項壓測說到底是在挑戰系統的極限所以要講究分寸。幾個我吃過虧的教訓分享給你第一不要在遠程連接的唯一會話里直接跑大壓力測試。如果你用的是SSH連服務器跑壓力測試壓力過大可能導致系統響應變慢甚至假死你的SSH連接有可能斷掉然后你就失去了對機器的控制。建議用tmux或screen起一個會話跑壓測即使連接斷了壓測進程還能繼續運行重新連上后還能看到之前的輸出。第二內存壓測總量一定要留余量。別把物理內存壓到100%給系統內核和基礎服務留出幾百MB甚至更多的余量否則OOM Killer啟動后可能把不該殺的系統服務給殺了測試結果會被嚴重污染。第三跑磁盤壓測前確認磁盤空間和磨損程度。如果是機械硬盤或老舊SSD的機器長時間--hdd壓測會加劇磁盤磨損。這種測試不是不能做但要有目的性不是為了測磁盤本身就沒必要長時間跑。5. 常見問題與排查技巧實錄5.1 壓測以后系統負載降不下來這個問題我遇到不只一次。明明按了CtrlC或者--timeout到了時間系統負載依然很高。排查步驟是這樣的先用top看是哪個進程在消耗CPU如果是stress的殘留子進程用pkill -f stress清理。注意stress的父進程退出后某些子進程可能會變成孤兒進程繼續運行。這時可以pgrep -l stress列出所有名字包含stress的進程逐個確認后清理pkill -9 stress另外如果CPU壓測跑完LOAD值依然很高但CPU使用率已經降下來了那可能是系統在刷臟頁或等待I/O完成這時候耐心等一下就好通常不會持續太久。5.2 內存壓測觸發OOM Killer內存壓測時系統報錯Out of memory: Kill process說明壓測配置和機器實際內存不匹配。比如一臺只有4G內存的機器你直接跑stress --vm 8 --vm-bytes 1G8個進程共需要8G內存遠超物理內存OOM Killer就會出手。解決方案是精確計算內存分配量。建議先看free -h確定可用內存最多用70%到80%的可用內存做壓測。假設機器有8G內存系統已用2G可用約6G那壓測內存量控制在4G到5G比較合適可以配置成stress --vm 4 --vm-bytes 1G還有一種情況你確實想壓到OOM看系統能不能正確殺掉內存超限進程從而保護主機不掛這種測試在容器環境驗證時其實是有效的驗證手段。但如果你的目標是驗證“系統在內存高負載下穩定運行”那就要避開OOM閾值。5.3 --hdd壓測后臨時文件沒清理干凈stress --hdd跑完后會在/var/tmp下留下臨時文件按我的經驗它會以類似stress.XXXXXX的命名方式寫入文件。如果不清理日積月累會占用不少磁盤空間。清理命令很簡單ls /var/tmp/ rm -f /var/tmp/stress.*為了避免這個問題更推薦的做法是在命令里就指定臨時文件路徑放到專門的測試目錄下測完直接刪目錄mkdir /tmp/stress-test stress --hdd 2 --hdd-bytes 1G --timeout 1m跑完以后刪除整個測試目錄干凈利落。5.4 壓測過程中SSH超時斷連這是一個很實際的運維場景你通過SSH連接服務器跑長時間壓測壓測到一半SSH連接斷了。排查思路是先確認是不是網絡側的會話超時限制同時建議所有長時間壓測都放進tmux會話中執行。我已經養成習慣凡是超過10分鐘的壓測一律先建tmux會話tmux new -s stress-test stress --cpu 16 --timeout 1h # 按 CtrlB 再按 D 脫離會話連接斷了也不影響壓測進程重新連接后用tmux attach -t stress-test回到壓測會話查看輸出情況。這個習慣幫我避免了多次遠程壓測斷連后無法確認結果的麻煩。5.5 壓測結果如何判斷是否成功最后聊一下怎么判斷壓測結果。stress本身不會輸出一個“通過/失敗”的結論你需要自己綜合判斷。我個人的判斷標準有三條壓測期間系統沒有出現嚴重錯誤日志dmesg中沒有OOM、panic、硬件報錯。壓測結束后SSH和基礎服務依然正常響應負載能回落到正常水平。壓測期間業務進程如果有沒有出現崩潰或者長時間無響應。這三條都滿足這臺機器基本可以認定在當前壓測配置下是穩定的。如果再嚴格一點可以對比壓測前后/proc/cpuinfo和smartctl的磁盤健康狀態確認沒有新增的硬件隱性故障。結尾我在實際使用stress過程中最大的體會是工具本身簡單到不行真正的復雜度在于你怎么設計壓測方案和解讀壓測結果。壓測之前先想清楚要驗證什么再動手跑數據才有參考價值。最后分享一個小技巧如果你需要定期做壓力測試可以寫一個腳本把stress和stress-ng配合使用先用stress做快速冒煙驗證確認基本功能正常后再用stress-ng做專項深度壓測這樣兼顧了效率與深度我在多個項目的服務器驗收中都是這么做的效果一直不錯。本文還有配套的精品資源點擊獲取