sqlserver内存占用过高

BXS_null 2018-09-30 10:22:22
服务器是32G的,但是经常因为数据库内存达到30G左右然后IIS爆炸。
在网上查了说是更改属性里面的最大服务器内存


我就是想问下:
1.改了最大服务器内存值是否有用。如果sqlserver内存超过了这个值会怎么样

2.上面那个选项 “使用AWE分配内存” 是做啥用的,需要勾选吗

3.关于数据库内存过高还有没有其他更好的解决办法。
...全文
2343 38 打赏 收藏 转发到动态 举报
写回复
用AI写文章
38 条回复
切换为时间正序
请发表友善的回复…
发表回复
weixin_43083875 2018-10-02
  • 打赏
  • 举报
回复
可以看看官网上最新的消息,一定可以找到相关信息
  • 打赏
  • 举报
回复
出现异常时,好像是服务器机器的什么内存和操作信息都要,其实等于根本不知道要怎么诊断。 所以首先就是要知道你的代码具体是哪一行语句出的错误。如果不知道除了异常时第一时间获取这个行号信息,绝对是乱猜!
  • 打赏
  • 举报
回复
通常,一个程序发布之前应该运行自动测试(顺序执行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。这就好像一个庸医不首先拿到诊断书,而是只能乱猜乱想什么以学书本上的教条。
  • 打赏
  • 举报
回复
引用 18 楼 weixin_40068689 的回复:
去检查出错的语句、日志记录出错的环境(输入变量值)。在你电脑上重现 bug。 你可以想想看,不重现 bug,而是把时间花在与运行时明显的 bug 无关的地方,不可能解决 bug。
weixin_42732594 2018-10-01
  • 打赏
  • 举报
回复
学习到了感谢
  • 打赏
  • 举报
回复
引用 18 楼 weixin_40068689 的回复:
这个。这个也有可能。这个之前也出现过。后来百度说是缓存过期了,我按照上面说的把缓存时间改成100年了,现在还是报错了。这咋解决。
这首先要检查你的 and_user.cs 的110 行之类的代码。 不要纠结什么数据库,那只是结果,根本不是原因。如果你纠结于结果等于绕弯弯在乱猜原因!
xuzuning 2018-09-30
  • 打赏
  • 举报
回复
IIS和网站应用程序都需要内存,并随并发连接数增加而增加
若剩余得可用内存 小于 最大服务器内存 时,必然会对数据库的运行带来影响,盲目加大 最大服务器内存,只能是弊大于利
大鱼> 2018-09-30
  • 打赏
  • 举报
回复
数据库里面有个报表服务会占内存,这个如果没用可以关掉
BXS_null 2018-09-30
  • 打赏
  • 举报
回复
引用 14 楼 yenange 的回复:
[quote=引用 10 楼 weixin_40068689 的回复:] 好 谢谢 新增服务器是没指望的,我们公司很穷的。。 如果是设置数据库的内存大小就是设置数据库里面最大服务器内存是吧?
#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
[/quote] 我用的sql2005执行不了额, 消息 102,级别 15,状态 1,第 36 行 '.' 附近有语法错误。 这一行 CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
BXS_null 2018-09-30
  • 打赏
  • 举报
回复
引用 17 楼 sp1234 的回复:
你还是需要详细分析、断点跟踪你的“爆炸”的故障环境。比如说知道具体是哪一个页面、哪一个方法、甚至哪一条语句时会“爆炸”。不了解细节操作,则根本不知道宏观的概念具体如何落实。
从这里开始的,是一个添加语句,还有其他的修改语句。 日志一直到一点钟就没动静了,估计是网站挂了。 还有一个错误!!!刚刚看到 这个。这个也有可能。这个之前也出现过。后来百度说是缓存过期了,我按照上面说的把缓存时间改成100年了,现在还是报错了。这咋解决。
  • 打赏
  • 举报
回复
如果你不找原因,而只是修改皮毛,你会发现,故障出现的概率不变、甚至更频繁了。
  • 打赏
  • 举报
回复
引用 7 楼 weixin_40068689 的回复:
[quote=引用 5 楼 sp1234 的回复:] 所谓“爆炸”我估计是你们的某个 web 程序有 BUG。一锅汤里混入了一个蟑螂,这个时候要有能力及时发现蟑螂,而不是把锅缩小尺寸。
也有可能是bug 因为每次网站挂掉的时候我去看内存都是数据库占了30G,然后重启就好了。。[/quote] 你这个就是把结果当作原因,这不是找故障原因的正确方法。
  • 打赏
  • 举报
回复
你还是需要详细分析、断点跟踪你的“爆炸”的故障环境。比如说知道具体是哪一个页面、哪一个方法、甚至哪一条语句时会“爆炸”。不了解细节操作,则根本不知道宏观的概念具体如何落实。
BXS_null 2018-09-30
  • 打赏
  • 举报
回复
这是今天凌晨报的错,早上七点多起来看网站就挂掉了
吉普赛的歌 2018-09-30
  • 打赏
  • 举报
回复
引用 10 楼 weixin_40068689 的回复:
好 谢谢 新增服务器是没指望的,我们公司很穷的。。 如果是设置数据库的内存大小就是设置数据库里面最大服务器内存是吧?
#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
正怒月神 2018-09-30
  • 打赏
  • 举报
回复
引用 7 楼 weixin_40068689 的回复:
[quote=引用 5 楼 sp1234 的回复:] 所谓“爆炸”我估计是你们的某个 web 程序有 BUG。一锅汤里混入了一个蟑螂,这个时候要有能力及时发现蟑螂,而不是把锅缩小尺寸。
也有可能是bug 因为每次网站挂掉的时候我去看内存都是数据库占了30G,然后重启就好了。。[/quote] 挂掉时30G,那么平时你看过吗?是多少呢
BXS_null 2018-09-30
  • 打赏
  • 举报
回复
引用 9 楼 yenange 的回复:
[quote=引用 7 楼 weixin_40068689 的回复:] [quote=引用 5 楼 sp1234 的回复:] 所谓“爆炸”我估计是你们的某个 web 程序有 BUG。一锅汤里混入了一个蟑螂,这个时候要有能力及时发现蟑螂,而不是把锅缩小尺寸。
也有可能是bug 因为每次网站挂掉的时候我去看内存都是数据库占了30G,然后重启就好了。。[/quote] 真不是 bug . 我在 #3 的评论, 你仔细看完, 就会明白: 数据库最好不要跟应用放在一起。 数据库的争夺性非常强, 你没限制的话肯定会挤压 iis 的内存空间。 如果数据库的问题, 百度一下就能解决, DBA 就没有必要了。[/quote] 好 谢谢 新增服务器是没指望的,我们公司很穷的。。 如果是设置数据库的内存大小就是设置数据库里面最大服务器内存是吧?
BXS_null 2018-09-30
  • 打赏
  • 举报
回复
引用 11 楼 hanjun0612 的回复:
[quote=引用 7 楼 weixin_40068689 的回复:] [quote=引用 5 楼 sp1234 的回复:] 所谓“爆炸”我估计是你们的某个 web 程序有 BUG。一锅汤里混入了一个蟑螂,这个时候要有能力及时发现蟑螂,而不是把锅缩小尺寸。
也有可能是bug 因为每次网站挂掉的时候我去看内存都是数据库占了30G,然后重启就好了。。[/quote] 挂掉时30G,那么平时你看过吗?是多少呢[/quote] 平时一般维持在28G左右 到30G的时候就不行了。重启的话一般是从几G开始上涨
吉普赛的歌 2018-09-30
  • 打赏
  • 举报
回复
引用 7 楼 weixin_40068689 的回复:
[quote=引用 5 楼 sp1234 的回复:] 所谓“爆炸”我估计是你们的某个 web 程序有 BUG。一锅汤里混入了一个蟑螂,这个时候要有能力及时发现蟑螂,而不是把锅缩小尺寸。
也有可能是bug 因为每次网站挂掉的时候我去看内存都是数据库占了30G,然后重启就好了。。[/quote] 真不是 bug . 我在 #3 的评论, 你仔细看完, 就会明白: 数据库最好不要跟应用放在一起。 数据库的争夺性非常强, 你没限制的话肯定会挤压 iis 的内存空间。 如果数据库的问题, 百度一下就能解决, DBA 就没有必要了。
BXS_null 2018-09-30
  • 打赏
  • 举报
回复
引用 5 楼 sp1234 的回复:
所谓“爆炸”我估计是你们的某个 web 程序有 BUG。一锅汤里混入了一个蟑螂,这个时候要有能力及时发现蟑螂,而不是把锅缩小尺寸。
也有可能是bug 因为每次网站挂掉的时候我去看内存都是数据库占了30G,然后重启就好了。。
加载更多回复(18)
本课程根据讲师十多年在世界500强外企的生产环境中的SQL Serer数据库管理和项目实施经验倾心打造。课程系统性强,知识体系完整,覆盖90%以上的企业环境下SQL Server高可用场景,课程中不仅演示详细的操作步骤,更加突出最常见的故障和问题,让学员少走“弯路”,不只是让学员学会“操作”更能让学员“操作”的规范,满满的干货分享,一些课程资料(架构图、部署规划表格等)不仅可以帮助学员掌握技能,也可以作为学员在企业生产环境中实施SQL Server高可用的配置文档、操作手册等。课程的实验环境介绍:1)全部基于微软域环境和企业版SQL Server AOAG - 95%以上的企业环境都是在域环境中,不介绍非域环境和标准版的SQL Server高可用性组,这的配置在企业中较罕见,没有实践意义,不浪费学员时间。2)相应域环境已提前部署和配置好 - 学员导入虚拟机即可开始实验,无需从零开始搭建域环境,所有实验中SQL Server均已加域,直入主题,节省大量时间。3)最新的Windows Server故障转移集群(WS2016、WS2019)和最新版本的SQL Server(SQL2017、SQL2019) -  WS2016-SQL2017与WS2019-SQL2019是目前大多数企业SQL Server高可用的主要平台,基于微软产品生命周期现在一些企业也在讲早期的AOAG向这两个版本迁移,掌握这两种组合不仅让学员学会,更能学有所用。本课程为后续SQL Server进阶课程铺垫,是通向SQL Server DBA 专家的必经之路,讲师每周答疑两次。所有课程资料包括:课程PPT、架构图、部署规划表格、各类脚本学员均可下载。     

110,477

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • Web++
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧