說明:在寫這篇文章之前,本人也不曾瞭解LTP是幹嘛的,直到參加一次技術沙龍才瞭解到它是用來對linux系統進行穩定性測試的一個開源工具,演講人是世紀佳緣運維部門的技術老總!平時我們這些做運維朋友們都很少涉及到系統的測試,因爲覺得linux本生就很穩定,因此就沒有必要去做測試,但是系統是更新的,同樣linux的內核是也在更新的,那新系統是否就適合我們的業務,是否就比就係統穩定可靠呢!!我想大部分人憑直覺認爲新系統就比老系統好吧!特別是對那些業務量大,訪問量較高的大型網站來說,穩定的系統是多麼的重要!!!
@@@@-本人在網上也找了好久LTP的介紹,大都是雷同的,而且不知道COPY了多少遍,且時間已久,要想找到完整且好的非常的困難,從這點也可以看出,幾乎很少有人做穩定性測試這方面的工作了!!
本人關於LTP的一些說明大都還是來自於網上,我想這個應該都是一樣的!
=============================LTP介紹開始===================================
LTP–Linux Test Project
簡介:
LTP套件是由 Linux Test Project 所開發的一套系統測試套件。它基於系統資源的利用率統計開發了一個測試的組合,爲系統提供足夠的壓力。
通過壓力測試來判斷系統的穩定性和可靠性。
壓力測試是一種破壞性的測試,即系統在非正常的、超負荷的條件下的運行情況 。用來評估在超越最大負載的情況下系統將如何運行,是系統在正常的情況下對某種負載強度的承受能力的考驗 。
使用LTP測試套件對Linux操作系統進行超長時間的測試,重點在於Linux用戶環境相關的工作負荷。而並不是致力於證明缺陷。
壓力測試的設計
重點: 1測試選擇。
2評價系統資源利用率。
3分析內核代碼覆蓋率。
4評價最終壓力測試
測試選擇–包括達成兩方面目的的測試：
- 測試應該可以得到 CPU（s）、內存、I/O 和網絡等主要內核區域的高水平的資源利用率。
- 測試應該充分地覆蓋內核代碼，以幫助支持自其結果中生成的穩定性聲明。
評價系統資源利用率
所選擇的測試的組合必須給系統的資源帶來足夠的壓力。Linux 內核的四個主要方面可以影響系統的 響應和執行時間：
- CPU：用於在機器的 CPU（s）上處理數據的時間。
- Memory：用於自真實存儲器中讀寫數據的時間。
- I/O：用於自磁盤存儲器讀寫數據的時間。
- Networking：用於自網絡讀寫數據的時間。
系統資源利用率評價階段通常需要多次嘗試才能得到合適的測試組合，並得到期望水平的利用率。當確定測試組合時，過度利用總是一個至關重要的問題。例如，如果選擇的組合過於受 I/O 所限，可能會 導致 CPU 的測試結果不好，反之亦然。方法的這一部分主要是大量的試驗和出錯，直到所有資源達到期望水平。
當選定一個組合後，測試必須長時間運行以準確評價資源的利用率。測試運行的時間長短取決於每個測試的長度。假如多個測試同時運行，則時間必須足夠長以使得這些測試中最長的那個可以完成。在這個評價過程中，sar 工具也應該在運行。在評價運行的結論中，您應該收集並評價所有四種資源的利用率水平。
分析內核代碼覆蓋率
獲得足夠的內核覆蓋率是系統壓力測試的另一個職責。儘管所選的測試組合充分地利用了四種主要資源，它也有可能只是執行了內核的一小部分。因而，應該對覆蓋率進行分析以確保組合可以成爲一個系統壓力測試，而不是一個系統負載生成器。
之所以要執行方法中的這最後一步，是爲了對系統壓力測試進行覈實。在一個被認爲是穩定的內核上執行壓力測試； 通常，發行版本中的內核可以滿足這一要求，但不總是如此。要長時間地執行壓力測試，同時運行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 壓力測試。
內存管理壓力測試。
文件系統壓力測試。
數學 (浮點) 測試。
多線程壓力測試。
硬盤 I/O 測試。
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身份不需密碼驗證直接登錄本機。
測試運行
- 初始測試
./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
- 壓力測試
在使用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年的,而且說的太簡單,最重要的是它裏面的圖標數據是怎麼來的,本人還不知道是怎麼來的呢,望知道的朋友能夠提出您的寶貴意見,本人將非常感謝,或者能夠發帖出來與大家分享一下!!!
http://www.ibm.com/developerworks/cn/linux/l-rel/ 可以看看!!!
此圖挺好,本人就是不知道用什麼工具來實現,期待ING!!!!!!!
可以參考資料:使用 gnuplot 在網頁中顯示數據
http://www.ibm.com/developerworks/cn/aix/library/au-gnuplot/#4.Installing Gnuplot|outline
下面附上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 報告系統交換活動狀況