У меня странная проблема в производственной среде клиента. Я не могу дать никаких подробностей об инфраструктуре, за исключением того, что SQL-сервер работает на виртуальном сервере. Файл данных, журнала и файлового потока находится на другом сервере хранения (данные и файловый поток вместе и журнал на отдельном сервере).
В нашей локальной тестовой среде есть один конкретный запрос, который выполняется с такой продолжительностью:
- сначала мы очищаем кеш
- 300 мс (в первый раз требуется больше времени, но с этого момента он кешируется.)
- 20 мс
- 15 мс
- 17 мс
В производственной среде заказчика SQL Server более мощный, это длительности (у меня не было прав на очистку кеша. Попробую завтра).
- 2500 мс
- 2600 мс
- 2400 мс
Серверы в производственной среде заказчика более мощные, но у них есть виртуальные серверы (у нас их нет).
Что может быть причиной...
Как бы вы решили эту проблему с производительностью?
РЕДАКТИРОВАТЬ:
Некоторые люди спрашивали меня, равен ли набор данных, и это так. Я восстановил их базу данных в нашей среде. Это правда, что это было первое, на что я посмотрел. (@Everyone: я добавил правку, потому что это будет первое, о чем многие подумают).
Причиной может быть нехватка памяти, фрагментация, физическая память, а также различные настройки степени параллелизма, конкуренции, разные размеры таблиц, разная статистика, разные уровни исправлений SQL и так далее и тому подобное.
Так что вопрос не в том какие неправильно, а скорее как определить что случилось. Моя обычная рекомендация, которая, по моему опыту, не совсем так. этот или который, заключается в использовании Методология ожидания и очередей. Это справедливый методический подход, который в конечном итоге определит виновника, и вы получите решение.
Это может быть нехватка памяти, ЦП, сети или диска, но больше ли набор данных клиента?
Первым шагом будет получение плана выполнения самого запроса, чтобы убедиться, что он не сканирует строки. Вам действительно следует сначала оптимизировать запрос, поскольку вы уже сказали, что их сервер базы данных мощный. Анализатор запросов SQL Server - лучший инструмент для этого.
Вполне возможно, что даже с теми же данными, что и ваша система, они могут генерировать другой план запроса, если их статистика устарела. Я бы побежал EXEC sp_updatestats и посмотрите, имеет ли это значение.
Раньше у нас был сервер, который это делал. По-видимому, кто-то установил файлы базы данных на массиве RAID 3 ... не очень хорошая идея!
Конечно, это может быть что угодно, но обязательно проверьте конфигурацию диска.
Это могло быть что угодно. Это также может быть медленная сеть (или проблема в сети), поскольку похоже, что вы используете какие-то SAN (ы).
Одинаков ли масштаб данных в среде заказчика и в среде тестирования? Это ошибка многих разработчиков, тестирующих производительность на наборе данных, который не моделирует масштаб данных в производственной среде.
Если у вас есть доступ к Profiler и PerfMon, вы, вероятно, сможете довольно быстро решить проблему.
Рекомендуемый способ отладки - изучить SQL Server. счетчики производительности (Пуск / Выполнить / perfmon.exe). Понадобится немного времени, чтобы узнать, какие из них актуальны в вашем случае, но это определенно того стоит и поможет точно определить тип проблемы.
Вот несколько быстрых ссылок, которые мне нравятся, Google знает намного больше:
Производственный сервер такой же, как и ваша тестовая установка?
Вы упомянули, что журналы данных и файловая система находятся на сервере хранения, с чем это связано? Оптоволоконный канал, 10/100/1 ГБ? scsi? Все, кроме Fibre Channel, будет медленным !!!
Выделен ли сервер хранения для сервера db? Вы боретесь за ресурсы?
В зависимости от используемой технологии виртуализации виртуальный сервер действительно может работать значительно хуже, особенно в отношении дискового ввода-вывода. На виртуальной машине доступ к диску может осуществляться на уровне эмуляции или драйвера, который преобразует команды на виртуальном диске в команды на физическом диске. Эта эмуляция часто приводит к значительной дополнительной задержке и может не использовать надлежащие преимущества базового дискового массива.