sqlserver内存占用过高

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


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

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

3.关于数据库内存过高还有没有其他更好的解决办法。
...全文
2368 38 打赏 收藏 转发到动态 举报
AI 作业
写回复
用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)
SQL Server 2005微软官方权威参考书.   公球公认SQL Server 2005 经典著作..   数据库“铁人”、微软MVP胡百敬先生鼎力推荐   微软SQL Server 总部Principal Group 项目经理朱凌志鼎力推荐   本书详细介绍了数据引擎的基础运作,包含了数据库的设定与数据实际在硬盘的摆放、索引结构、事务与锁定等。除了解释设计理念与运作原理外,还辅之以测试验证的方式。数据库开发者和管理员可从中获得最优的方法、务实的建议和实例代码来帮助他们掌握创建和维护企业级关系数据库所需的复杂技术。该书获得资深专家关于创建和维护健壮数据库的高屋建瓴般的视野和入木三分的剖析,十分适合有一定数据库基础的读者学习。 内容简介 本书是Inside Microsoft SQL Server 2000的作者Kalen Delaney的又一经典著作,是Inside Microsoft SQL Server 2005系列四本著作中的一本。本书对SQL Server 2005存储引擎方面的知识进行了全面而详细的阐述,包括数据库文件、日志和恢复、表、索引及其管理、锁定和并发等内容。除了解释设计理念与运作原理外,书中还辅之以大量简短而有力的实例。您将跟随一位广受欢迎的作家同时也是SQL Server资深专家一起深入探索SQL Server存储引擎的技术内幕。   本书适合于专业数据库开发者、BI开发者、DBA和以SQL Server作为后台数据库的一般应用程序开发者。本书不仅适合SQL Server 2005的初级读者,也适合SQL Server 2005的中高级读者。读者可以从中获得最优的方法、务实的建议和实例代码来帮助他们掌握创建和维护企业级关系数据库所需的复杂技术。本书是所有SQL Server 2005用户的案头必备之书。 作者简介 Kalen Delaney,她还是微软出版社inside SQL Sever丛书的编辑。她从1987年开始便一直从事SQL Server相关的工作,1995年被评为MVP(微软最有价值专家》。她同时也是Solid Quality Learning的首席顾问和创始人。除此之外,她还是SQL Server Magazine的优秀编辑和专栏作家,她还写作了大量的SQL Server类书籍,包括著名的Inside Microsoft SQL Server2000。 目录 前言 致谢 引言 第1章 SQL Server 2005 的安装与升级  1.1 SQL Server 2005安装前提   SQL Server 2005 版本   软件要求   硬件要求  1.2 安装前决策   安全性和用户上下文   字符与排序规则   排序次序   安装SQL Server的多个实例   安装SQL Server命名实例  1.3 做好安装准备   SQL Server 2005升级向导  1.4 迁移还是升级   迁移   升级   升级后的操作  1.5 选择组件   SQL Server数据库服务(数据库引擎)   Analysis Services   Reporting Services   Notification Services   Integration Services   工作站组件、联机丛书及开发工具  1.6 小结 第2章 SQL Server 2005体系结构  2.1 SQL Server引擎组件   观测数据库引擎行为   协议   表格格式数据流(TDS)端点   关系引擎   存储引擎   SQLOS  2.2 内存   缓冲池和高速数据缓冲区   访问内存中的数据页   管理数据高速缓冲区中的页面   检查点   管理其他高速缓存中的内存   调节内存大小   调节缓存池大小  2.3 小结 第3章 SQL Server 2005的配置  3.1 使用SQL Server 配置管理器   配置网络协议   默认的网络配置   管理服务  3.2 系统配置   任务管理   资源分配   系统分页文件的位置   非必需的服务   网络协议   与SQL Server 早期版本之间的兼容性   跟踪标记(Trace Flags)   SQL Server 的配置设定   内存选项   调度选项(Scheduling Options)   磁盘I/O 选项   查询处理选项   默认跟踪(Default Trace)  3.3 小结 第4章 数据库和数据库文件 第5章 日志和恢复 第6章 表 第7章 索引的内部构造和管理 第8章 锁定和并发

111,098

社区成员

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

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

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