Производительность запросов SQL Server замедляется со временем

Question

Я видел этот вопрос во многих отношениях по всему Интернету, но, несмотря на обилие советов (и некоторых вуду), я все еще боюсь. У меня есть база данных 100 ГБ +, которая постоянно вставляет и обновляет записи в очень больших транзакциях (более 200 операторов на транс). После перезапуска системы производительность потрясающая (данные записываются на большой SSD-накопитель SATA III, подключенный через USB 3.0). Экземпляр SQL Server работает на виртуальной машине, работающей под рабочей станцией VMWare. Хост настроен на сохранение всей виртуальной памяти в памяти. Сама виртуальная машина имеет кэш пейджинга 5000 МБ. Пользователь SQL Server настроен на «удерживание страниц в памяти». У меня есть 5 ГБ ОЗУ, выделенных для виртуальной машины, а максимальная память экземпляра SQL Server равна половине Gig.

Я играл с каждым одним из этих параметров, чтобы попытаться поддерживать стабильную производительность, но уверенность и устойчивость, производительность в конечном итоге ухудшается до такой степени, когда она начинает тайм-аут. Но вот кикер, если я остановлю приложение, загружающее базу данных, а затем запустил сохраненный процесс в Management Studio, он работает как молния, четко указывая на то, что это не проблема с запросом и, вероятно, не имеет ничего общего с управлением памятью или пейджинг. Если я перезапущу приложение-загрузчик, он все равно сканирует. Если я перезагружу виртуальную машину, приложение снова будет работать как молния ... какое-то время ...

Есть ли у кого-нибудь другие предложения, основанные на представленных симптомах?

Answer 1

В конце концов, я сделал комбинацию из двух вещей, введя логику для восстановления при возникновении тайм-аутов и установив подсчет ядра ядра только для отображения физических ядер, а не для логических ядер, так что, например, 2 ядра, которые являются гиперпоточными. Когда я устанавливаю свою виртуальную машину на использование 4 ядер, она иногда зависает в бесконечном цикле, но когда я устанавливаю ее на 2 ядра, она запускается без сбоев. Тем не менее, аберрантное поведение, подобное этому, трудно смягчить надежно.

Answer 2

• В зависимости от того, насколько велика ваша горячая сетка, 5 ГБ памяти может взимать налог только за базу данных 100 + gb.

• Проверка индексов и планов запросов. Мы не можем вам помочь без них. И я уверен, вы пропустите некоторые показатели - это стандартная проблема производительности, которую люди испытывают.

• В противном случае, как только вы сделали домашнее задание, перейдите к dba.stackexchange.com и спросите об этом.

• Как правило, считайте, что 200 операторов за транзакцию могут просто означать серьезное субоптимальное программирование. Например, вы можете массировать данные в таблицу temp, а затем сливаться в финальную.

Answer 3

Попробуйте выполнить это, чтобы определить проблемные вопросы:

SELECT TOP 20 
    qs.sql_handle, 
    qs.execution_count, 
    qs.total_worker_time AS Total_CPU, 
    total_CPU_inSeconds = --Converted from microseconds 
     qs.total_worker_time/1000000, 
    average_CPU_inSeconds = --Converted from microseconds 
     (qs.total_worker_time/1000000)/qs.execution_count, 
    qs.total_elapsed_time, 
    total_elapsed_time_inSeconds = --Converted from microseconds 
     qs.total_elapsed_time/1000000, 
st.text, 
qp.query_plan 
FROM 
sys.dm_exec_query_stats as qs 
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as st 
cross apply sys.dm_exec_query_plan (qs.plan_handle) as qp 
ORDER BY qs.total_worker_time desc 

Затем проверить сметные и фактические планы выполнения запросов на эту команду помогает вам определить.

Источник How do I find out what is hammering my SQL Server? и в нижней части страницы http://technet.microsoft.com/en-us/magazine/2007.11.sqlquery.aspx

Answer 4

На самом деле, я могу иметь рабочую теорию. То, что я сделал, это добавить некоторую логику в приложение, когда он истекает, сидите в течение двух минут, а затем повторите попытку и вуаля! Вернитесь на полную скорость. Я уволил своего коллегу и придумал концепцию, согласно которой мои воспринимаемые скорости записи SSD были фактически скоростью записи в виртуальный буфер USB 3 VMWare, и что фактические скорости записи SSD были медленнее. Я, вероятно, сталкиваюсь с размером буфера хоста и заставляя приложение ждать 2 минуты, у хоста есть возможность сбросить свои данные с буферизацией обратно на SSD. Элементарно, Ватсон :)

Если этот подход также не будет устойчивым, я доложу в.

Answer 5

За отличные индексированию предложений уже приведенных, обязательно прочитать на параметр нюхают. Это может быть причиной проблемы.

SQL Server - parameter sniffing

http://www.sommarskog.se/query-plan-mysteries.html#compileps

В результате вы можете иметь плохой план запроса используется повторно, или буфер SQL не может быть получение полной и записи страниц из памяти на диск (может быть, другая выделенная память в твоем случае).

Вы можете запустить DBCC FreeProcCache и DBCC FreeSystemCache, чтобы очистить его и посмотреть, есть ли у вас повышение производительности.

Вы также должны предоставить SQL больше памяти - столько, сколько сможете, оставив место для других критических программ и ОС. У вас может быть 5 гб Ram на виртуальной машине, но SQL только начинает играть с 1/2 gb, что кажется ДЕЙСТВИТЕЛЬНО маленьким для того, что вы описываете.

Если эти вещи не перемещают вас в правильном направлении, установите хранилище данных управления SQL, чтобы вы могли точно видеть, что происходит, когда начинается ваше замедление. Запуск занимает дополнительную память, но вы дадите DBA больше для продолжения.