数据库服务器吃内存疑问

oreoconansisu 2013-08-07 10:37:14

最近用户反映页面读取插入数据速度比以前慢很多

我看了数据库服务器
发现物理内存总共48G，已经占用了46个G。。。

1.我想问为何内存会吃的那么厉害

2.应该如何优化调整

谢谢

...全文

528 17 打赏收藏转发到动态举报

写回复

用AI写文章

17 条回复

切换为时间正序

请发表友善的回复…

发表回复

阳泉酒家小当家 2013-11-12

打赏
举报

引用 15 楼 oreoconansisu 的回复:

[quote=引用 14 楼 ap0405140 的回复:] 检查一下SQL Server最新的SP补丁是否有安装,如SQL2000 SP4,SQL2005 SP4,SQL2008 SP2等. 我曾遇过这种问题,系统吃内存很大,装了SP补丁后就正常了.

装过SQL2008 SP2补丁[/quote] 吃内存是正常的，如果你不希望sql server占用那么大的内存，那就设置max server memory(MB)小一点

發糞塗牆 2013-11-12

打赏
举报

哇，3个多月了，还没解决？

oreoconansisu 2013-11-11

打赏
举报

引用 14 楼 ap0405140 的回复:

检查一下SQL Server最新的SP补丁是否有安装,如SQL2000 SP4,SQL2005 SP4,SQL2008 SP2等. 我曾遇过这种问题,系统吃内存很大,装了SP补丁后就正常了.

装过SQL2008 SP2补丁

唐诗三百首 2013-10-20

打赏
举报

检查一下SQL Server最新的SP补丁是否有安装,如SQL2000 SP4,SQL2005 SP4,SQL2008 SP2等. 我曾遇过这种问题,系统吃内存很大,装了SP补丁后就正常了.

阳泉酒家小当家 2013-10-19

打赏
举报

1.首先，占用那么多内存并不表示，就不正常。 2.但如果觉得查询变慢了，那就得关注一下了。但查询变慢，和占用那么多的内存，并没有什么必然联系。 3.为了能了解是否真的有问题，首先，你得知道，这些内存都是花在哪儿了。一般的内存，主要是由数据库页、sql执行计划、网络包等，如果数据大部分都是缓存的数据，那应该问题不大。但如果大部分都由sql执行计划，那就有问题了，可能是由于没有使用绑定变量，导致大量的重复语句，都缓存在内存中。

select 
    type,
    
	sum(virtual_memory_reserved_kb) as [VM Reserved],   --从buffer pool中保留的大小
	
	sum(virtual_memory_committed_kb) as [VM Committed], --从buffer pool中提交的大小
	
	--是Buffer Pool里的Stolen Memory的大小.在Buffer Pool中通过Stolen分配的,也就是直接Commit分配的内存量.
	sum(single_pages_kb) as [SinlgePage Allocator],
	
	--分配的多页内存量(KB)，是使用内存节点的多页分配器分配的内存量。此内存在buffer pool外分配，是SQL Server自己的代码使用的MemToLeave大小。
	sum(multi_pages_kb) as [MultiPage Allocator],

	--内存Clerk使用地址窗口化扩展插件(AWE)分配的内存量。当启用AWE时,只有缓冲池Clerk(MEMORYCLERK_SQLBUFFERPOOL)使用此机制，不可为空值。
    --可以由buffer pool使用的内存量
	sum(awe_allocated_kb) as [AWE Allocated],	
	
	sum(shared_memory_reserved_kb) as [SM Reserved],   --内存Clerk保留的共享内存量,保留给共享内存和文件映射使用.
	
	sum(shared_memory_committed_kb) as [SM Committed]  --内存Clerk提交的共享内存量,和上面的字段一起可以追踪Shared Memory的大小.
		
from sys.dm_os_memory_clerks 
group by type
order by type

4.接下来，是查询为什么变慢的问题。向上面说的，可能是由于表经常进行插入，删除，修改，导致了存储碎片，这样会导致查询同样的数据，需要更多的IO，也需要更多的内存，那么效率自然下降，同时内存的效率下降，间接导致需要吃更多的内存，这个可以通过重建表和索引，来完成。还有，就是随着数据的变化，表的统计信息不够准确，导致查询优化器不能够生成足够优化的执行计划，那么查询自然会慢，这个主要是通过update statistics 表 ,来更新统计信息就可以。还有最关键的是，你的查询是否通过索引来访问数据，因为索引的效率更高，否则，用表扫描的话，效率非常差。

wangchangming 2013-08-08

打赏
举报

试着重新生成下索引，更新下统计信息再看

Cloud_Hero 2013-08-07

打赏
举报

通过性能检测，查看一下是硬盘还是其他资源访问过大，导致cpu运行速度过快，内存占用率过大。

oreoconansisu 2013-08-07

打赏
举报

引用 10 楼 public0011 的回复:

占用46G太正常了。如果读写比较频繁。47.5G都可以。关键你这个占用是在那里看到的。不会是在window的任务管理器里面看到的吧

对啊

Q315054403 2013-08-07

打赏
举报

充分利用资源（CPU、RAM）是正道呀。。应该改善的系统设计，或者优化若有预算，欢迎联系ME

KevinLiu 2013-08-07

打赏
举报

最近用户反映页面读取插入数据速度比以前慢很多 1。先查一下是否有Blocking，是否有WaitType，WaitResource 2。是否有IO问题 3。内存是否有瓶颈。。。。

oreoconansisu 2013-08-07

打赏
举报

引用 3 楼 wwwwgou 的回复:

#1.每次增删改查数据，都会先把页加载到内存，再处理。如果内存足够，加载进来后，就不再释放，直到超出SQL SERVER设置的最大阈值，或系统控制 #2.监控一下，看是哪些语句执行比较慢；看一下慢的原因，是为什么。才能下结论。 #3.一般来说，在既定的硬件条件下，优化索引是首选

引用 4 楼 DBA_Huangzj 的回复:

个人猜测： 1、过多的增删改操作，导致碎片增多。 2、库越来越大，索引效率降低，或者以前小表的时候即使没有索引都没所谓，现在很大了就显示出重要性。 3、有新的程序部署，影响了既有性能。 4、数据的增长没有计划性，比如短期内操作数量巨大的数据。 5、没有定期维护，到了一定时间段，就从量变到质变。结论： 1、用性能监视器看看CPU，磁盘、内存等资源，参考网上的“建议”，初步评估和定位问题再哪里。 2、借助sqlserver自带功能，如profiler、dmv、DTA等来找到比较大开销的语句。进行优化。 3、做好定期维护，如索引维护、磁盘空间维护等。

谢谢分析如有疑问，再来请教哈

發糞塗牆 2013-08-07

打赏
举报

说的比较虚，但是没有真正数据之前，的确也不好猜测，只能先监控看看瓶颈在哪部分。另外还可以查看等待信息，也可以看资源问题。这些不是一个贴能说完的，只能给你个方向，然后到网上找找

發糞塗牆 2013-08-07

打赏
举报

个人猜测： 1、过多的增删改操作，导致碎片增多。 2、库越来越大，索引效率降低，或者以前小表的时候即使没有索引都没所谓，现在很大了就显示出重要性。 3、有新的程序部署，影响了既有性能。 4、数据的增长没有计划性，比如短期内操作数量巨大的数据。 5、没有定期维护，到了一定时间段，就从量变到质变。结论： 1、用性能监视器看看CPU，磁盘、内存等资源，参考网上的“建议”，初步评估和定位问题再哪里。 2、借助sqlserver自带功能，如profiler、dmv、DTA等来找到比较大开销的语句。进行优化。 3、做好定期维护，如索引维护、磁盘空间维护等。