环境:Microsoft SQL Server 2005 - 9.00.4035.00 (X64) Nov 24 2008 16:17:31 Copyright (c) 1988-2005 Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1 (Build 7600: ) 最近发现,32G的内存,大部分情况下都是占用31.7G左右,原来好像一直在20G左右。
这个啥情况?
与此同时,数据库的性能貌似没啥变化。
SQL Server 2005的默认配置没有动过,主要是不懂。
就这个情况,请指点。SQL Server 2005内存
这个啥情况?
与此同时,数据库的性能貌似没啥变化。
SQL Server 2005的默认配置没有动过,主要是不懂。
就这个情况,请指点。SQL Server 2005内存
应该是正常,sqlserver2005默认内存设置是无限大,只用那麼多的话证明那些足够它内部数据转换的了。 手动设置 SQL Server 内存选项有两种主要方法:第一种方法,将 min server memory 和 max server memory 设置为同一值。此值与达到该值后分配给 SQL Server 缓冲池的固定内存量相对应。第二种方法,将 min server memory 和 max server memory 设置成一个内存范围。这种方法在系统或数据库管理员希望配置 SQL Server 实例,同时又要考虑在同一台计算机上运行的其他应用程序的内存需求时很有用。
min server memory 保证了 SQL Server 实例的缓冲池可用的最小内存量。SQL Server 不会在启动时立即分配 min server memory 指定的内存量。不过,除非降低 min server memory 的值,否则当内存使用量由于客户端负荷而达到该值后,SQL Server 不能从已分配的缓冲池中释放内存。
max server memory 避免了 SQL Server 缓冲池使用的内存量多于指定的内存量,这样剩余的可用内存可以用来快速启动其他应用程序。SQL Server 不会在启动时立即分配 max server memory 指定的内存量。内存使用量会随着 SQL Server 的需要增加,直到达到 max server memory 指定的值。除非提高 max server memory 的值,否则 SQL Server 不能超过此内存使用量。
min server memory 保证了 SQL Server 实例的缓冲池可用的最小内存量。SQL Server 不会在启动时立即分配 min server memory 指定的内存量。不过,除非降低 min server memory 的值,否则当内存使用量由于客户端负荷而达到该值后,SQL Server 不能从已分配的缓冲池中释放内存。
max server memory 避免了 SQL Server 缓冲池使用的内存量多于指定的内存量,这样剩余的可用内存可以用来快速启动其他应用程序。SQL Server 不会在启动时立即分配 max server memory 指定的内存量。内存使用量会随着 SQL Server 的需要增加,直到达到 max server memory 指定的值。除非提高 max server memory 的值,否则 SQL Server 不能超过此内存使用量。
1、缓存所需数据,sqlserver不直接操作磁盘上的数据,需要用时会从磁盘加载到内存,这部分是内存最大的消耗者,而且除非内存有压力,不然一般数据会驻留内存相当长的时间,除非重启或者用DBCC命令清除。
2、缓存执行计划,减少编译时间,降低CPU压力。提高重用机会
看sqlserver的内存不能仅看用了多少,还要借助某些计数器或者其他技术来识别是否有内存压力,可以看看我的文章:http://blog.csdn.net/dba_huangzj/article/details/8627000
但不会是默认设置,这个明显配置了sql server 启动帐号的lock page in memory。
这是推荐设置。
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
--库缓存(buffer pool中stolen的单页,Multi-page的多页)--各种对象各占了多少内存:
select objtype,
sum(size_in_bytes) as sum_size_in_bytes,
count(bucketid) as cache_counts
from sys.dm_exec_cached_plans
group by objtype
不是有人建议周期性重启吗?
重启后,是不是清理了一些长期不用的Buffer之类的?
昨天重启后,现在内存消耗一般在23G左右,原来一直是在31.多G。
不是有人建议周期性重启吗?
重启后,是不是清理了一些长期不用的Buffer之类的?
昨天重启后,现在内存消耗一般在23G左右,原来一直是在31.多G。确实会有效,但是一般也可以通过的命令来清理buffer,不过一定要在系统维护期内用,而不要在白天系统繁忙时用:--清除过程缓存
dbcc freeproccache
go--清除数据缓存
dbcc dropcleanbuffers
go
不是有人建议周期性重启吗?
重启后,是不是清理了一些长期不用的Buffer之类的?
昨天重启后,现在内存消耗一般在23G左右,原来一直是在31.多G。任何DBMS都吃内存,太多太多人觉得SQLServer内存吃那么多是问题,根据某本书的说法,磁盘的速度比内存速度慢接近100万倍,而SQLServer直接操作内存而不是磁盘,每次需要数据才加载,少量数据到没问题,但是大量数据并发的时候,延时相当严重。并且重启会把最重要的一部分东西去掉——执行计划缓存,这样最少第一次运行的时候要重编译,CPU压力会增大。要通过监控内存的使用情况来分析是否存在问题,而不是从任务管理器里面看内存占用就觉得高、有问题。