В прошлые выходные мы переместили нашу производственную базу данных на новый сервер. Это центр обработки данных Windows Server 2008 R2. На нем установлена новая 64-разрядная версия SQL Server 2008 Enterprise Edition. В воскресенье, после завершения переезда, все выглядело нормально. Но как только пользователи начали использовать приложение в понедельник утром, все замедлилось до сканирования и с тех пор идет медленно.
Я думаю, что я изолировал проблему от tempdb, поскольку почти все активные процессы, запущенные, когда я проверяю, вставляются во временные таблицы. Этот запрос:
SELECT '1' AS Number,GETDATE() AS Date INTO #Temp
Go
INSERT INTO #Temp
VALUES ('1', GETDATE())
GO 1000
Занимает 20 секунд на моем новом сервере 2008 года, тогда как на старом сервере с SQL 2005 это занимает всего 2-3 секунды.
Новый сервер имеет 128 ГБ оперативной памяти, и в любой момент времени он использует всего 35 ГБ для всех процессов. На старом производственном сервере использование оперативной памяти составляет не менее 50% в любой момент, даже если это почти никто не использует, а в нашей среде разработки это около 80%, что хорошо и нормально. Я понятия не имею, почему наш SQL Server 2008 на новом сервере использует только крошечную часть доступной оперативной памяти.
Мы перенастроили нашу базу данных tempdb для использования 10 файлов данных одинакового размера, раньше на нашем старом сервере было 1 с соотношением ядра / файла 8: 1. У нас 48 ядер на этом новом сервере, так что соотношение ядра / файла 48:10. Один из самых ср. Администраторы баз данных создали еще 10 дополнительных файлов данных для tempdb и еще 5 файлов журнала, но это, похоже, не помогло.
Я проверил perfmon на предмет общей памяти, и похоже, что он выравнивается. У меня нет никаких ограничений на сконфигурированную память, поэтому она должна использовать все доступное, верно?
Я пробовал искать ответы на свои вопросы о tempdb и использовании памяти, и все советы, похоже, ориентированы на более ранние серверы 2003 года или 34-битные системы. Я не могу найти никакой соответствующей информации, которая могла бы помочь с центром обработки данных Windows Server 2008 R2 и экземпляром SQL Server 2008.
Сетевой специалист тоже пытался позвонить в Microsoft, но пока они не смогли помочь.
Пожалуйста, помогите мне. Я действительно убежден, что это проблема с памятью / tempdb, но я не могу заставить SQL использовать всю доступную ему память.
Ваш старший администратор базы данных не знает, что делает. К сожалению, добавление нескольких файлов журналов не способствует повышению производительности. Жаль, что он не знает, как работают файлы журналов. Файлы журнала используются последовательно, и если вы добавите еще 5 файлов журнала, они все равно не будут использоваться, если первый не будет использован полностью. В обычных повседневных операциях этого не произойдет.
Что касается добавления нескольких файлов данных в tempdb, существует некоторый конфликт между MSFT и отраслевыми экспертами по рекомендации. MSFT играет хорошо и рекомендует 1: 1 для файлов core:, но во всех случаях это НЕ обязательно. Отраслевые эксперты говорят, что достаточно от 1: 1/4 до 1: 1/2, но вам нужно следить за 2: 1: 1 (свободное пространство страницы, т.е. узкое место PFS) и 2: 1: 3 (узкое место SGAM) и настраивать количество файлов по мере необходимости. В некоторых крайних случаях вам может потребоваться добавить больше файлов, чем количество ядер, но это большой вопрос «Зависит».
Переходя к проблеме с памятью, вы проверили% использования PageFile, Page Life Expectancy, коэффициент попадания в буферный кеш. Если эти цифры выглядят хорошо, возможно, этот новый сервер недостаточно нагружен.
Перед изменением количества файлов в tempdb вам необходимо просмотреть статистику ожидания. Если у вас сработало 24 файла, то это хорошо, но посмотрите статистику ожидания и выясните, является ли tempdb узким местом. Обратите внимание, что существует 2 общих типа узких мест для tempdb (узкое место ввода-вывода + выделения). Если это узкое место при распределении, вы также можете использовать 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
Помимо того, что объяснил @Sankar, после обновления существует известная проблема, связанная с SQL Server, работающим на Windows 2008 R2, с сервером, работающим в режиме энергосбережения (который включен по умолчанию), и это влияет на производительность запросов, особенно если ваши серверы не слишком большие. давление (ЦП может работать наполовину медленнее для экономии энергии). проверять, выписываться этот этот и этот блоги для деталей.
Привет, ребята, спасибо за полезные советы и ссылки. Я передал большую часть этой информации нашему системному администратору, так как на самом деле у меня нет прав администратора на этом сервере, только на SQL. После пятницы, когда мы реструктурировали файлы tempdb до 24 файлов данных и избавились от вторичных файлов данных и дополнительных файлов журналов, это, похоже, очень помогло. Однако у нас не было большой нагрузки в пятницу днем или в выходные, поэтому было трудно сказать, решило ли это одно только это.
На выходных была проделана еще одна работа, о которой я не знал до вчерашнего дня. Они установили на сервере SQL Server 2005 и несколько пакетов обновлений. (Я предполагаю, что они хотели иметь доступный экземпляр резервной копии, я действительно не знаю причины) Когда экземпляр 2005 года был активен, использование ОЗУ резко увеличилось до нормального уровня. Экземпляр SQL server 2005 был удален, использование ОЗУ осталось высоким и для экземпляра 2008 года, что хорошо - мы хотели, чтобы 2008 год начал использовать всю доступную ему оперативную память. Поэтому я не знаю, был ли это экземпляр 2005 года, который что-то запустил, или один из пакетов обновлений (хотя все они были старыми, которые не должны были быть необходимы на данном этапе), но теперь ОЗУ находится там, где мы этого хотим. слишком.
Прошу прощения, если я не ответил всем о конкретной статистике. Я всего лишь администратор баз данных среднего уровня, и у меня нет никакого дела до такого рода вещей, и, вероятно, это было чудом, что я случайно заглянул в Google и обнаружил проблему соотношения ядра tempdb и файлов.
Я предполагаю, что ключевой была структура первичного файла tempdb. Итак, я надеюсь, что, по крайней мере, это может помочь любому, у кого возникла такая же проблема.