一种自动清除/重新启动虚拟内存蠕变的方法？

Question

一种自动清除/重新启动虚拟内存蠕变的方法？

Fan*_*o68 3 sql-server-2005 sql-server memory

我知道这样做不是很好的做法，但我的公司负担不起我试图为我们的问题找到合适的解决方案。我读过这篇文章，我可以用 SQL Server 2005 做同样的事情，但我希望有更好（更快？）的方法。

问题如下：

我们有一个在 Windows Server 2003 上运行的 ASP.net 网站 (ASP2)，它也托管我们的 SQL Server 2005 数据库并安装。

最近，我们注意到 SQL Server 2005 实例的 VM 已提交内存空间增长，几乎达到了我们设置为 1.7 GB 的 VM 保留空间（嗯太多了？）。

运行 SQL Server 的 PC 服务器有 4 GB 的 RAM 和最多 3.5 GB 的可用磁盘空间，用于 SQL Server 2005 安装。数据库本身在 350 GB 共享上（有两个分区：分别是 C 和 D 驱动器）。

因此，在 VM 空间方面，我原以为我们有足够的空间并且将 VM 限制设置为 1.7 GB（理想情况下为 2 GB）就足够了。

数据库本身的大小不到 500 MB。

当我们的 VM Committed 值接近 VM Reserved 值时，服务会显着减慢。我知道的唯一方法是停止所有 SQL 服务服务并重新启动它们。但是在 24 小时内，VM Committed 仍然在上升！

有没有一种方法可以让我试图找出问题的原因，但只需在一夜之间自动重新启动所有服务？或者我真的应该试图找出我们问题的原因？

我做了一些调查（但正如我所说的，我们现在时间很短），并找到了这个 SQL 查询（见下文），它告诉我什么实际查询似乎最占用 CPU（不确定这是否有任何影响）解决我上面的原始 VM 问题）。

它显示了一个恰好在一夜之间运行的查询，可能是这个查询只是在占用内存而不是将其释放回池中？

有没有办法在 SQL Server 中“关闭”线程/内存分配等，以便释放内存？

这是 CPU“猪搜索”查询（由this 提供）

select  
    highest_cpu_queries.plan_handle,  
    highest_cpu_queries.total_worker_time, 
    q.dbid, 
    q.objectid, 
    q.number, 
    q.encrypted, 
    q.[text] 
from  
    (select top 50  
        qs.plan_handle,  
        qs.total_worker_time 
    from  
        sys.dm_exec_query_stats qs 
    order by qs.total_worker_time desc) as highest_cpu_queries 
    cross apply sys.dm_exec_sql_text(plan_handle) as q 
order by highest_cpu_queries.total_worker_time desc

Run Code Online (Sandbox Code Playgroud)

编辑，对巴图姆问题的回答：

运行查询的结果：

---------------------------------------------------------------------------------------------------- 
Memory usage details for SQL Server instance SERVER9 (9.00.4053.00 - X86) - Standard Edition)
----------------------------------------------------------------------------------------------------

Memory visible to the Operating System
Physical Memory_MB|Physical Memory_GB|Virtual Memory GB 4091|4|2
Buffer Pool Usage at the Moment
BPool_Committed_MB|BPool_Commit_Tgt_MB|BPool_Visible_MB
519.250000|1599.875000|1599.875000

Total Memory used by SQL Server Buffer Pool as reported by Perfmon counters
Mem_KB|Mem_MB|Mem_GB 531712|519.250000|0.507080078

Memory needed as per current Workload for SQL Server instance    
Mem_KB|Mem_MB|Mem_GB 1638272|1599.875000|1.562377929

Total amount of dynamic memory the server is using for maintaining connections
Mem_KB|Mem_MB|Mem_GB 560|0.546875|0.000534057

Total amount of dynamic memory the server is using for locks
Mem_KB|Mem_MB|Mem_GB 968|0.945312|0.000923156

Total amount of dynamic memory the server is using for the dynamic SQL cache
Mem_KB|Mem_MB|Mem_GB 1120|1.093750|0.001068115

Total amount of dynamic memory the server is using for query optimization
Mem_KB|Mem_MB|Mem_GB 552|0.539062|0.000526428

Total amount of dynamic memory used for hash, sort and create index operations.
Mem_KB|Mem_MB|Mem_GB 0|0.000000|0.000000000

Total Amount of memory consumed by cursors
Mem_KB|Mem_MB|Mem_GB 480|0.468750|0.000457763

Number of pages in the buffer pool (includes database, free, and stolen).
8KB_Pages|Pages_in_KB|Pages_in_MB 66464|531712.000000|519.250000000

Number of Data pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 50135|401080.000000|391.679687500

Number of Free pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 895|7160.000000|6.992187500

Number of Reserved pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 0|0.000000|0.000000000

Number of Stolen pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 15434|123472.000000|120.578125000

Number of Plan Cache pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 11953|95624.000000|93.382812500

Page Life Expectancy - Number of seconds a page will stay in the buffer pool without references
Page Life in seconds|PLE Status 47011|PLE is Healthy

Number of requests per second that had to wait for a free page
Free list stalls/sec 0


Number of pages flushed to disk/sec by a checkpoint or other operation that require all dirty pages to be flushed
Checkpoint pages/sec 572

Number of buffers written per second by the buffer manager"s lazy writer
Lazy writes/sec 0

Total number of processes waiting for a workspace memory grant
Memory Grants Pending 0

Total number of processes that have successfully acquired a workspace memory grant
Memory Grants Outstanding 0

Run Code Online (Sandbox Code Playgroud)

第二个查询，检查内存压力：

SELECT object_name, cntr_value 
FROM sys.dm_os_performance_counters 
WHERE counter_name IN ('Total Server Memory (KB)', 'Target Server Memory (KB)');

Run Code Online (Sandbox Code Playgroud)

结果：

object_name|cntr_value
SQLServer:Memory Manager        |1638272
SQLServer:Memory Manager        |531712
(2 row(s) affected)

Run Code Online (Sandbox Code Playgroud)

我的服务器是 32 位的。我们不会出于任何原因迁移到 64 位。
sp_configur无法提供来自电子信息的值，这是保密的。:)

Answer 1

Sha*_*nky 5

首先，每当您发布与 SQL Server 相关的问题时，请发布“SQL Server 的版本和版本”，您不会相信答案可能会随着版本的不同而完全改变。

最近，我们注意到 SQL Server 2005 实例的 VM 已提交内存空间增长，几乎达到了我们设置为 1.7 GB 的 VM 保留空间（嗯太多了？）。

为什么你在看VM committed和VM reserved，实际上，你知道它告诉。你想从 VM 提交/保留中推断出什么。VM 保留是 SQL Server 保留的虚拟地址空间 (VAS) 总量。SQL Server 可能会根据其 VAS 限制保留 VAS，该限制在 64 位上为 8 TB，在 32 位上默认为 2 G。所以当VM预留高时没有问题。这是正常行为。保留内存实际上是 SQL Server“认为”将来可能使用的内存。而且由于保留的 VM 是 1.7 GI，因此不认为这有问题

VM 已提交是指虚拟地址空间 (VAS) 或 SQL Serverphysical RAM在系统上已提交或支持的虚拟内存总量。提交的内存具有与其关联的物理内存。已提交意味着 SQL Server 当前正在使用的总虚拟内存。

当我们的 VM Committed 值接近 VM Reserved 值时，服务会显着减慢。我知道的唯一方法是停止所有 SQL 服务服务并重新启动它们。但是在 24 小时内，VM Committed 仍然在上升！

在 SQL Server 上，提交的虚拟机可能等于保留的虚拟机，这不一定是问题。并且请不要养成重新启动 SQL Server IMO 的习惯，这是您能做的最糟糕的事情。现在我认为您在 SQL Server 中面临性能问题，您需要首先找出导致服务器变慢的实际原因。要开始使用，您可以参考如何分析 SQL Server 性能

这实际上可以帮助您找出问题所在。相信我，从你发布的内容来看，它在我看来并不像内存问题，你再次提供了关于 SQL Server 版本的有限信息，所以我的回答是有限的。

请在您的问题中添加以下输出

Select @@Version

Run Code Online (Sandbox Code Playgroud)

您的 SQL Server 是否已修补到 SQL Server 2005 SP4。肯定是。您能否使用以下命令读取错误日志并将其内容发布到某个共享位置并附加有问题的链接我想查看错误日志中的内容。

sp_readerrorlog

Run Code Online (Sandbox Code Playgroud)

你说你的 SQL Server 只有 4 G 你有没有为 SQL Server 设置最大服务器内存？

Windows Server 2003 是否已修补到最新的 Service Pack。确保 Windows Server 中是否存在过度修剪 SQL Server 内存的错误。

编辑：

.Microsoft SQL Server 2005 - 9.00.4053.00 (Intel X86) 2009 年 5 月 26 日 14:24:20 版权所有 (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 5.2（Build 3790：Service Pack 2）

您的 SQL Server 是 32 位的，Windows Server 是标准版的 32 位。您无论如何都不能强制 Windows Server 使用超过 4 G 的 RAM，因此在 SQL Server 上启用 AWE 没有意义，因为它可能允许数据和索引页看到超出 2 G 的 VAS 限制的内存。我只能建议您将 SQL Server 和 Windows 操作系统都升级到 64 位。我会推荐 SQL Server 2012 SP2 和 windows Server 2012 或 windows server 2008 r2，但要确保两者都是 64 位。

如果这不可能，您可以将 Windows Server 2003 从标准升级到企业，然后您可以启用 PAE，窗口服务器可以看到超过 4 G。之后启用 AWE 允许 SQL Server 数据和索引页看到大于 2 G 的内存。截至目前，无论如何 SQL Server VAS 都被限制为 2 G，因此它无法访问超过 2G 的内存

如果您想了解 32 位内存配置，请阅读本文

归档时间：	10 年，11 月前
查看次数：	6589 次
最近记录：	10 年前