标签:
最近帮客户解决发布订阅的问题时,突然遇到这样一个问题发布订阅中报下面的错误,另外执行alter table 操作时也会报错 :
问题很奇怪发布订阅和CLR有什么关系?memtoleave内存是个啥?回忆学习体系架构的时候,确实看到过memtoleave内存,但是是什么已经完全想不起来了,所以拿起书本回味一下学习的快感...
---------------转载请注明出处------------http://www.cnblogs.com/double-K/p/5049417.html--------------------
抛开问题我们先看一下SQL SERVER的内存结构:
1.从操作系统层面看SQL SERVER内存分配:windows 和SQL SERVER的关系就像君与臣一样,windows的统治下SQLSERVER和其他应用如notepad并无两样,当操作系统级别都内存紧张的时候SQL SERVER的内存一样会紧张。所以了解WINDOWS的内存结构同样重要。
2.SQL SERVER内存的使用分类:
我们以按照大小的分类作为说明:申请小于等于8KB 这些页面都集中管理,这块内存称为 buffer pool,另一部分申请大于8KB的称为multi-page(memtoleave),memtoleave这块区域的内存分配很大一部分不受SQLSERVER本身控制,或者可以说只在SQL SERVER内部分配,但是却是由加载在SQL SERVER内部的其他DLL来分配的,如CLR。
32位的年代启动时需要保留我们配置需要的memtoleave大小(包含worker thread所需)的地址空间,然后把其他的都给buffer pool。
64位时代以后由于地址空间可以理解为无限大,所以SQL SERVER不再控制memtoleave这段空间的大小,甚至已经可以抢夺database cache了。
以一个表格总结一下:
类型 | database cache | consumer | 第三方代码 | threads |
reserved/commit | 是 | 一般不是 | 一般不是 | 不是 |
stolen | 不是 | 是 | 是 | 是 |
buffer pool | 所有 | 绝大部分 | 没有 | 没有 |
memtoleave | 没有 | 一小部分 | 所有 | 所有 |
---------------转载请注明出处------------http://www.cnblogs.com/double-K/p/5049417.html--------------------
简单的说明了一下SQL 的内存,有几点需要注意的也简单提一下:
1.WINDOWS不缺内存SQL 就不会缺内存吧?
答:这个是很错误的(1)如果是32位,由于虚拟地址空间的限制SQL 可能无法继续申请内存。有人会说我可以开AWE,前文也提到过AWE不是万能的,有64位为什么还要选32位呢? 对吧。(2)SQL SERVER很可能设置了max server memory约束了SQL 继续申请内存的能力,这个真遇到过,256G内存的服务器 max server memory 被设置成了2个G。
2.我们设置SQL 的最大内存 为20G,为什么有的时候观察sql进程的内存使用会超过20G?是不是这个没用呢?
答:属性->内存->最大内存 (max server memory)设置的其实buffer pool的最大值,里面没有包含memtoleave这段空间的大小,所以有的时候会看到SQL 使用的内存超过了设置的max server memory
---------------转载请注明出处------------http://www.cnblogs.com/double-K/p/5049417.html--------------------
说了这么多回到我开篇的问题上,为什么出现这个情况memtoleave内存不足呢?看完文章也许你已经有了答案。
我说一下我排查问题的步骤,当客户发给我报错截图的时候我第一反应必须是了解客户的环境,因为不能远程所以我询问了操作系统版本SQL 版本,补丁及内存设置等等...告诉我64位的WINDOWS SERVER2008 ,SQL SERVER2008R2,遗憾的是当时客户没有select @@version确认SQL 版本,我也理所当然的认为装的肯定是64位SQL SERVER呀!!经过翻阅资料网上寻找答案始终想不明白为什么会出现这个显现...最后再次要求客户确认SQL 版本时才发现64位操作系统竟然误安装32位SQL SERVER 这下问题瞬间明了。
这个32位memtoleave的内存初始是多大呢?256M + 256(个thread) X 0.5MB = 384MB,可以通过修改启动参数 + -g 1024 (分配1024MB)解决这个问题,但是这个问题的根本不是修改启动参数,这仅仅是表名现象,最终的操作必然是重新安装SQL SERVER x64 !!!当然这会对用户的应用造成很大的影响。
---------------转载请注明出处------------http://www.cnblogs.com/double-K/p/5049417.html--------------------
以为这个案例我突然发现自己的体系结构如此之脆弱...遇到问题虽然见过却没有完善的知识体系来支撑,所以准备再次学习一下SQL 内存篇!!同时也会奉上后续学习文章!!
哦了~~~
标签:
原文地址:http://www.cnblogs.com/double-K/p/5049417.html