Старый SQL Express 2005 работал на сервере Dell с одним процессором Xeon начального уровня, дисками RAID 5 7200, 2 ГБ ОЗУ (SBS 2003).
Я не проводил никаких базовых измерений на старом физическом сервере, но веб-приложением пользуются полдюжины человек (возможно, двое одновременно), поэтому я подумал, «насколько плохим может быть экземпляр Amazon EC2?».
Это довольно ужасно: разница в времени загрузки на одном экране составляет 8 секунд.
Во-первых, я не гуру SQL, но вот что я пробовал:
Имел небольшой экземпляр, теперь работающий с экземпляром c1.medium (High Cpu Medium) Windows 2008 32-разрядной версии R2 с поддержкой EBS, работающим под управлением IIS 7.5 и SQL Express 2008 R2. Никаких заметных улучшений.
Файл подкачки изменен с фиксированных 256 на автоматический.
Настройте чередующееся зеркало из управления дисками с двумя подключенными томами EBS объемом 1 ГБ. Перенесли базу данных и журнал транзакций, все остальное оставили на загрузочном томе EBS. Без заметных изменений.
Посмотрел память, свободно ~ 1000 МБ физической памяти (всего 1,7 ГБ). Экземпляр SQL изменен на использование как минимум 1024 ОЗУ; перезапущенный сервер, без изменений в использовании памяти. SQL по-прежнему использует только ~ 28 МБ ОЗУ (!).
Итак, я думаю: эта база данных крошечная (28 МБ), почему все это не кешируется в ОЗУ? Конечно, это повысит производительность. Журнал транзакций составляет 241 МБ. По сравнению с этим кажется большим - разве это не было совершено? Это причина снижения производительности? Я кое-что вспомнил о моделях восстановления и размерах журналов где-то в своих путешествиях, но не положительный.
Еще один момент: на старом сервере работал SQL Express 2005. Не уверен, что это повлияет на это, но я попытался изменить уровень совместимости с SQL 2000 на 2008, но это не дало результата.
В любом случае, что еще я могу здесь попробовать? Кажется смешным бросать на это больше виртуального оборудования. Я знаю, что ввод-вывод для томов EBS будет грубым, но наверняка другие успешно запускают небольшие приложения .NET / SQL на экземплярах по разумной цене?
Ответ в том, что EBS слишком медленный для SQL Server.
Я провел обширное тестирование. Для SQL EBS очень плохо читает. Для записи SQL он настолько медленный, что его никогда (никогда) не следует использовать.
Появились новые тома EBS с выделенным IOPS. Это единственный путь.
Настройте два тома EBS: один для ldf, один для mdf.
Настраивайте IOPS, пока не добьетесь хорошей производительности.
Поместите tempdb в хранилище локальных экземпляров.
Всякий раз, когда я обновляю базы данных, а я делаю это в течение как минимум двенадцати лет, первое, что я делаю после восстановления базы данных, - это переиндексация всех таблиц. Я делаю это прежде, чем позволю кому-либо использовать базу данных. Переиндексировать очень просто: потребуется всего пара секунд, чтобы переиндексировать 28 МБ данных на чем-либо более быстром, чем ноутбук 2005 года выпуска.
Убедитесь, что для базы данных установлено значение AUTOCLOSE = FALSE. В некоторых средах по умолчанию установлено значение ИСТИНА, что неверно для любого производственного сервера.
Как говорит cmenke, если вы не используете стратегию восстановления на определенный момент времени, вам следует установить для своей базы данных режим ПРОСТОГО восстановления. Была ли база данных настроена на ПРОСТОЙ режим восстановления на сервере SBS?
Имеет ли база данных на EC2 такая же индексация, как и старая база данных? Вы не упомянули, как вы перемещали свои данные, поэтому мы не знаем, выполняли ли вы резервное копирование и восстановление, использовали ли мастер копирования базы данных или написали свои собственные пакеты SSIS. Некоторые методы перемещения баз данных не сохранят ваши индексы. Для будущих читателей этого ответа, которые пытаются перемещать базы данных между серверами, вы всегда должны пытаться использовать BACKUP / RESTORE или копировать файлы MDF и LDF. Использование SSIS / DTS для всех баз данных, кроме самых простых, сведет вас с ума.
Если база данных по-прежнему работает медленно, запустите SQL Profiler (на сервере, а не на рабочем столе) и захватите небольшой трафик. В чем проблема: в одном большом медленном операторе SQL или в большом количестве маленьких операторов SQL? Сколько операторов SQL выдает на этой первой странице?
Имейте в виду, что вы уже внесли ряд изменений в свой SQL Server и не заметили никаких изменений в поведении. Может проблема в другом. Ваша веб-страница неожиданным образом взаимодействует с настройкой AD? Что-то не работает на веб-странице, не показывая вам никаких ошибок? Ищет ли веб-страница что-то в старой настройке SBS, что не было перенесено на EC2? Если у вас есть код и некоторые варианты разработки, я бы просмотрел этот код.
Похоже, что большая часть вашей БД на самом деле кешируется в ОЗУ. Вы можете использовать счетчик степени попадания в кэш буфера SQLServer: BufferManager в perfmon, чтобы увидеть, какой процент ваших запросов попадает в кеш, а не на диск. Чем выше, тем лучше.
Я также предлагаю проверить использование вашего диска и процессора, ваша медлительность может вообще не быть связана с оперативной памятью.
Интересен огромный журнал транзакций по сравнению с размером базы данных. Я не уверен, действительно ли это проблема, но вы можете попытаться избавиться от нее, выполнив следующие действия: убедитесь, что модель восстановления для базы данных установлена на «простую» (не «полную»!), Затем выполните резервное копирование. базу данных в файл. Это должно вызвать контрольную точку и позволить SQL Server усечь журнал.