SQL Script в ВМ занимает много времени для выполнения

Question

У меня есть пакет Execute SQL Script, который содержит сценарий для вставки около 150 тыс. Записей.

Проблема здесь в том, что когда я выполняю пакет на виртуальной машине, он занимает примерно 25 минут и тот же пакет в физическоймашина занимает 2 минуты

Вопрос 1?Почему это занимает столько времени, чтобы загрузить те же данные в ВМ.Вопрос 2?Как решить эту проблему производительности.

Конфигурация физической машины имеет 4 ГБ оперативной памяти и 250 ГБ HD + Windows server 2008 R2 + SQL server 2008 R2 Standard Edition.Виртуальная машина имеет ту же конфигурацию

Обновление: проблема с SQL Server в виртуальной машине.

Вопрос 1?Почему для запуска одного и того же сценария в ВМ требуется столько времени.

Вопрос 2?Как решить эту проблему с производительностью.

Обе схемы баз данных на физическом компьютере и виртуальной машине идентичны.Другие базы данных также одинаковы.Для этих таблиц индексация не применялась на обеих машинах.Типы данных одинаковы.Жесткий диск, как я уже сказал, имеет одинаковую конфигурацию.

На обеих машинах не выполняется RAID.

Физическая машина имеет Quad Core 2,67 ГГц, а в виртуальной машине - 2,00Оперативная память ГГц Quad Core

Версия SQL PM:

Microsoft SQL Server 2008 R2 (окончательная первоначальная версия) - 10.50.1600.1 (X64) 2 апреля 2010 г. 15:48:46 Copyright (c)) Microsoft Corporation Standard Edition (64-разрядная версия) в Windows NT 6.1 (сборка 7601: пакет обновления 1)

Версия SQL PM:

Microsoft SQL Server 2008 R2 (окончательная первоначальная версия) - 10.50.1600.1 (X64) 2 апреля 2010 15:48:46 Copyright (c) Microsoft Corporation Standard Edition (64-разрядная версия) в Windows NT 6.1 (сборка 7601: пакет обновления 1) (гипервизор)

Я выполнил сценарийПлан выполнения для обоих одинаков, так как нет разницы в плане.

Поставщик - машина HP ML350.

На одном физическом сервере почти 20 виртуальных машин, из которых 7 активных серверов.

Answer 1

Здесь есть статья о правильной настройке конфигурации SQL для реализации виртуальной машины: Рекомендации для SQL Server .Ниже приведен отрывок, хотя в статье содержатся другие советы и хороший план тестирования производительности:

Проблемы с конфигурацией хранилища являются основной причиной проблем производительности SQL.Обычно эти проблемы возникают из-за того, что администратор БД запрашивает виртуальный диск администратора VI, а администратор VI размещает VMDK на LUN, который может соответствовать или не соответствовать требованиям производительности администратора.Например:

1. Файлы VMDK виртуальных машин помещаются на тома VMFS без достаточного количества шпинделей.
2. Многие файлы VMDK размещаются на одном томе VMFS, который может использовать больше шпинделей.
3. База данных и файлы журналов, размещенные на одном и том же LUN, который, как вы уже догадались, может использовать больше шпинделей.

Это может быть очевидным для некоторых, но эта проблема возникает снова и снова.Администратор ВП должен знать о нескольких технических элементах, которые могут помочь понять и избежать этой проблемы:

1. Исходя из требований ввода-вывода для файлов БД, в этом файле должно быть гарантировано определенное количество шпинделей.,Это означает, что его VMDK должен быть размещен на томе VMFS для учета требований SQL Server и всех других требований к этому тому.
2. Смешивание последовательных действий (таких как обновление файла журнала) и случайных действий (таких каккак доступ к базе данных) приводит к случайному поведению.Это означает, что конфигурация LUN в пред-виртуальной физической среде может быть недостаточной для консолидированной среды.Это обсуждается в разделе «Производительность хранилища: VMFS и протоколы».
3. Если хранилище не соответствует требованиям SQL Server, задержка устройства или задержка ядра (время ожидания) увеличатся.Читайте об этих счетчиках в разделе Анализ и мониторинг производительности хранилища.

Answer 2

У меня похожая проблема.

Две клиентские машины (одна физическая, одна виртуальная) выполняют пакет с помощью SQLCMD. Этот пакет вызывает хранимую процедуру на физическом сервере (поэтому это не проблема с памятью, поскольку разработка ведется только на стороне сервера).

Пакет, выполненный с физической машины, занимает 20 минут. Пакет, выполняемый с виртуальной машины, занимает 1 час 20 минут.

Используя профилировщик SQL, я заметил, что в случае медленного выполнения существует тип ожидания ASYNC_NETWORK_IO.

Вероятно, уровень виртуализированной сети не оптимизирован.

Не могли бы вы запустить профилировщик SQL и проверить, видите ли вы тип ожидания ASYNC_NETWORK_IO?

Answer 3

Наиболее распространенной причиной этой проблемы является отсутствие оперативной памяти.Ваша задача настроить все на маленькой машине с 4 ГБ ОЗУ.

Когда вы пытаетесь загрузить эти 150k строк в память (помните, все, что происходит в SSIS, находится в памяти), многие из этих строк обрабатываютсяпо вашему файлу подкачки.

Pagefile на вашей виртуальной машине намного медленнее, чем на вашей физической машине.

Чтобы решить эту проблему, увеличьте объем оперативной памяти на вашей виртуальной машине.