sqlserver内存占用过高

改变服务器内存会有用的，但是 sqlserver 一般超不过这个数值，只会比这个数值低，因为操作系统会占用内存。所以最好预留 1至2 个G给操作系统。使用AWE分配内存，这个早期遗留的产物，主要早期的操作系统无法支持 3个G左右以上的内存，勾选这个选择会让sqlserver 使用到更多的内存，但现在这个选项对应现在的操作系统和硬件已经没有什么用了。你这个情况最好先检查一下大概什么原因占用了服务器这么多内存，看看能不能进行一些优化。实在不行，你只好购买一些内存来扩充了。

比如说我现在32G的内存这里设置多少合适，之前sqlserver经常就占用到30G然后网站就挂了

你这个贴发到 Sql Server 版块比较合适。1.改了最大服务器内存值是否有用。如果sqlserver内存超过了这个值会怎么样
-- 有用。一般情况下，如果你改小了，不是太离谱的话， sql server 的内存会逐渐降至你设置的值。
-- 实在不行，可以在业务不忙的时候，重启下 sql server 服务一定是能够生效的。2.上面那个选项 “使用AWE分配内存” 是做啥用的，需要勾选吗
-- 那个只是针对老旧的 32 位系统而言的，你这个应该是 64 位系统，不需要设置。3.关于数据库内存过高还有没有其他更好的解决办法。
--没有，也不需要。
--数据库与普通的程序不同，大内存是天然的优化手段，如果你的数据库比较大使用又频繁，基本上有多少内存都会占用完。占用多了，很多东西都在缓存里，这样才快。你要做的，不是怎么想方设法限制数据库的内存，不是看到内存占用多了就觉得难受，没必要。
分配好内存就可以了。数据库设置为 25GB
IIS 5GB
操作系统 2GB但最好的解决方案，还是增加一台 Web 服务器，让数据库单独用一台服务器。
如果数据库单独用一台服务器，也不要设置得过高，总共32GB内存，限制sqlserver 最大28-30GB。
操作系统不预留一定的空余内存，有时可能远程都会有问题，不要因小失大。

所谓“爆炸”我估计是你们的某个 web 程序有 BUG。一锅汤里混入了一个蟑螂，这个时候要有能力及时发现蟑螂，而不是把锅缩小尺寸。

也有可能是bug因为每次网站挂掉的时候我去看内存都是数据库占了30G，然后重启就好了。。

每次都是页面显示 service unavailable

也有可能是bug因为每次网站挂掉的时候我去看内存都是数据库占了30G，然后重启就好了。。真不是 bug .
我在 #3 的评论，你仔细看完，就会明白：数据库最好不要跟应用放在一起。
数据库的争夺性非常强，你没限制的话肯定会挤压 iis 的内存空间。如果数据库的问题，百度一下就能解决， DBA 就没有必要了。

也有可能是bug因为每次网站挂掉的时候我去看内存都是数据库占了30G，然后重启就好了。。真不是 bug .
我在 #3 的评论，你仔细看完，就会明白：数据库最好不要跟应用放在一起。
数据库的争夺性非常强，你没限制的话肯定会挤压 iis 的内存空间。如果数据库的问题，百度一下就能解决， DBA 就没有必要了。好谢谢新增服务器是没指望的，我们公司很穷的。。
如果是设置数据库的内存大小就是设置数据库里面最大服务器内存是吧？

也有可能是bug因为每次网站挂掉的时候我去看内存都是数据库占了30G，然后重启就好了。。
挂掉时30G，那么平时你看过吗？是多少呢

也有可能是bug因为每次网站挂掉的时候我去看内存都是数据库占了30G，然后重启就好了。。
挂掉时30G，那么平时你看过吗？是多少呢平时一般维持在28G左右到30G的时候就不行了。重启的话一般是从几G开始上涨

#3 已经说得很清楚了，设置为 25GB.
后面可以再根据情况来调整。再送一条语句，你可以在服务器上执行，看下 sql 有没有优化的必要：
SELECT TOP 10 OBJECT_NAME(qt.objectid, qt.dbId)  AS procName,
       DB_NAME(qt.dbId)                   AS [db_name],
       qt.text                            AS SQL_Full,
       SUBSTRING(
           qt.text,
           (qs.statement_start_offset / 2) + 1,
           (
               (
                   CASE statement_end_offset
                        WHEN -1 THEN DATALENGTH(qt.text)
                        ELSE qs.statement_end_offset
                   END
                   - qs.statement_start_offset
               ) / 2
           ) + 1
       )                                  AS SQL_Part --统计对应的部分语句
       ,
       qs.creation_time,
       qs.last_execution_time,
       qs.execution_count,
       qs.last_elapsed_time / 1000000     AS lastElapsedSeconds,
       qs.last_worker_time / 1000000      AS lastCpuSeconds,
       CAST(
           qs.total_elapsed_time / 1000000.0 / (
               CASE
                    WHEN qs.execution_count = 0 THEN -1
                    ELSE qs.execution_count
               END
           ) AS DECIMAL(28, 2)
       )                                  AS avgDurationSeconds,
       CAST(qs.last_logical_reads AS BIGINT) * 1.0 / (1024 * 1024) * 8060 AS
       lastLogicReadsMB,
       qs.last_logical_reads,
       qs.plan_handle
FROM   sys.dm_exec_query_stats qs
       CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS p
WHERE  qs.last_execution_time >= CONVERT(CHAR(10),GETDATE(),120)+' 08:00' --今天8点之后的慢SQL
       AND qs.last_elapsed_time >= 3 * 1000 * 1000 --只取执行时间大于 3 秒的记录
       AND qt.[text] NOT LIKE '%Proc_DBA%'
ORDER BY
       qs.last_worker_time DESC

也有可能是bug因为每次网站挂掉的时候我去看内存都是数据库占了30G，然后重启就好了。。你这个就是把结果当作原因，这不是找故障原因的正确方法。

#3 已经说得很清楚了，设置为 25GB.
后面可以再根据情况来调整。再送一条语句，你可以在服务器上执行，看下 sql 有没有优化的必要：
SELECT TOP 10 OBJECT_NAME(qt.objectid, qt.dbId)  AS procName,
       DB_NAME(qt.dbId)                   AS [db_name],
       qt.text                            AS SQL_Full,
       SUBSTRING(
           qt.text,
           (qs.statement_start_offset / 2) + 1,
           (
               (
                   CASE statement_end_offset
                        WHEN -1 THEN DATALENGTH(qt.text)
                        ELSE qs.statement_end_offset
                   END
                   - qs.statement_start_offset
               ) / 2
           ) + 1
       )                                  AS SQL_Part --统计对应的部分语句
       ,
       qs.creation_time,
       qs.last_execution_time,
       qs.execution_count,
       qs.last_elapsed_time / 1000000     AS lastElapsedSeconds,
       qs.last_worker_time / 1000000      AS lastCpuSeconds,
       CAST(
           qs.total_elapsed_time / 1000000.0 / (
               CASE
                    WHEN qs.execution_count = 0 THEN -1
                    ELSE qs.execution_count
               END
           ) AS DECIMAL(28, 2)
       )                                  AS avgDurationSeconds,
       CAST(qs.last_logical_reads AS BIGINT) * 1.0 / (1024 * 1024) * 8060 AS
       lastLogicReadsMB,
       qs.last_logical_reads,
       qs.plan_handle
FROM   sys.dm_exec_query_stats qs
       CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS p
WHERE  qs.last_execution_time >= CONVERT(CHAR(10),GETDATE(),120)+' 08:00' --今天8点之后的慢SQL
       AND qs.last_elapsed_time >= 3 * 1000 * 1000 --只取执行时间大于 3 秒的记录
       AND qt.[text] NOT LIKE '%Proc_DBA%'
ORDER BY
       qs.last_worker_time DESC
我用的sql2005执行不了额，
消息 102，级别 15，状态 1，第 36 行
'.' 附近有语法错误。这一行   CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt

IIS和网站应用程序都需要内存，并随并发连接数增加而增加
若剩余得可用内存小于最大服务器内存时，必然会对数据库的运行带来影响，盲目加大最大服务器内存，只能是弊大于利

使用AWE分配内存是低版本 SQL Server 的行为，已安排在废弃计划之中
其目的是从内存中分割出一块来，专供 SQL Server 使用
及时释放查询资源和关闭数据库，减少（不用）所谓的后台访问，才是减少数据库内存占用的唯一途径
不过，你是如何认定是数据库的原因？
如果是页面程序死锁而导致网站挂掉的呢

SQL Server 的内存分配策略就是内存会越占越多的，设置了限制就好，到达上限会释放。对性能会有一点负面的影响。

嗯，我有个小服务器 4G内存，也是被SQLSERVER 2000吃个光，经常IIS 就挂了。

#3 已经说得很清楚了，设置为 25GB.
后面可以再根据情况来调整。再送一条语句，你可以在服务器上执行，看下 sql 有没有优化的必要：
SELECT TOP 10 OBJECT_NAME(qt.objectid, qt.dbId)  AS procName,
       DB_NAME(qt.dbId)                   AS [db_name],
       qt.text                            AS SQL_Full,
       SUBSTRING(
           qt.text,
           (qs.statement_start_offset / 2) + 1,
           (
               (
                   CASE statement_end_offset
                        WHEN -1 THEN DATALENGTH(qt.text)
                        ELSE qs.statement_end_offset
                   END
                   - qs.statement_start_offset
               ) / 2
           ) + 1
       )                                  AS SQL_Part --统计对应的部分语句
       ,
       qs.creation_time,
       qs.last_execution_time,
       qs.execution_count,
       qs.last_elapsed_time / 1000000     AS lastElapsedSeconds,
       qs.last_worker_time / 1000000      AS lastCpuSeconds,
       CAST(
           qs.total_elapsed_time / 1000000.0 / (
               CASE
                    WHEN qs.execution_count = 0 THEN -1
                    ELSE qs.execution_count
               END
           ) AS DECIMAL(28, 2)
       )                                  AS avgDurationSeconds,
       CAST(qs.last_logical_reads AS BIGINT) * 1.0 / (1024 * 1024) * 8060 AS
       lastLogicReadsMB,
       qs.last_logical_reads,
       qs.plan_handle
FROM   sys.dm_exec_query_stats qs
       CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS p
WHERE  qs.last_execution_time >= CONVERT(CHAR(10),GETDATE(),120)+' 08:00' --今天8点之后的慢SQL
       AND qs.last_elapsed_time >= 3 * 1000 * 1000 --只取执行时间大于 3 秒的记录
       AND qt.[text] NOT LIKE '%Proc_DBA%'
ORDER BY
       qs.last_worker_time DESC
我用的sql2005执行不了额，
消息 102，级别 15，状态 1，第 36 行
'.' 附近有语法错误。这一行   CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt

其实在 sqlserver2005 下是可以执行的，但需要把兼容性级别改成 2005 , 如果兼容性级别是 2000 ，就会出现你那样的错误。数据库的优化，其实是需要比较专业的知识。
下次有类似的问题，欢迎到 SQL Server 版块。超时比较麻烦，最好能在应用程序的日志中记载。
如果有数据库异常（不管是什么原因导致的异常），都记录下相关的 SQL 语句和存储过程名，还有所有的参数值。
这样，即使有异常，也能非常精准的一步到位定位问题。定位了问题，下一步的优化才有目标。但限制 SQL Server 内存，不管怎么样都是要做的，这个无需置疑，做了再说吧。
这个谈不上优化，但至少可以减少 IIS 崩溃。如果你司有专门的运维人员，让他们对这台机做监控，比如服务器异常了，提供崩溃时的 cpu，内存情况。
理论虽然重要，但空谈理论不行，需要有实际的数据来支撑。

这首先要检查你的 and_user.cs 的110 行之类的代码。不要纠结什么数据库，那只是结果，根本不是原因。如果你纠结于结果等于绕弯弯在乱猜原因！

去检查出错的语句、日志记录出错的环境（输入变量值）。在你电脑上重现 bug。你可以想想看，不重现 bug，而是把时间花在与运行时明显的 bug 无关的地方，不可能解决 bug。

通常，一个程序发布之前应该运行自动测试（顺序执行10遍，然后并发几十倍强度再测试，因为许多问题是高并发操作时在特定情况下才会出现的）。通常在自己开发机器的调试环境可以运行你的测试程序，让 vs 调试器可以立刻捕获错误并进入调试环境。但是假设你没有在调试运行测试程序，而是部署之后才能发现 bug，那么你需要日志。例如以下代码        Common.Program.WriteObjectLog("law详细查询", new
        {
            this.Command
        }, endTime: new DateTime(2018, 9, 30, 20, 0, 0));
#if DEBUG
        return Search(query);
#else
        try
        {
            return Search(query);
        }
        catch (Exception ex)
        {
            Common.Program.WriteObjectLog("law详细查询", new
            {
                query,
                error = ex.ToString()
            });
            throw;
        }
#endif这里首先使用条件编译语句，区分 BEBUG 和 Release，在 DEBUG 中根本不去 try...catch。然后在 Release 的时候，在特定的日志文件中，记录了参数 query 和异常堆栈信息。当出现错误的时候，你需要贴出特定的日志文件，查看当时的变量值和异常堆栈。如果贴不出来错误日志，那就不算是能够 debug。这就好像一个庸医不首先拿到诊断书，而是只能乱猜乱想什么以学书本上的教条。

调试易

sqlserver内存占用过高

解决方案 »