В настоящее время у нас есть очень слабая виртуальная машина, и мы предлагаем перейти на виртуальную машину Azure с лучшими характеристиками. Проблема заключается в том, что виртуальная машина Azure намного медленнее, чем исходная виртуальная машина, хотя и имеет более высокую спецификацию.
Исходный сервер представляет собой 2-ядерную виртуальную машину с 2 ГБ памяти, которая также является веб-сервером. Он работает под управлением Microsoft SQL Server Web Edition 2008 R2, и поскольку этот сервер используется для других целей, нам пришлось ограничить максимальный объем памяти сервера в SQL Server до 512 МБ .
Новый сервер представляет собой 4-ядерную виртуальную машину с 7 ГБ памяти, которая является только сервером базы данных. Он работает под управлением Microsoft SQL Server Standard Edition 2008 R2, и мы не ограничили объем памяти, который может использовать SQL Server.
Это один из двух серверов, настроенных в зеркальной среде, но база данных, на которой я запускаю тесты, не отражена. Другие базы данных на этом сервере в настоящее время не получают большого трафика (фактически, Activity Monitor не показывает активности на других БД, пока я выполнял эти тесты).
Я понимаю, что проблема с виртуальными машинами Azure заключается в том, что жесткие диски являются сетевым ресурсом, поэтому они могут стать источником замедления, но все равно медленнее, даже если в статистике ввода-вывода показано 0 физических чтений.
На этой странице я следовал советам по настройке виртуальной машины Azure, включая чередование дисков (по два диска на диск) и размещение файлов журнала и данных на отдельных дисках.
Единственное, что я не сделал, - включил сжатие страниц, ограничил автоматическое увеличение базы данных и переместил журнал ошибок сервера SQL и каталоги файлов трассировки на диски данных. Я не делал этого и на старом сервере.
На старом сервере эта настройка не выполнена, а файлы журнала и данных находятся на одном диске, который не является чередующимся.
База данных на текущем сервере составляет 65 ГБ (45 данных и 20 журналов), что было слишком много для переноса на новый сервер, поэтому я тестирую на меньшей БД (6 данных и 13,5 журналов)
Результаты на старом сервере CPU time = 1311 ms, elapsed time = 1057 ms.и на новом сервере - CPU time = 1281 ms, elapsed time = 2525 ms. это всего лишь один прогон, но результаты отражают то, что я обычно вижу.
Новый сервер, по-видимому, постоянно проводит время, значительно превышающее время процессора. Это проблема, и есть ли что-то, что я могу сделать, чтобы найти причину?
Какие еще шаги я могу предпринять, чтобы выяснить, почему этот сервер работает так медленно, когда кажется, что он должен быть быстрее, чем старый сервер?
источник
Ответы:
Что ж, я закончил, изменив виртуальную машину в Azure с типа A на тип D, а затем подключив другой диск и переместив TEMPDB на этот диск. Итак, моя последняя виртуальная машина теперь является стандартом D2 с 7 ГБ ОЗУ и тремя дисками с данными, один для файлов MDF, другой для файлов LDF и новый диск TEMPDB.
Я перестал пытаться понять с A3 некоторые вещи, которые вы упомянули, и просто обновить виртуальную машину. Я даже перешел с A2 на A3 и, хотя я нашел некоторые улучшения, я в итоге перешел на виртуальную машину D2.
В указанном вами документе Microsoft рекомендует D3 для Enterprise Edition или D2 для Web или Standard Edition, а также использование Premium Storage, помимо прочего, в контрольном списке в начале документа.
источник