說明:在寫這篇文章之前,本人也不曾了解LTP是幹嘛的,直到參加一次技術沙龍才了解到它是用來對linux系統進行穩定性測試的一個開源工具,演講人是世紀佳緣運維部門的技術老總!平時我們這些做運維朋友們都很少涉及到系統的測試,因為覺得linux本生就很穩定,是以就沒有必要去做測試,但是系統是更新的,同樣linux的核心是也在更新的,那新系統是否就适合我們的業務,是否就比就系統穩定可靠呢!!我想大部分人憑直覺認為新系統就比老系統好吧!特别是對那些業務量大,通路量較高的大型網站來說,穩定的系統是多麼的重要!!!
@@@@-本人在網上也找了好久LTP的介紹,大都是雷同的,而且不知道COPY了多少遍,且時間已久,要想找到完整且好的非常的困難,從這點也可以看出,幾乎很少有人做穩定性測試這方面的工作了!!
本人關于LTP的一些說明大都還是來自于網上,我想這個應該都是一樣的!
=============================LTP介紹開始===================================
LTP--Linux Test Project
簡介:
LTP套件是由 Linux Test Project 所開發的一套系統測試套件。它基于系統資源的使用率統計開發了一個測試的組合,為系統提供足夠的壓力。
通過壓力測試來判斷系統的穩定性和可靠性。
壓力測試是一種破壞性的測試,即系統在非正常的、超負荷的條件下的運作情況 。用來評估在超越最大負載的情況下系統将如何運作,是系統在正常的情況下對某種負載強度的承受能力的考驗 。
使用LTP測試套件對Linux作業系統進行超長時間的測試,重點在于Linux使用者環境相關的工作負荷。而并不是緻力于證明缺陷。
壓力測試的設計
重點: 1測試選擇。
2評價系統資源使用率。
3分析核心代碼覆寫率。
4評價最終壓力測試
1. 測試選擇--包括達成兩方面目的的測試：
- 測試應該可以得到 CPU（s）、記憶體、I/O 和網絡等主要核心區域的高水準的資源使用率。
- 測試應該充分地覆寫核心代碼，以幫助支援自其結果中生成的穩定性聲明。
2. 評價系統資源使用率
所選擇的測試的組合必須給系統的資源帶來足夠的壓力。Linux 核心的四個主要方面可以影響系統的 響應和執行時間：
- CPU：用于在機器的 CPU（s）上處理資料的時間。
- Memory：用于自真實存儲器中讀寫資料的時間。
- I/O：用于自磁盤存儲器讀寫資料的時間。
- Networking：用于自網絡讀寫資料的時間。
系統資源使用率評價階段通常需要多次嘗試才能得到合适的測試組合，并得到期望水準的使用率。當确定測試組合時，過度利用總是一個至關重要的問題。例如，如果選擇的組合過于受 I/O 所限，可能會 導緻 CPU 的測試結果不好，反之亦然。方法的這一部分主要是大量的試驗和出錯，直到所有資源達到期望水準。
當選定一個組合後，測試必須長時間運作以準确評價資源的使用率。測試運作的時間長短取決于每個測試的長度。假如多個測試同時運作，則時間必須足夠長以使得這些測試中最長的那個可以完成。在這個評價過程中，sar 工具也應該在運作。在評價運作的結論中，您應該收集并評價所有四種資源的使用率水準。
3. 分析核心代碼覆寫率
獲得足夠的核心覆寫率是系統壓力測試的另一個職責。盡管所選的測試組合充分地利用了四種主要資源，它也有可能隻是執行了核心的一小部分。因而，應該對覆寫率進行分析以確定組合可以成為一個系統壓力測試，而不是一個系統負載生成器。
4. 之是以要執行方法中的這最後一步，是為了對系統壓力測試進行核實。在一個被認為是穩定的核心上執行壓力測試； 通常，發行版本中的核心可以滿足這一要求，但不總是如此。要長時間地執行壓力測試，同時運作sar 工具，原因有以下兩點：
-長時間運作有助于發現組合中的所有問題，否則，在短時間的“取樣測試（sniff test）”中這些問題可能會被忽略。
-sar 生成的資料構成以後測試運作中進行比較的基線。
長時間運作結束後，現在可以基于收集的所有資料來決定這個測試組合是否是系統壓力測試的合适候選者。
LTP 測試方法
測試方法有兩個階段:
階段1: 初始測試
階段2: 壓力測試
初始測試 --- 是開始測試的必要條件。初始測試包括LTP測試套件在硬體和作業系統上成功運轉,這些硬體和作業系統将用于可靠性運轉。LTP測試套件包附帶的驅動程式腳本runalltests.sh用于驗證核心。這個腳本串行地運作一組成包的測試,并報告全部結果。也可以選擇同時并行地運作幾個執行個體。在執行runltp腳本的時，可以指定參數添加需要的測試的項目（在/testscripts内）,初始測試的測試腳本是runalltests.sh或runltp(runltp預設執行的内容與runalltests相同),預設地,這個腳本執行:
- 檔案系統壓力測試。
- 硬碟 I/O 測試。
- 記憶體管理壓力測試。
- IPC 壓力測試。
- SCHED 測試。
- 指令功能的驗證測試。
- 系統調用功能的驗證測試。
壓力測試 --- 可以驗證産品在系統高使用率時的健壯性。作為runalltests.sh的補充,特别設計了一個名為ltpstress.sh的測試場景,在使用網絡與記憶體管理的同時并行地運作大範圍的核心元件,并在測試系統上生成高壓力負荷。
ltpstress.sh也是LTP測試套件的一部分。這個腳本并行地運作相似的測試用例,串行地運作不同的測試用例,這樣做是為了避免由于同時通路同一資源或者互相幹擾而引起的間歇性故障。測試内容同runltp,不同點在于runltp可以指定測試項進行組合測試，而runalltests.sh則會全部執行。預設地,這個腳本執行:
- NFS 壓力測試。
- 數學 (浮點) 測試。
- 多線程壓力測試。
- IPC (pipeio, semaphore) 測試。
- 網絡壓力測試。
LTP工作組在設計Linux 核心壓力測試腳本 ltpstress.sh 時使用了這一設計方法，為給系統提供足夠的壓力，LTP工作組對這個組合測試進行了分析，以确定 Linux 核心的哪些部分在測試執行中得到了使用。然後，修改了組合測試，在保持期望的高強度系統壓力的同時提高代碼覆寫率的百分比。最終得到的壓力測試涵蓋了Linux 核心的足夠多部分，有助于穩定性聲明，并且有系統使用情況和核心代碼覆寫情況的資料來支援它。
有兩個開放源代碼工具可以幫助進行 Linux 核心的代碼覆寫率分析：
- gcov：一個由 LTP 維護的開放源代碼工具。這個工具分析核心代碼的覆寫率，并報告哪些行、函數和分支被覆寫以及它們被通路了多少次。
- lcov：另一個由 IBM 開發，由 LTP 維護的開放源代碼工具。 這個工具由一組建構于基于文本的 gcov 輸出之上的 Perl 腳本構成，以實作基于 HTML 的輸出。輸出包括覆寫率百分比、圖表以及概述頁，可以快速浏覽覆寫率資料。可以自LTP首頁找到這兩個工具。
lcov 工具會生成一棵完整的HTML 樹，其中包含有核心中代碼的每一行以及關于每一行執行了 多少次的資料（如果有的話）。這個工具會量化覆寫率資料并生成關于核心中每一部分和 檔案覆寫率的百分比數字。
核心的代碼覆寫率分析隻是在ltpstress.sh的設計和開發過程中用到，目的是保證lptsress.sh的可用性，我們在實際測試的時候就不需要再做核心的代碼覆寫率分析了。
系統監控
LTP 測試套件附帶的 top 工具是經過修改的，用作系統監控工具。使用 top 可以實時地觀察處理器的行為。改進的 top 工具具有附加的功能，可以将 top 結果的快照儲存到檔案中，并給出結果檔案的平均總結，包括 CPU、記憶體和交換空間使用率等資訊。
在我們的測試中，sar工具每 10 秒鐘截取一次系統使用率的快照，并儲存到結果檔案。
測試之前所有標明的測試系統的硬體配置盡可能相同。去掉額外的硬體以減少潛在的硬體故障。在映像安裝過程中選擇最低的安全選項。預留至少 2 GB 的硬碟空間以儲存 top 資料檔案和 LTP 日志檔案。
在測試期間系統不要受到幹擾。偶爾通路一下系統以确認測試仍在進行是可以接受的。确認的手段包括使用 ps 指令、檢查 top 資料和檢查 LTP 日志資料。
源安裝包目錄清單:
doc: 該目錄是說明檔案和幫助文檔的所在地,這個目錄中對LTP的内容和每個工具都有詳細的說明
testscripts: 該目錄中存儲的是可執行的測試腳本,不同方面的測試腳本的集合
testcases: 該目錄存儲了所有LTP測試套件中所使用的測試用例的源碼
runtest: 該目錄中的每個檔案都是要執行的測試用例的指令集合,每個檔案針對測試的不同方面
（用于連結testscripts内的測試腳本和testcases測試項目）
include: LTP測試套件的頭檔案目錄,定義了LTP自身的資料結構和函數結構
lib: LTP測試套件運作時自身需要的庫檔案,定義了LTP自身的各種函數
bin: 存放LTP測試的一些輔助腳本
results: 測試結果預設存儲目錄
output: 測試日志預設存儲目錄
share: 腳本使用說明目錄
pan: 該目錄存儲的是LTP測試套件的測試驅動程式pan
pan工作原理：LTP測試套件有一個專門的測試驅動程式pan，具體的測試用例的執行都是由pan來調用執行，它可以跟蹤孤兒程序和抓取測試的輸出資訊。它的工作方式是這樣的：
從一個測試指令檔案中讀取要測試的條目的要執行的指令行，然後等待該項測試的結束，并記錄詳細的測試輸出。預設狀态下pan會随機的選擇一個指令行來運作，可以指定在同一時間要執行測試的次數。
pan會記錄測試産生的詳細的格式複雜的輸出，但它不進行資料的整理和統計，資料整理統計的工作由scanner來完成，scanner是一個測試結果分析工具，它會了解pan的輸出格式，并輸出成一個表格的
形式來總結那些測試passed或failed.
LTP測試套件通過執行測試腳本runalltests.sh(或runltp或runltplite.sh)或/testscripts内的測試腳本調用驅動程式pan執行/testcases内的測試項目。
檔案清單:
IDcheck.sh : 檢查系統是否缺少執行LTP測試套件所需的使用者和使用者組，如果缺少則為LTP測試套件建立所需的使用者和使用者組。
runltplite.sh : 這個腳本用來測試LTP安裝，也可用來對測試套件的子項目進行測試。
ver_linux : 這個腳本是擷取硬體、軟體、環境資訊。
安裝: ltp-full-20110915.bz2
下載下傳位址: http://ltp.sourceforge.net/
1> tar xvjf ltp-XXXXXXXX.bz2
2> cd ltp
3> ./configure
4> make all
5> make install
##不指定安裝路徑的話,将會預設安裝到/opt/ltp目錄
LTP的實際運作
實際運作當中，您還需要配置一些必要的服務才可以正确的運作LTP的測試套件，以ltprunall.sh為例，它是不需要配置其他服務就可以運作的，但是對于ltpstress.sh，是需要配置一些相關服務之後才可以正确運作的，需要您配置的服務如下：
配置rsh和rlogin服務，使使用者能以root身份不需密碼驗證直接登入本機。
測試運作
1. 初始測試
./runltp -p -l /tmp/resultlog.20111207 -d /tmp -o /tmp/ltpscreen.20111207 -t 24h
或者: ./runalltests.sh
-p:人為指定日志格式,保證日志為可讀格式
-l:記錄測試日志的檔案
-d:指定臨時存儲目錄,預設為/tmp
-o:直接列印測試輸出到/tmp/ltpscreen.20111207
-t:指定測試的持續時間
-t 60s = 60 seconds
-t 45m = 45 minutes
-t 24h = 24 hours
-t 2d = 2 days
2. 壓力測試
在使用testscripts/ltpstress.sh腳本之前需要對系統進行配置
-rsh必須配置完畢并在運作。
-核心支援NFS，并且安裝NFS軟體，通過網絡測試。
-"sar"或"top"工具需要被安裝，執行ltpstress時需要添加"sar"或"top"工具。 # yum install sysstat
./ltpstress.sh -d /tmp/sardata -l /tmp/ltpstress.log -I /tmp/iofile -i 5 -m 128 -t 24 -S
-d:指定sar或top記錄檔案,預設/tmp/ltpstress.data
-l:記錄測試結果到/tmp/ltpstress.log (小寫L)
-I:記錄"iostat"結果到iofile,預設是/tmp/ltpstress.iostat (大寫i)
-i:指定sar或top快照時間間隔,預設為10秒
-m: 指定最小的記憶體使用,預設為: RAM + 1/2 swap
-n:不對網絡進行壓力測試
-S :用sar捕捉資料
-T:利用LTP修改過的top工具捕捉資料
-t: 指定測試時間
測試結果分析
預設情況下，測試結果放在/tmp
ltpstress.log ---- 記錄相關日志資訊，主要是測試是否通過(pass or fail)
ltpstress.data ---- sar工具記錄的日子檔案，包括cpu,memory,i/o等
ltpstress.611.output1 ---- 對應stress.part1，測試指令的一些輸出資訊
ltpstress.611.output2 ---- 對應stress.part2，測試指令的一些輸出資訊
ltpstress.611.output3 ---- 對應stress.part3，測試指令的一些輸出資訊
cpu 平均使用率：#sar -u -f ltpstress.data
memory 平均使用率：#sar -r -f ltpstress.data
分析：
ltpstress.log 将所有FAIL過濾出來，得到完整的所有FAIL的testcases。
方法如下：用sort把FAIL的項排序，再用uniq排除重複項輸出到一個檔案就可以了：
grep FAIL ltpstress.log | sort | uniq >failcase.txt
至此，得到的failcase.txt為所有FAIL的testcases名字。要注意分析case失敗的原因是什麼.
并下結論：是配置的問題，還是穩定性的問題(有失敗也有成功)。并将結論加注在failcase.txt中，友善檢視。
使用者自定義測試:
想要有選擇的自定義測試項目,可以如下方法操作
建立指令檔案,這個指令檔案包括兩部分: tag和test case
tag即為标簽項,起到一個說明的目的,友善我們知道是幹什麼的.
test case即為要測試的項目,此部分為/opt/ltp/testcases/bin/下的指令加上相關的選項
例如:
#Tag Test case
#------------------------------------
mtest01 mtest01 -p 10
mmstress mmstress -x 100
fork01 fork01
chdir01 symlink01 -T chdir01
假如此檔案名定義為self.sh
則可運作:
./runltp -p -l self.log -f /opt/ltp/self.sh
如果未指定日志檔案存儲路徑将會預設儲存到/opt/ltp/results/self.log下
如果-f選項後的檔案不指定絕對路徑,将會預設的到目錄/opt/ltp/runtest下去尋找
此例中假如self.sh檔案在/opt/ltp/runtest目錄下,隻需-f self.sh即可.如不在将會提示在runtest目錄下找不到
檔案self.sh 如:
./runltp -p -l self.log -f self.sh
INFO: creating /opt/ltp/results directory
cat: /opt/ltp/runtest/self.sh: 沒有那個檔案或目錄
FATAL: unable to create command file
例如要單獨測試runtest目錄裡的項目,以tracing為例,則可:
./runltp -p -l tracing.log -f tracing
結果如下:
#cat results/tracing.log
Test Start Time: Thu Dec 8 18:26:03 2011
-----------------------------------------
Testcase Result Exit Value
-------- ------ ----------
ftrace-stress-test PASS 0
-----------------------------------------------
Total Tests: 1
Total Failures: 0
Kernel Version: 2.6.18-194.el5
Machine Architecture: i686
Hostname: HA02
同樣可以對檔案進行修改,取消我們不需要測試的部分,如下:
runtest中stress.part1,stress.part2,stress.part3。
如修改 stress.part1 中有這樣一個測試 mem02,根據閱讀testcases/kernel/mem/mem/mem02.c 源代碼,可将他修改為 mem02 -m 15,意思是測試 15m 記憶體。同樣的也可以在 stress.part1,stress.part2,stress.part3 中添加、删除一些測試,如我們測試時就把
stress.part3 中關于 swap 交換分區的去掉
#swapoff01 swapoff01
#swapoff02 swapoff02
#swapon01 swapon01
#swapon02 swapon02
有個IBM的LTP測試,不過時間較老為2004年的,而且說的太簡單,最重要的是它裡面的圖示資料是怎麼來的,本人還不知道是怎麼來的呢,望知道的朋友能夠提出您的寶貴意見,本人将非常感謝,或者能夠發帖出來與大家分享一下!!!
<a target="_blank" href="http://blog.51cto.com/attachment/201112/120514572.jpg"></a>
<a target="_blank" href="http://blog.51cto.com/attachment/201112/120527411.jpg"></a>
此圖挺好,本人就是不知道用什麼工具來實作,期待ING!!!!!!!
可以參考資料:使用 gnuplot 在網頁中顯示資料
<a target="_blank" href="http://www.ibm.com/developerworks/cn/aix/library/au-gnuplot/#4.Installing%20Gnuplot%7Coutline">http://www.ibm.com/developerworks/cn/aix/library/au-gnuplot/#4.Installing Gnuplot|outline</a>
下面附上top和sar的使用方法,友善參考!
"top"工具
使用方式：top [-] [d delay] [q] [c] [S] [s] [i] [n] [b]
說明：即時顯示 process 的動态
-d 改變顯示的更新速度，或是在交談式指令列( interactive command)按d
-q 沒有任何延遲的顯示速度，如果使用者是有 superuser 的權限，則 top 将會以最高的優先序執行
-c 切換顯示模式，共有兩種模式，一是隻顯示執行檔的名稱，另一種是顯示完整的路徑與名稱
-S 累積模式，會将己完成或消失的子行程 ( dead child process ) 的 CPU time 累積起來
-s 安全模式，将交談式指令取消, 避免潛在的危機。
-i 不顯示任何閑置 (idle) 或無用 (zombie) 的行程
-n 更新的次數，完成後将會退出 top
-b 批次檔模式，搭配 "n" 參數一起使用，可以用來将 top 的結果輸出到檔案内
"sar"工具
sar [options] [-A] [-o file] t [n]
說明：在指令行中，n 和t 兩個參數組合起來定義采樣間隔和次數，t為采樣間隔，是必須有的參數，n為采樣次數，是可選的，sar指令的選項很多，下面隻列出常用選項：
-a 報告檔案讀寫使用情況
-b 報告緩存的使用情況
-c 報告系統調用的使用情況
-d 報告磁盤的使用情況
-h 報告關于buffer使用的統計資料
-m 報告IPC消息隊列和信号量的使用情況
-q 報告運作隊列和交換隊列的平均長度
-R 報告程序的活動情況
-r 報告沒有使用的記憶體頁面和硬碟塊
-u 報告CPU的使用率
-v 報告程序、i節點、檔案和鎖表狀态
-w 報告系統交換活動狀況
本文轉自 zhangzj1030 51CTO部落格，原文連結:http://blog.51cto.com/tech110/737865
![linux-svn解除安裝與安裝[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)