笔记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