原創|其它|編輯:郝浩|2009-04-24 10:15:30.000|閱讀 396 次
概述:數據的日常維護與優化方法。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
二、數據庫系統的性能監視與優化
1.、性能監視:
1)增長
測量并預測增長,需要收集四種主要的信息:處理器,網絡,存儲,內存。
對像類型 |
|
要收集的值 |
Processor |
|
使用率百分比 |
Network |
|
流量,總字節數 |
Storage |
|
總傳輸數,以操作或塊為單位 |
Memory |
|
使用中的MB數或GB數 |
Database |
|
每個數據庫的大小 |
如果沒有以前管理人員留下來的數據庫性能基準線,則可以自己制做自己的數據庫性能監視基準線。
方法:
以使用一個較小的時間間隔(5-10秒)進行一周,每天24小時,在之后24小時的測量改為每周一次,持續一個月,最后每月一次,并持續兩個月。
有了這些數字之后,首先檢查每天的范圍。按照時間排列這些數字并為它們創建一個圖表。這些數字將顯示一種趨勢,如果數字顯示出一個增長趨勢的
可預測模式,則要注意周測試的最后一次測量,并根據它預測后三個星期的增長模式。如果預測正確,它們應該與你實際采集的周數據接近。采用相同
的方法對月度數據進行測試。如果度量值初始顯示出一個平穩的曲線,你應當進行更長時間的測試,每周一次,至少進行三個月以上。如果測量值呈下
降趨勢,則延遲一周后再進行每天測量。
2、活動和性能
對像類型 |
|
要收集的值 |
Processor |
|
使用率百分比,特別是應用程序相關的進程 |
Network |
|
讀和寫的字節數 |
Storage |
|
讀和寫操作 |
Memory |
|
sql server需要使用的值,以及sql server正在使用的值 |
Database |
|
數據庫活動,連接和鎖 |
得到這些值之后,按時間順序組織它們,計算出最小值,最大值和平均值。如果使得平均有意義,還要計算出集合的標準差,標準差越接近0,平均值越可信。
3、性能監視
對像 |
計數器 |
含義 |
說明 |
Processor |
%Processor Time |
顯示在監視時間內處理器的使用百分比。 |
平均低于75%(低于50%更佳)
|
Memory |
Available Mbytes |
顯示還剩多少內存。從總內存數量中減去這個值就可以算出正在使用的數量 |
應該保持在50MB上
|
|
Page/sec |
|
平均低于20(低于15更佳)
|
LogicalDisk |
%Disk Time |
顯示在監視時間內的讀,寫百分比 |
|
Network Interface |
Bytes Total/sec |
顯示發送和接收的字節數 |
用于規劃網絡帶寬的大小
|
Sql Server:Databases |
Active Transactions |
顯示實例范圍內數據庫的所有活動事務
|
|
SqlServer:General |
User Connections |
顯示被統計的連接到服務器的用戶數量 |
用于規劃內存
|
我通常會使用系統監視器的日志功能,并把結果發送一個制表符分隔的文件。如果只監視一天,我會把收集時間間隔設置為5秒一次,如果要監視更長的時間
,則設置為5分鐘一次。
然后我創建了一個三張表的Excel文件:監視,評估,建議。我會把系統監視器的結果讀到“監視”表中,然后更改列的格式,例如去掉服務器名稱。對于處理
器內存,磁盤,網絡和Sql server計數器,我會使用不同的顏色標記。
在“評估”表中我會創建引用“監視”表中數據的公式,這些公式會計算出最大值,最小值,平均值,標準偏差等。然后我會對這些列中的數據進行評估并使用
不同的顏色標注,例如紅色表示非常正常,綠色表示好,藍色表示差。在這些數字下面我會解釋為什么覺得它好或是不好,以及其他影響它的因素。我還會對測試環
境進行簡單描述。
在“建議”表中我會解釋使用什么方法來解決問題。例如如果連接數以某種頻率增長,并且同時內存使用量多于服務器上安裝的數量,那么服務器正在進行換頁
操作,那么它需要更多內存。
磁盤增長方式
線性增長:
未來使用率=當前使用率+(增長數量*周期個數)
例如:如果數據庫當前每分鐘處理40個事務,并且每年每分鐘增長10個事務,就可以通過這些數值放置到公式中計算出未來3年內數據庫使用的情況
未來3年內使用率=40+(10*3)
幾何增長:
未來使用率=當前使用率+(+增長率)^周期個數
例如:如果數據庫當前是600GB,并且增長率每個月為2%,則未來三年內數據庫大小=600(1+0.02)^36
4、磁盤系統的優化
對于磁盤子系統規劃監視
對像 |
計數器 |
含義 |
說明 |
System |
Processor Queue |
每個處理器平均低于2。 |
例如,在一個雙處理器的機器上,應該保持在低于4的狀態 |
Physical Disk |
%Disk Time |
顯示在監視時間內的讀,寫百分比
|
平均低于50% |
|
Avg.Disk QueueLength |
平均每個磁盤應該低于2。 |
例如,對于一個5磁盤的陣列,此值應該低于10
|
|
Avg.Disk Reads/sec |
用戶規劃磁盤和CPU |
該低于磁盤容量的85%
|
|
vg.Disk Writes/sec |
用戶規劃磁盤和CPU |
應該低于磁盤容量的85% |
SQL Server:Buffer Manager |
Buffer Cache HitrATIO |
應該超過90%(理想狀態下接近99%) |
|
|
Page Life Expectancy |
用于規劃內存(應該保持在300秒以上) |
用于規劃內存
|
|
Transactions/sec |
用戶規劃磁盤和CPU
|
|
|
Data Files Size KB |
用于規劃磁盤子系統
|
|
|
Percent Log Used |
用于規劃磁盤子系統 |
|
|
|
|
|
假設:數據庫的工作負載在峰值時段內為每秒600個讀事務,200個寫事務, 每個磁盤的標準是300IOPS及最大255 IOPS
1.使用RAID1R的配置中,寫事務的數量是雙倍,因此它將此吞吐量的級別調整為600個讀事務,和400個寫事務.或者1000 IOPS.如果這些I/O負載分攤到兩個磁盤,
那么每個磁盤就是500IOPS,遠遠超出了每個磁盤的標準值.
所以RAID1不滿足這個數據庫的負載.
2.在RAID 5配置中,由于增加了4倍的寫事務個數,所以提高了總體的I/O量.由此I/O吞吐量級別上升到了每秒1400(600+200*4).不像RAID1,RAID5配置固定磁盤個數,
所以在RAID5 配置中,你可以使用多個磁盤來分擔吞吐量,以符合每個磁盤最大255IOPS的負載.
計算出磁盤數量:1400/255=5.49.由于5.49不是一個整數值,所以應該將其上升到下一個整數值,所以應該是6.
3.在RAID 10配置中,和RAID1配置一樣的寫事務的數量翻一倍.
計算出磁盤數量:1000/255=3.9 .所以最少要4個物理磁盤才能滿足.
4.內存:
并發是指300秒持續時間內的執行數量.
1.連接上下文指的是需要支持用戶連接的數據庫結構.連接到sql server的每個用戶大約需要500KB.確定并發用戶的最大數量之后,將500*最大并發連接數,就可以確定用戶的內在需要.
2.存儲過程緩沖內存:
1) 首先收集在數據庫應用程序中包含所有的查詢類型.然后計算每個查詢文本在內在中需要的存儲空間數量.請記住,執行此計算時,文本中每個字符都是一個字節.
例:
如果一個特定的存儲過程中包含了4000個字符,則此查詢的文本在內存中大概占據4KB.
2) 對每個查詢評估最大的并發執行數量.
例:
你可能估算出相同的存儲過程的并發執行的最大的數量為500.則需要的緩存為4*501 (一個用于共享的查詢計劃,500用于執行上下文)為2004KB.
3.緩沖區內存:(這個是最大的內存用戶)
例:
查詢A:有30個用戶并發執行,每個查詢有400KB數據輸出, 共120MB
查詢B:有20個用戶并發執行,每個查詢有300KB數據輸出,共60MB
查詢C: 有50個用戶并發執行,每個查詢有100KB數據輸出,共50MB
三個種查詢總共需要230MB內存,做為緩沖區.
本站文章除注明轉載外,均為本站原創或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn
文章轉載自:博客園