CPU 內存檢測

 在任務管理器中看到sql server 2000進程的內存佔用，而在sql server 2005中，不能在任務管理器中查看sql server 2005進程的內存佔用，要用

如下語句查看sql server 的實際內存佔用：

select * from sysperfinfo where counter_name like '%Memory%'

其中, Total Server Memory 表示內存佔用。

 

select locked_page_allocations_kb  from sys.dm_os_process_memory
Select sum(awe_allocated_kb)  as [AWE allocated, kb] From sys.dm_os_memory_clerks

 

要適當限制sql server 的內存佔用，要給sql server設置最大值，不要把物理內存所有給sql server，要給windows系統保留適當大小的內存。

對於大物理內存，要在windows server 2003系統的boot.ini中增長 /PAE 參數，若是是AMD的CPU，還要加 /usepmtimere 參數，要在本地組策略裏設置「鎖定內存中的頁」，在sql erver 2005 中選中AWE,並設置最小值和最大值， 重啓服務器或sql server服務便可，詳細請參考windows server 2003和sql server 2005中的「啓用對4GB以上物理內存的支持」的幫助文檔。

 

 

 

1、sql 數據庫CPU瓶頸

對於SQL Server的一個工做進程的狀態有不少，主要狀態有運行中（RUNNING)、可運行（RUNNABLE)和掛起(SUSPENED)3種。

經過查看系統監視計數器Processor:% Processor Time，能夠肯定CPU瓶頸。若是這個計數器的值很高。好比持續15-20分鐘超80%，就意味着CPU出現了瓶頸。

 

當您懷疑計算機硬件是影響SQL Server運行性能的主要緣由時，能夠經過SQL Server Performance Monitor監視相應硬件的負載，以證明您的猜想並找出系統瓶頸。下文將介紹一些經常使用的分析對象及其參數。

　　Memory: Page Faults / sec

　　若是該值偶爾走高，代表當時有線程競爭內存。若是持續很高，則內存多是瓶頸。

　　Process: Working Set

　　SQL Server的該參數應該很是接近分配給SQL Server的內存值。在SQL Server設定中，若是將"set working set size"置爲0, 則Windows NT會決定SQL Server的工做集的大小。若是將"set working set size"置爲1，則強制工做集大小爲SQLServer的分配內存大小。通常狀況下，最好不要改變"set working set size"的缺省值。

　　Process:%Processor Time

　　若是該參數值持續超過95%，代表瓶頸是CPU。能夠考慮增長一個處理器或換一個更快的處理器。

　　Processor:%Privileged Time

　　若是該參數值和"Physical Disk"參數值一直很高，代表I/O有問題。可考慮更換更快的硬盤系統。另外設置Tempdb in RAM，減低"max async IO"，"max lazy writer IO"等措施都會下降該值。

　　Processor:%User Time

　　表示耗費CPU的數據庫操做，如排序，執行aggregate functions等。若是該值很高，可考慮增長索引，儘可能使用簡單的表聯接，水平分割大表格等方法來下降該值。

　　Physical Disk:Avg.Disk Queue Length

　　該值應不超過磁盤數的1.5~2倍。要提升性能，可增長磁盤。

　　注意:一個Raid Disk實際有多個磁盤。

　　SQLServer:Cache Hit Ratio

　　該值越高越好。若是持續低於80%，應考慮增長內存。 注意該參數值是從SQL Server啓動後，就一直累加記數，因此運行通過一段時間後，該值將不能反映系統當前值。

檢測CPU壓力的另外一個方法是計算可運行狀態下的工做進程數量，經過執行以下的DMV查詢能夠獲得這個信息：

SELECT COUNT(*) AS workers_waiting_for_cpu, t2.Scheduler_id

FROM sys.dm_os_workers AS t1, sys.dm_os_schedulers AS t2

WHERE t1.state = 'RUNNABLE' AND t1.scheduler_address=t2.scheduler_address

AND t2.scheduler_id < 255

GROUP BY t2.scheduler_id

也能夠執行以下的查詢獲得工做進程在可運行狀態下花費的時間：

SELECT SUM(signal_wait_time_ms) FROM sys.dm_os_wait_stats

下面查詢是找出每次執行佔用CPU最多的前100位查詢：

SELECT TOP 100 total_worker_time/execution_count AS avg_cpu_cost, plan_handle, execution_count,

(SELECT SUBSTRING(text, statement_start_offset/2+1,

(CASE WHEN statement_end_offset = -1 THEN LEN(CONVERT(nvarchar(max), text)) * 2

ELSE statement_end_offset END - statement_end_offset)/2)

FROM sys.dm_exec_sql_text(sql_handle)) AS query_text

FROM sys.dm_exec_query_stats

ORDER BY avg_cpu_cost DESC

稍作修改，找出運行最頻繁的查詢：

SELECT TOP 100 total_worker_time/execution_countASavg_cpu_cost, plan_handle, execution_count,

(SELECT SUBSTRING(text,statement_start_offset/2+1,

(CASE WHEN statement_end_offset = -1 THEN LEN(CONVERT(nvarchar(max), text)) * 2

ELSE statement_end_offset END - statement_end_offset)/2)

FROM sys.dm_exec_sql_text(sql_handle)) AS query_text

FROM sys.dm_exec_query_stats

ORDER BY execution_count DESC

可使用下列系統監視性能計數器查看編譯和重編譯的速度：

1. SQLServer: SQL Statistics: BatchRequests/Sec（每秒批處理請求數）

2. SQLServer: SQL Statistics: SQLCompilations/Sec（每秒SQL編譯次數）

3. SQLServer: SQL Statistics: SQLRecompilations/Sec（每秒SQL重編譯次數）

還能夠經過下面語句獲得SQLServer在優化查詢計劃上花費的時間：

SELECT * FROM sys.dm_exec_query_optimizer_info

WHERE counter='optimizations' OR counter = 'elapsed time'

下面查詢找到被編譯得最多的前10位查詢計劃：

SELECT TOP 10 plan_generation_num, execution_count,

(SELECT SUBSTRING(text, statement_start_offset/2+1,

(CASE WHEN statement_end_offset = -1 THEN LEN(CONVERT(nvarchar(max), text)) * 2

ELSE statement_end_offsetEND-statement_end_offset)/2)

FROM sys.dm_exec_sql_text(sql_handle))ASquery_text

FROM sys.dm_exec_query_stats

WHERE plan_generation_num> 1

ORDER BY plan_generation_num DESC

 

2、sql 數據庫內存瓶頸

內存有壓力時，一個查詢計劃可能得移出內存。若是這個計劃被再次提交執行，就必須再優化一次，而因爲查詢優化是CPU密集型運算，這就會給CPU帶來壓力。一樣，內存有壓力時，數據庫頁面可能須要被移出緩衝區池。若是這些頁面很快就再次被選中，就會致使更多的物理IO。

一般所說的內存指的是服務器上的可用物理內存（既RAM）。還有另一種內存叫作虛擬地址空間（VAS）或虛擬內存。在Windows系統上，全部位應用程序都有一個GB的進程地址空間，用來獲取最大GB的物理內存。在GB的可用內存以外，進程還能夠在用戶模式下獲得GB的VAS，另外GB保留只能經過內核模式獲取。要想更改這個配置，能夠在boot.ini文件中使用/3GB switch。

常見的操做系統機制是頁面調試，它使用一個交換文件來存儲最近未使用的部分進程內存。當這一內存被再次引用時，它就直接從交換文件中讀取（或調入）物理內存。

 

能夠經過性能計數器，監測下面參數：

1. 內存：可用字節（Available Bytes）

2. SQL Server:緩衝管理器：緩存命中率（Buffer Cache Hit Ratio）指的是那些不用經過磁盤讀取而直接在緩衝區池中找到的頁的比例。對於大多數產品工做負荷而言，這個值應該是多。（應該是越大越好）

3. SQL Server:緩衝管理器：頁平均壽命（Page Life Expectancy）指的是一個沒有被引用的頁在緩衝區池中保留的秒數。若是數值較低，則說明緩衝區池遇到了內存不足的狀況。

4. SQL Server:緩衝管理器：檢查點頁/秒（Checkpoint Pages/Sec）指的是被檢查點刷新的頁數，或者要求全部髒頁被刷新的其它操做的數目。它能顯示工做負荷中增長的緩衝區池活動量。

5. SQL Server:緩衝管理器：延遲寫入/秒（Lazywrites/Sec）指的是緩衝管理器的延遲寫入器寫入的緩衝數目，它的做用相似於前面提到的檢查點頁/秒。

 

懷疑內存不足時：

方法1：

【監控指標】：Memory Available MBytes ，Memory的Pages/sec， page read/sec， Page Faults/sec

【參考值】：

若是 Page Reads/Sec 比率持續保持爲 5，表示可能內存不足。

Page/sec 推薦00-20（若是服務器沒有足夠的內存處理其工做負荷，此數值將一直很高。若是大於80，表示有問題）。

方法2：根據Physical Disk 值分析性能瓶頸

【監控指標】：Memory Available MBytes ，Pages read/sec，%Disk Time 和 Avg.Disk Queue Length

【參考值】：%Disk Time建議閾值90%

當內存不足時，有點進程會轉移到硬盤上去運行，形成性能急劇降低，並且一個缺乏內存的系統經常表現出很高的CPU利用率，由於它須要不斷的掃描內存，將內存中的頁面移到硬盤上。

懷疑內存泄漏時

【監控指標】：Memory Available MBytes ，Process\Private Bytes和Process\Working Set，PhysicalDisk/%Disk Time

【說明】：

Windows資源監控中，若是Process\Private Bytes計數器和Process\Working Set計數器的值在長時間內持續升高，同時Memory\Available bytes計數器的值持續下降，則極可能存在內存泄漏。內存泄漏應該經過一個長時間的，用來研究分析當全部內存都耗盡時，應用程序反應狀況的測試來檢驗。

 

 

 

CPU瓶頸問題

一、System\%Total processor time若是該值持續超過90%，且伴隨處理器阻塞，則說明整個系統面臨着處理器方面的瓶頸.

注：在某些多CPU系統中，該數據雖然自己並不大，但CPU之間的負載情況極不均衡，此時也應該視做系統產生了處理器方面的瓶頸.

二、排除內存因素，若是Processor %Processor Time計數器的值比較大，而同時網卡和硬盤的值比較低，那麼能夠肯定CPU 瓶頸。（內存不足時，有點進程會轉移到硬盤上去運行，形成性能急劇降低，並且一個缺乏內存的系統經常表現出很高的CPU利用率，由於它須要不斷的掃描內存，將內存中的頁面移到硬盤上。）

形成高CPU使用率的緣由：

頻繁執行程序，複雜運算操做，消耗CPU嚴重

數據庫查詢語句複雜，大量的 where 子句，order by， group by 排序等，CPU容易出現瓶頸

內存不足，IO磁盤問題使得CPU的開銷增長

 

CPU分析

【監控指標】：

System %Processor Time CPU，Processor %Processor Time CPU

Processor%user time 和Processor%Privileged Time

system\Processor Queue Length

Context Switches/sec 和%Privileged Time

【參考值】：

System\%Total processor time不持續超過90%，若是服務器專用於SQL Server，可接受的最大上限是80-85% ，合理使用的範圍在60%至70%。

Processor %Processor Time小於75%

system\Processor Queue Length值，小於CPU數量的總數+1

磁盤I/O分析

【監控指標】：PhysicalDisk/%Disk time，PhysicalDisk/%Idle Time，Physical Disk\ Avg.Disk Queue Length， Disk sec/Transfer

【參考值】：%Disk Time建議閾值90%

Windows資源監控中，若是% Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec頁面讀取操做速率很低，則可能存在磁盤瓶徑。

Processor%Privileged Time該參數值一直很高，且若是在 Physical Disk 計數器中，只有%Disk time 比較大，其餘值都比較適中，硬盤可能會是瓶頸。若幾個值都比較大，那麼硬盤不是瓶頸。若數值持續超過80%，則多是內存泄露。若是 Physical Disk 計數器的值很高時該計數器的值（Processor%Privileged Time）也一直很高，則考慮使用速度更快或效率更高的磁盤子系統。

Disk sec/Transfer 通常來講，該數值小於15ms爲最好，介於15-30ms之間爲良好，30-60ms之間爲能夠接受，超過60ms則須要考慮更換硬盤或是硬盤的RAID方式了.

Average Transaciton Response Time（事務平均響應時間）隨着測試時間的變化，系統處理事務的速度開始逐漸變慢，這說明應用系統隨着投產時間的變化，總體性能將會有降低的趨勢

Transactions per Second（每秒經過事務數/TPS）當壓力加大時，點擊率/TPS曲線若是變化緩慢或者有平坦的趨勢，頗有多是服務器開始出現瓶頸

Hits per Second（每秒點擊次數）經過對查看「每秒點擊次數」，能夠判斷系統是否穩定。系統點擊率降低一般代表服務器的響應速度在變慢，需進一步分析，發現系統瓶頸所在。

Throughput（吞吐率）能夠依據服務器的吞吐量來評估虛擬用戶產生的負載量，以及看出服務器在流量方面的處理能力以及是否存在瓶頸。

Connections（鏈接數）當鏈接數到達穩定狀態而事務響應時間迅速增大時，添加鏈接可使性能獲得極大提升（事務響應時間將下降）

Time to First Buffer Breakdown（Over Time）（第一次緩衝時間細分（隨時間變化））可使用該圖肯定場景或會話步驟運行期間服務器或網絡出現問題的時間。

碰到過的性能問題：

1. 在高併發的狀況下，產生的處理失敗（好比：數據庫鏈接池太低，服務器鏈接數超過上限，數據庫鎖控制考慮不足等）

2. 內存泄露（好比：在長時間運行下，內存沒有正常釋放，發生宕機等）

3. CPU使用偏離（好比：高併發致使CPU使用率太高）

4. 日誌打印過多，服務器無硬盤空間

如何定位這些性能問題：

1. 查看系統日誌，日誌是定位問題的不二法寶，若是日誌記錄的全面，很容易經過日誌發現問題。

好比，系統宕機時，系統日誌打印了某方法執行時拋出out of memory的錯誤，咱們就能夠順藤摸瓜，很快定位到致使內存溢出的問題在哪裏。

2. 利用性能監控工具，好比：JAVA開發B/S結構的項目，能夠經過JDK自帶的Jconsole，或者JProfiler，來監控服務器性能，Jconsole能夠遠程監控服務器的CPU，內存，線程等狀態，並繪製變化曲線圖。

利用Spotlight能夠監控數據庫使用狀況。

咱們須要關注的性能點有：CPU負載，內存使用率，網絡I/O等

3. 工具和日誌只是手段，除此以外，還須要設計合理的性能測試場景

具體場景有：性能測試，負載測試，壓力測試，穩定性測試，浪涌測試等

好的測試場景，能更加快速的發現瓶頸，定位瓶頸

4. 瞭解系統參數配置，能夠進行後期的性能調優

除此之外，還想說個題外話，就是關於性能測試工具的使用問題

在剛開始用Loadrunner和JMeter的時候，作高併發測試時，都出現過沒有把服務器壓垮，這兩個程序本身先倒下的狀況。

若是遇到這個問題，能夠經過遠程調用多個客戶端的服務，分散性能測試工具客戶端的壓力來解決。

說這個的目的是想說，作性能測試的時候，咱們必定要確保瓶頸不要發生在咱們本身的測試腳本和測試工具上