☰

SQL Server 2008 性能不佳 - 迁移到新服务器后速度极慢

tag-icon • tag-icon sql-server-2008 datacenter
SQL Server 2008 性能不佳 - 迁移到新服务器后速度极慢

上周末，我们将生产数据库移到了一台新服务器上。这是一台 Windows Server 2008 R2 数据中心。上面安装的是 SQL Server 2008 Enterprise Edition 64 位的全新版本。周日，迁移完成后，一切看起来都很正常。但是，一旦用户在周一早上开始使用该应用程序，速度就会变得非常缓慢，并且从那以后一直很慢。

我认为我已经将问题隔离到了 tempdb，因为当我检查时，几乎所有正在运行的活动进程都是插入到临时表中的。此查询：

SELECT '1' AS Number,GETDATE() AS Date INTO #Temp

Go

INSERT INTO #Temp
VALUES ('1', GETDATE())

GO 1000

在我的新 2008 服务器上需要 20 秒，而在装有 SQL 2005 的旧服务器上，只需 2-3 秒。

新服务器有 128 GB 内存，在任何时候，它只使用 35 GB 内存用于所有进程。在旧的生产服务器上，内存使用率在任何给定点至少为 50%，即使几乎没有人使用它，而我们的开发环境内存使用率约为 80%，这很好也很正常。我不知道为什么新服务器上的 SQL Server 2008 只使用了可用内存的一小部分。

我们重新配置了 tempdb，使其使用 10 个大小相同的数据文件，之前在旧服务器上只有 1 个，核心/文件比率为 8:1。新服务器上有 48 个核心，因此核心/文件比率为 48:10。这里的一位高级 DBA 为 tempdb 又创建了 10 个辅助数据文件和 5 个日志文件，但这似乎毫无帮助。

我检查了 perfmon 的总内存，看起来内存已经耗尽。我没有配置任何内存限制，所以它应该会使用所有可用内存，对吗？

我尝试在 Google 上搜索有关 tempdb 和内存使用情况的答案，所有建议似乎都针对 2003 版之前的服务器或 34 位系统。我找不到任何与 Windows Server 2008 R2 数据中心和 SQL Server 2008 实例相关的信息。

网络人员也尝试过致电微软，但是他们至今仍无法提供帮助。

请帮帮我。我确信这是内存/tempdb 问题，但我似乎无法让 SQL 使用它可用的所有内存。

答案1

您的高级 DBA 不知道自己在做什么。遗憾的是，添加多个日志文件对提高性能毫无帮助。遗憾的是，他不知道日志文件的工作原理。日志文件是按顺序使用的，如果您添加 5 个以上的日志文件，除非第一个日志文件已完全使用，否则它们无论如何都不会被使用。在正常的日常操作中不会发生这种情况。

至于向 tempdb 添加多个数据文件，微软和行业专家对此建议存在一些分歧。微软态度很好，建议核心文件比例为 1:1，但在所有情况下，这都不是必要的。行业专家表示，只有 1:1/4 到 1:1/2 就足够了，但您需要注意 2:1:1（页面可用空间，即 PFS 瓶颈）和 2:1:3（SGAM 瓶颈），并根据需要调整文件数量。在某些极端情况下，您可能还必须添加比核心数量更多的文件，但这是一个很大的“视情况而定”问题。

说到内存问题，您是否检查过页面文件的使用率、页面预期寿命、缓冲区缓存命中率。如果这些数字看起来不错，那么可能是这台新服务器的压力不够大。

在更改 tempdb 中的文件数之前，您需要查看等待统计信息。如果 24 个文件对您有用，那么它很好，但请查看等待统计信息并找出 tempdb 是否是瓶颈。请注意，tempdb 有两种常见的瓶颈类型（IO + 分配瓶颈）。如果是分配瓶颈，那么您可能还想使用 TF 1118。

-- Isolate top waits for server instance since last restart or statistics clear
WITH Waits AS
(SELECT wait_type, wait_time_ms / 1000. AS wait_time_s,
100. * wait_time_ms / SUM(wait_time_ms) OVER() AS pct,
ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS rn
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK'
,'SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR', 'LOGMGR_QUEUE','CHECKPOINT_QUEUE'
,'REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH','BROKER_TASK_STOP','CLR_MANUAL_EVENT'
,'CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE', 'FT_IFTS_SCHEDULER_IDLE_WAIT'
,'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP'))
SELECT W1.wait_type, 
CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2
ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 99 OPTION (RECOMPILE); -- percentage threshold

答案2

除了 @Sankar 解释的内容之外，升级后，在 Windows 2008 R2 上运行的 SQL Server 存在一个已知问题，服务器运行省电模式（默认情况下处于开启状态），这会影响查询性能，特别是当您的服务器没有承受巨大压力时（CPU 可能会以一半的速度运行以节省电量）。请查看这 这和这博客了解详情。

答案3

大家好，感谢你们提供的所有有用的建议和链接。我已将这些信息中的很多内容传递给了我们的系统管理员，因为我实际上没有该服务器的管理员权限，只有 SQL 的管理员权限。星期五我们将 tempdb 文件重组为 24 个数据文件，并删除了次要数据文件和额外的日志文件，这似乎很有帮助。不过，星期五下午或周末我们的负载并不大，因此很难判断仅凭这一点是否解决了问题。

周末还做了一些工作，直到昨天我才知道。他们在服务器上安装了 SQL Server 2005 和几个服务包。（我猜他们想有一个可用的备份实例，我真的不知道原因）当 2005 实例处于活动状态时，RAM 使用率飙升至正常水平。SQL Server 2005 实例被删除后，2008 实例的 RAM 使用率仍然很高，这很好 - 我们希望 2008 开始使用所有可用的 RAM。所以我不知道是 2005 实例启动了某些事情，还是其中一个服务包（尽管它们都是旧的，此时不应该是必要的），但现在 RAM 也达到了我们想要的水平。

如果我没有向大家回复具体的统计数据，我很抱歉。我只是一个中级 DBA，真的没必要在这种事情上浪费时间，我碰巧在 Google 上找到了 tempdb 核心：文件比率问题，这可能是一个奇迹。

我假设 tempdb 主文件结构是关键。因此，我希望这至少可以帮助遇到相同问题的其他用户。

相关内容