筆記26-徐 SQLSERVER內存分配和常見內存問題

 1 --SQLSERVER內存分配和常見內存問題
  2
  3 --SQLOS:SQL 把他對系統資源調度尤爲是對內存和CPU的調度的功能組件，稱爲SQLOS
  4 --SQL是一個很是喜歡用內存的應用，若是內存不夠，SQL必定會運行得很是艱難
  5 --並且在內存使用上，容易出的問題也比較多
  6
  7
  8 --一、SQL所佔用的內存數量從啓動之後，就不停地增加
  9
10 --二、在Windows2003以上版本運行SQL，內存使用量忽然急劇降低
11 --errorlog:
12 --spid1 a singnificant part of sqlserver process memory has been paged out
13 --this may result in a performance degradation 退化降級
14 --duration:0 seconds working set:1086400  commited:2160928 memory utilization:50%
15
16 --這類問題不是SQL本身致使的，而是Windows感受到急迫的內存壓力，迫使SQL釋放內存
17
18
19 --三、用戶在作操做時，遇到內存申請失敗
20 --錯誤號：701（SQL2005或以上）     17803（SQL2000）   
21 --    8645（2000、2005）         17802（SQL2000）           17189（SQL2005或以上）
22 --SQL內存分紅不少部分，不是用戶想申請多少就申請多少的
23 --在內存分配上，SQL2005比SQL2000有了更明顯的變化。SQL2000簡單一些，SQL2005依然使用
24 --SQL2000的總體框架結構，但有了更復雜的實現方式。因此SQL2005之後的內存問題比SQL2000
25 --相比有了一些變化。
26
27
28 --四、內存壓力致使的性能降低
29 --若是內存緊張，SQL會立刻做出反應，進行自我調節，因此申請內存失敗的概率
30 --不是過高。可是內存對性能的影響會很是顯著。同一條語句，在內存充裕和
31 --緊張的狀況下，速度可能會相差幾十倍，甚至上百倍。經過性能監視器和
32 --動態管理視圖來解決內存壓力
33
34
35 --從操做系統層面看SQL內存分配
36 --各個應用程序包括SQL，都在經過VirtualAlloc之類的API向Windows申請內存。
37 --SQL申請內存都是經過一些公開的API完成的，Windows不會給SQL任何特殊照顧
38
39 --系統不缺內存不表明SQL就必定不缺內存
40
41 --Windows的一些內存術語
42 --虛擬地址空間virtual address space
43 --尋址空間最大是4GB ，在緩存文件paging file  跟物理內存裏
44
45 --物理內存physical memory
46 --頻繁訪問的數據對象放在物理內存裏，達到最優化
47
48 --保留內存reserved memory
49 --應用程序經過一些特殊API，首先保留一塊內存地址空間，以供未來使用
50 --若是某塊地址已經被其餘對象保留，你去訪問他，就會收到一個訪問越界（AV ACCESS VIOLATION）
51 --錯誤，像WIN32的VirtualAlloc  和VirtualAllocEx之類的函數，就能提供這些功能
52 --須要說明的是這裏保留的只是虛擬地址空間上的一段地址，而不是真正的物理內存空間
53
54
55
56 --提交內存commited memory
57 --將預先保留的內存頁面正式提交使用。提交的頁面在訪問時最終轉換到物理內存
58 --中的有效頁面。也就是說，正式在物理內存中申請一段空間，向頁面中存入數據
59
60 --分兩步來預留和提交內存，經過推遲頁面提交來減小物理內存的使用。對於
61 --潛在、大量、連續的內存緩存區的應用程序是頗有用的。地址空間能夠被保留
62 --在須要的時候再提交，而不是爲了整個區域提交頁面。這種技術在SQL中被
63 --普遍使用，用以緩存數據頁面
64
65
66
67 --共享內存 share memory
68 --共享內存定義爲對一個以上的進程都是可見的內存，或存在於多個進程的虛擬地址
69 --空間。例如，若是兩個進程使用相同的DLL，只把DLL的代碼頁裝入內存一次，其餘
70 --全部映射這個DLL的進程只要共享這些代碼頁就能夠了
71
72 --private bytes
73 --某個進程提交的地址空間commited memory中，非共享的部分
74
75 --working set
76 --某個進程的地址空間中，存放在物理內存的那一部分
77
78 --頁面訪問錯誤page fault soft/hard
79 --訪問一個存在於虛擬地址空間但不存在於物理內存working set的頁面
80 --就會發生一次page fault。
81 --Windows內存管理組件會處理每一個頁面訪問錯誤，首先判斷是否是訪問越界
82 --若是不是，兩種狀況
83 --hard fault:目標頁面存在於硬盤上，例如page file，這種訪問會帶來硬盤的讀寫
84 --soft fault:頁面存在於物理內存中，尚未直接放在這個進程的working set下
85 --須要Windows從新定向一次，這種訪問不會帶來硬盤操做
86
87
88 --system working set
89 --Windows的working set的類型：system cache  paged pool  non page pool  system mapped views
90 --能夠經過Windows性能監視器裏的memory：cache bytes,發生在系統內存上的page fault 能夠經過
91 --memory :cache fault/sec 看到
92
93
94
95 --系統高速緩存system cache
96 --用於映射在系統高速緩存中打開的文件頁面，以提供磁盤I/O速度。
97 --性能監視器：memory:cache resident bytes 監控
98
99
100 --非換頁區non paged pool
101 --包括必定範圍的系統虛擬地址的內存交換區，保證在任什麼時候候它都駐留在物理內存中
102 --能夠在沒有I/O調頁的狀況下從任何地址空間訪問。非頁交換區能夠在系統初始化時
103 --建立，而且在內核模式組件用來分配系統內存。
104 --性能監視器：memory:pool nonpaged bytes 監控
105
106 --這一塊緩存能夠被全部的進程共享，一個最多見的用途是存放全部對象的指針object handles
107
108 --頁交換區paged pool
109 --系統空間中能夠調入或調出系統進程工做集working set的虛擬內存區域。頁交換區在系統
110 --初始化時候建立，被內存模式組件用來分配系統內存。
111 --性能監視：memory :pool paged bytes  ,pool paged resident bytes 監控
112
113 --棧stack
114 --每一個線程有兩個棧，一個給內核模式，一個給用戶模式。每個棧是一塊內存空間。
115 --存放線程運行的過程或函數的調用地址，以及全部參數的值
116
117
118 --in process
119 --運行在同一個進程的地址空間裏,例如一個進程須要加載一個DLL文件,這個DLL文件裏
120 --的代碼也會去申請內存.若是運行在同一個進程的地址空間裏,最大的好處是速度快
121 --不須要作上下文切換context switch。可是明顯缺點是DLL在內存使用上管理不善，
122 --出現嚴重錯誤會影響整個進程的安全性
123
124
125 --out of process
126 --運行在不一樣的進程地址空間裏，以上面的DLL爲例，像OLEDB這樣的驅動程序能夠配置
127 --成運行在DLLHOST.exe的進程空間裏
128
129 --內存泄漏memory leak
130 --一直不斷地提交或保留內存資源，哪怕它們再也不使用，也不釋放給其餘用戶重用
131 --SQL的內存泄漏有兩種：
132 --一、SQL做爲一個進程，不斷地向Windows申請內存資源，直到整個Windows內存耗盡
133 --二、SQL內部某個SQL組件不斷地申請內存，直到把SQL能申請到的全部內存都耗盡
134 --使得其餘SQL功能組件不能正常使用內存。
135
136 --因爲SQL完善的內存管理機制，前一種比較少見，並且問題每每不是SQL自身，常見的是
137 --後一種泄漏，並且這種泄漏與客戶端的操做有直接關係
138
139
140 --32位下Windows地址空間和AWE
141 --32位Windows用戶進程會有4G虛擬地址空間，其中2G給內核態，2G給用戶態
142 --這兩部分嚴格分開。Windows不會由於其中某一塊內存地址空間用盡而將
143 --另一塊空間讓出。
144
145 --因爲SQL的絕大部分指令都運行在用戶態下，因此SQL的用戶態地址空間資源也只有2G
146

147 --在32位Windows中，2G地址空間使得SQL最多隻能使用2G內存，嚴重阻礙了SQL有效利用硬件資源
148
149 --方法一：在Windows2003的Boot.ini文件裏使用/3GB參數
150 --企業版下使用這個參數，使得Windows將核心態地址空間由2G降到1G，將用戶態空間由
151 --2G升到3G，加起來仍是4G地址空間
152 --後果是大大縮小system cache裏面的一些結構大小，致使核心態內存空間耗盡，而核心態出問題
153 --會影響整個服務器的穩定。
154
155
156
157 --方法二：地址空間擴展address windowsing extensionsAWE。容許32位應用程序
158 --分配64G物理內存，並把視圖或窗口映射到2G虛擬地址空間的機制
159
160 --使用AWE，解決了2G地址空間的限制，使得一個應用程序可以訪問最多達64G的物理內存
161
162 --SQL2000的企業版，SQL2005/2008的企業版和標準版都支持這個技術，也可以享受
163 --這個技術帶來的好處。
164 EXEC sys.sp_configure @configname = 'AWE Enabled', -- varchar(35)
165     @configvalue = 1 -- int
166 RECONFIGURE
167 GO
168
169 --重啓SQL服務便可
170
171
172 --(1)開啓這個功能須要SQL啓動賬戶在Windows上的lock pages in memory權限。沒有這個權限，
173 --AWE就不能成功被開啓。啓動的SQL這時候只能使用2GB的地址空間。
174 --因此DBA要確認一下SQL的errorlog裏有沒有相關的信息
175 --成功開啓：server  Address Windowing Extensions enabled
176 --消息
177 --Address Windowing Extensions is enabled. This is an informational message only; no user action is required.
178 --開啓失敗：Cannot use Address Windowing Extensions because lock memory privilege was not granted
179
180 --(2)這個功能是在應用層面有意識地使用，而不是在Windows層面實施的。也就是說SQL在申請內存時，
181 --經過特殊API調用申請到的，若是SQL不調用這個功能，就還會在普通的2GB虛擬地址空間申請內存。
182 --在SQL中不是全部的內存申請都會調用AWE技術，只有先reserve,再commit的內存調用，SQL才使用AWE
183 --讓他們使用到擴展的內存。其餘方式申請的內存只能使用普通的2GB地址空間。
184
185
186 --正由於這樣，AWE不能稱爲解決SQL地址空間不足的最終解決方法。
187 --使用64位服務器，虛擬地址空間能夠達到8TB，大於絕大多數物理內存數，我見過最多的物理內存128GB
188 --在64位下運行的SQL，其性能每每比在32位上有比較明顯的提升。
189
190 --各個版本Windows上支持的最大內存數
191 --配置                                               應用虛擬地址空間大小        最大物理內存數         是否支持AWE/locked pages support
192 --32位SQLSERVER 2GB 64GB YES
193 --32位SQLSERVER    + /3GB boot.ini參數                       3GB                         16GB                   YES
194 --32位SQLSERVER   應用在x64位操做系統（WOW）                 4GB                         64GB                   YES
195 --32位SQLSERVER   應用在IA64操做系統（WOW）                  2GB                         2GB                    NO
196 --64位SQLSERVER   應用在x64操做系統                          8TB                         2TB TERABYTES          YES
197 --64位SQLSERVER   應用在IA64操做系統                         7TB                         2TB                    YES