Здесь много чего происходит, и большая часть его довольно широкая и расплывчатая.
2008R2 RTM вышел 21 апреля 2010 года. Он полностью вне поддержки. Вы захотите установить приоритет для последнего пакета обновления, который появился всего 3 года назад. Таким образом, вы будете защищены, если столкнетесь со странной ошибкой или чем-то еще. Идите сюда, чтобы выяснить, что вам нужно скачать.
Поскольку вы добавили vCPU (от 1 до 4) и не изменили никаких настроек, ваши запросы теперь могут идти параллельно. Я знаю, это звучит так, как будто они все будут быстрее, но держись!
Возможно, вы добавили ОЗУ, но, возможно, вы не изменили Макс. Объем памяти сервера, чтобы ваш сервер мог этим воспользоваться.
Выясните, что ожидает ваш сервер. Проект с открытым исходным кодом, над которым я работаю, предоставляет бесплатные сценарии, которые помогут вам измерить ваш SQL Server. Отправляйся сюда, если хочешь попробовать.
Вы хотите получить sp_BlitzFirst, чтобы проверить статистику ожидания вашего сервера. Вы можете запустить его несколькими способами.
Это покажет вам, что ваш сервер ждал с момента запуска.
EXEC dbo.sp_BlitzFirst @SinceStartup = 1;
Это покажет вам, какие запросы ожидают сейчас, в течение 30-секундного окна.
EXEC dbo.sp_BlitzFirst @Seconds = 30, @ExpertMode = 1;
После того, как вы выясните, какие запросы ждут (там написано множество вещей о статистике ожидания), вы можете начать вносить изменения, чтобы все контролировалось.
Если вы видите, что они ждут CXPACKET
, это означает, что ваши запросы идут параллельно и, возможно, растоптаны друг над другом. Если вы нажмете это, вы, вероятно, захотите увеличить порог стоимости для параллелизма до 50 и, возможно, понизить MAXDOP до 2.
После этого шага вы захотите использовать что-то вроде sp_WhoIsActive или sp_BlitzWho (последний находится в репозитории GitHub ранее), чтобы начать захват планов запросов. Помимо статистики ожидания, это одна из самых важных вещей, на которые вы можете посмотреть, чтобы выяснить, что происходит не так.
Возможно, вы также захотите проверить эту статью Джонатана Кехайаса о счетчиках VMWare, чтобы ознакомиться с SQL Server.
Обновить
Просмотр статистики ожидания и мальчик, они странные. Там определенно что-то не так с процессорами. Ваш сервер в основном сидит скучно, но когда все нагревается, все становится плохо. Я постараюсь сломать это легко.
Ты бьешь ядовитого ожидания под названием THREADPOOL
. Вы не имеете тонны этого, но это имеет смысл, потому что ваш сервер не очень активен. Я объясню почему через минуту.
Вы действительно долго средние ожидания на SOS_SCHEDULER_YIELD
и CXPACKET
. Вы работаете на виртуальной машине, поэтому вам нужно убедиться, что у SQL Server есть резервирование или что ящик не переполнен. Шумный сосед может действительно испортить вам день здесь. Вы также захотите убедиться, что сервер / гостевая виртуальная машина / хост виртуальной машины не работают в режиме сбалансированной мощности. Это заставляет ваши процессоры вращаться до ненужных низких скоростей, и они не сразу возвращаются к полной скорости.
Как они связаны? С 4 процессорами у вас есть 512 рабочих потоков. Имейте в виду, у вас было одинаковое количество с одним процессором, но теперь, когда ваши запросы могут идти параллельно, они могут потреблять гораздо больше рабочих потоков. В вашем случае 4 потока на параллельную ветвь параллельного запроса.
Что происходит параллельно? Скорее всего все. Пороговое значение стоимости по умолчанию для параллелизма равно 5. Это число было установлено по умолчанию в конце 90-х, работая на рабочем столе, который выглядел следующим образом .
Конечно, ваше оборудование меньше, чем у большинства ноутбуков, но вы все еще немного впереди этого.
Когда запускается множество параллельных запросов, у вас заканчиваются эти рабочие потоки. Когда это происходит, запросы просто сидят и ждут начала потоков. Это также то, что SOS_SCHEDULER_YIELD
приходит. Запросы отключают процессоры и не возвращаются в течение длительного времени. Я не вижу каких-либо ожидающих блокировок, поэтому вы, скорее всего, просто забиты ожиданиями параллелизма внутри запросов.
Что ты можешь сделать?
- Убедитесь, что в режиме сбалансированной мощности ничего нет
- Измените MAXDOP на 2
- Изменить порог стоимости для параллелизма на 50
- Следуйте статье Jon K. выше, чтобы проверить работоспособность VM
- Используйте вызываемый скрипт
sp_BlitzIndex
для поиска любых отсутствующих запросов индекса.
Для более тщательного устранения неполадок ознакомьтесь с техническим документом, который я написал для Google, по настройке аппаратного обеспечения в облаке.
Надеюсь это поможет!