Запросы не поделили Buffer I/O

← →
Ринсвинд © (2015-07-23 14:58) [0]

Всем привет.

Есть сервер. Обычный, железный, не виртуальный. Не первой свежести, но все же неплохой: Windows server 2008 R2, 32 ГБ ОЗУ, 64 bit.

На нем стоит MS SQL SERVER 2012 standart edition.

В нем есть БД сторонней программы. Разумеется, ее нельзя менять, на нее нельзя навешивать триггеры, индексы и т.д. Но ее нужно мониторить: вылавливать определенные события и сообщать про них пользователям.

Для этого у меня есть программа, опрашивающая базу с определенной периодичностью. Все работало нормально до апгрейда ПО. Но вот сторонняя программа обновилась, это потребовало обновление БД, а вот железо осталось прежним. Теперь пользователи сторонней программы начали жаловаться на фризы.

Монитор активности показывает, что во время выполнения запросов мониторящей программы, появляется несколько других запросов, ожидающих ресурса "Buffer I/O". Для отслеживания событий используются действительно крупные запросы, объединяющие в себе несколько таблиц с миллионами записей. Предположительно, новая версия MS SQL SERVER оказалась более прожорливой к ресурсам, и для выполнения запроса, ищущего события, съедаются все имеющиеся ресурсы.

Вряд ли получится оптимизировать запросы. Я и так из них все соки выжал... Согласно плану выполнения, основные затраты времени в самом большом запросе идут на поиск по кластерному индексу в большой таблице. Чуть меньше времени идет на сканирование еще одной очень большой таблицы. Даже индексы на нее навесить нельзя, т.к. она чужая...

Посоветуйте, пожалуйста, что можно сделать в данной ситуации? Возможно, в MS SQL SERVER есть какие-нибудь способы отслеживания событий, не влияющие на функционирование БД?

Если менять сервер, то, как я понимаю, прежде всего нужно ставить больше оперативки? Сейчас ее 32 ГБ. Замена сервера все равно рано или поздно будет необходима. Но сейчас это проблематично. Поэтому хотелось бы знать ваше мнение - действительно ли апгрейд может помочь, и, если да, то какой? Удвоение ОЗУ до 64 ГБ?

Заранее спасибо.

← →
Ринсвинд © (2015-07-23 15:16) [1]

Еще возникла идея убрать файл подкачки. Но для этого тоже придется останавливать сервер, а системные администраторы говорят, что это нежелательно. Насколько это может помочь? Хотя, не думаю, чтобы MS SQL SERVER путал ОЗУ и подкачку и размещал свой буфер на жестком диске.

← →
backuper (2015-07-23 21:15) [2]

вопрос глупый, но все же.. (nolock) прописан в запросах?

← →
Ринсвинд © (2015-07-24 08:42) [3]

> backuper (23.07.15 21:15) [2]

Увы, но ни NoLock, ни даже уровень изоляции транзакции READ UNCOMMITTED не помогает... Дело не в блокировках, это видно и в мониторе активности.

Зато помогает постоянное выполнение одного запроса. Если выполнять его с интервалом в несколько секунд, почти все страницы участвующих в нем таблиц перекачиваются в пул, и запрос начинает выполняться на 20-30 сек а всего 5-10. Т.е., как я понял, дело именно в том, что оперативной памяти не хватает на то чтобы забуферизовать все. Отсюда и мое предположение, что если ее будет больше, то, возможно, SQL SERVER не будет выгружать из нее страницы предыдущих выборок, и не будет так много операций Buffer I/O. Но не факт...

← →
Ринсвинд © (2015-08-06 12:53) [4]

Оказалось, что на сервере была 32-разрядная MS SQL SERVER, и использовалось не 32 ГБ ОЗУ, а 3.5ГБ... Удивительно не то, что появилась нехватка ресурса Buffer I/O, а то что ее не возникло раньше.

← →
Rouse_ © (2015-08-06 12:59) [5]

Я может и не в тему, но на сколько я помню MS SQL использует AWE для доступа к памяти свыше 4 гигабайтного лимита (т.е. по факту должны использоваться все 32 гигабайта).

> Rouse_ © (06.08.15 12:59) [5]

Насколько я понял, в SQL SERVER 2012 уже нет AWE (https://support.microsoft.com/en-us/kb/2644592)

О как оно, Михалыч, ну тогда да :)

Запросы не поделили Buffer I/O Найти похожие ветки