漫遊測試之效能測試(4.6常見資源故障曲線)
4.6.1在linux中注入CPU故障後的曲線
上圖示，系統的上下文切換過多，可能是由於呼叫了系統函式造成的。
上圖，系統多次中斷，可能呼叫了時間函式。
上圖示，CPU使用時間百常高，系統中的程序消耗了較多的CPU時間。
上圖示，個別時間CPU的核心消耗的CPU資源較多。
上圖示，等待IO的CPU時間較大，伺服器的IO等待問題出現了嚴重的問題。
上圖示，等待執行的程序數非常多，CPU繁忙。
上圖示，處於阻塞的程序數較大。
從以上圖示的監控來看，可以確定存在以下幾個問題的現象： 1.CPU使用率較高，上下文切換頻繁，核心資源在某幾個時間點內出現了不夠用的現象(system下的cs、in，CPU下的us、sy）； 2.等待的程序數非常多，程序出現阻塞呼叫的現象(Process 下的r、b）； 3.系統同時在進行IO操作，並且呼叫一系統函式和時鐘等待函式(CPU下的wa)；
結合4.4節列出的原因初步判斷，有可能是由於呼叫了系統函式並且程序阻塞引起的。
如下，注入CPU故障的核心程式碼是通過不調的增加程序來產生的，並且同時呼叫了open系統函式和time時鐘函式，從監控發現的問題原因來看，基本是複合推測的。
def cpu_load_until(rate):
i = 0
list = []
while True:
time.sleep(1)
counters1 = use.readCpuInfo()
# time.sleep(2)
counters2 = use.readCpuInfo()
rate1 = use.calcCpuUsage(counters1, counters2)
# print rate
if rate1 > rate:
break
#print 'cpu use = %d' % rate
proc = multiprocessing.Process(target = run,args=(i,))
proc.start()
list.append(proc)
i += 1
def readCpuInfo():
f = open('/proc/stat')
lines = f.readlines()
f.close()
for line in lines:
line = line.lstrip()
counters = line.split()
if len(counters) < 5:
continue
if counters[0].startswith('cpu'):
break
total = 0
for i in xrange(1, len(counters)):
total = total + long(counters[i])
idle = long(counters[4])
return {'total':total, 'idle':idle}
4.6.2在linux中注入記憶體洩露故障後的曲線
如上圖所示，可用的記憶體量出現一個下降的趨勢；
如上圖所示，虛擬記憶體開始急劇增加，記憶體開始吃緊。
所上圖所示，SI和SO都增加的較大，說明記憶體不夠，已經開始從硬碟到記憶體進行頁面交換了。
綜上圖所示，可以推論，記憶體開始吃緊了。故障注入的程式碼確實是在不斷的寫記憶體。
def mem_append(a=[]):
strd = ""
strd2 = ""
for x in xrange(2048):
strd = strd +str(x)
for y in xrange(2048):
strd2 = strd2 + strd
a.append(strd2)
# print os.system('free')
return a
def mem_append(a=[]):
strd = ""
strd2 = ""
for x in xrange(2048):
strd = strd +str(x)
for y in xrange(2048):
strd2 = strd2 + strd
a.append(strd2)
# print os.system('free')
return a
4.6.3在linux中檢視磁碟指標
如上圖所示，前半段，讀比寫頻繁。但後續，讀和寫都較頻繁。但是，如果從上面的圖示，根本看不出來是否存在IO問題，因為系統存在一定量的讀或者寫IO都是比較正常的現象(上圖採用的模擬CPU故障程式碼的監控資料)。
如何確定此時是否存在IO的問題，其實只需對磁碟進行IO基準測試即可。
測試結果是每秒可以達到134MB，但圖示最大才100000Bytes，所以IO是沒有問題的。