增加的RAM,性能更差


9

设定:

  • Windows Server 2008 R2
  • SQL Server 2008 R2 SP1
  • 240GB RAM
  • TempDB是8x16GB数据文件,没有自动增长(总共128GB)
  • 物理/独立服务器

该服务器用于ETL处理。我们刚刚在此服务器上安装了更多RAM,总共有240GB RAM。SQL Server服务是唯一可运行的东西。

内存在BIOS,OpenManage和Windows中显示正常。

如果我将SQL Server配置为使用最小/最大70 / 100GB内存,则没有问题。但是,一旦将其增加到120 / 150GB,则在运行我们的ETL进程之一时会出现以下错误:

无法为数据库“ tempdb”中的对象“ <临时系统对象:422234507706368>”分配空间,因为“ PRIMARY”文件组已满。通过删除不需要的文件,在文件组中删除对象,向文件组添加其他文件或为文件组中的现有文件设置自动增长来创建磁盘空间。(消息1105,状态2,过程未知,第1行)

在更改内存配置之前,我们从未遇到过此问题。重新配置回原始的70 / 100GB后,我们不会收到此错误。

我尝试过的事情:

  1. 将TempDB数据文件设置为自动增长。这只会导致文件自动增长,直到达到磁盘容量,然后失败。
  2. 添加更多的TempDB数据文件。与显示的错误相同。
  3. 将TempDB的大小增加到8x32GB(总共256GB)

我对可能导致此问题的原因不知所措。


2
您的内存在NUMA个节点之间是否平衡?你的处理器怎么样?SQL Server日志是否显示启动期间正在使用多少个CPU?
亚伦·伯特兰

1
您在ETL流程中使用什么?SSIS或类似的工具?如果它是SQL Server之外的工具,您是否在与SQL Server实例相同的服务器上运行它?
Mike Fal 2013年

1
@Mike很好,如果ETL进程无法捕获足够的内存来执行其任务,因为SQL Server使用过多,则可能必须将工作推送到tempdb。
亚伦·伯特兰

1
这是监视tempdb使用情况的一个很好的开始:msdn.microsoft.com/zh-cn/library/ms176029(v=SQL.105).aspx。这应该使您对正在发生的事情有所了解。
Thomas Stringer

2
在TempDB实际扩展时,您是否对实际运行的内容进行了任何分析?一个简单的sp_who2 / sp_whoisactive?在我看来,您有一些长期运行的事务可以更好地管理,但很难分辨。就个人而言,我不会继续关注内存更改,而是先查看代码,看看它是否运行正常。
Mike Fal 2013年

Answers:


3

感谢大家的帮助。

仔细研究了一些执行计划后,结果发现有一个JOIN会根据可用的RAM量进行不同的处理。RAM较少时,将使用哈希值对其进行评估。具有更多的RAM,它使用一系列合并联接。

因此,基本上可以归结为我目前正在重构的T-SQL编写不佳。


4
这是很不直观的,因为哈希联接需要内存授予,而合并则不需要。是否有其他排序操作来支持合并联接?
马丁·史密斯

1

这不是问题的答案,只是我不想在评论中发布的一些代码。要查看NUMA节点之间的调度程序和内存的平衡(并查看是否在线上看不到任何节点):

SELECT 
  parent_node_id, 
  [status],
  AVG(current_tasks_count) AS avg_tasks_count, 
  AVG(load_factor) AS avg_load_factor,
  scheduler_count = COUNT(*)
FROM sys.dm_os_schedulers
GROUP BY parent_node_id, [status];

SELECT 
  memory_node_id, 
  name, 
  SUM(single_pages_kb + multi_pages_kb) AS memory_kb
FROM sys.dm_os_memory_clerks
GROUP BY memory_node_id, name;

(在SQL Server 2012中,最后一个SUM应该是SUM(pages_kb)因为不再有单独的单页和多页分配器。)

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.