Назад | Перейти на главную страницу

Как я могу определить, почему доступ к БД кажется медленным с одним сервером БД, но не другим, использующим тот же сайт?

У нас есть установка с двумя веб-серверами и одним сервером БД как в Великобритании, так и в Австралии. Эти серверы подключены к Rackspace, и в обоих случаях веб-серверы подключаются к серверам db через частный IP-адрес. Один и тот же веб-сайт на соответствующих веб-серверах в каждом регионе, подключенный к их соответствующему региональному серверу БД, похоже, генерирует очень разную производительность.

Любое взаимодействие между соответствующим веб-сервером и сервером db кажется значительно медленнее на австралийском сервере, чем в Великобритании. Очевидно, это происходит путем запуска действия из браузера в соответствующих местах.

Сервер австралийской БД немного отличается, у него более быстрый процессор и больше памяти. Я работаю разработчиком .NET, поэтому не совсем уверен, как определить, в чем проблема. Как я могу определить, что здесь происходит, и попытаться понять, почему доступ к БД оказывается намного медленнее на австралийской стороне, чем на британской?

Есть еще одно отличие: австралийский сервер БД работает под управлением IIS для классической страницы asp, которая загружает / выгружает ресурсы со старого классического сайта asp. Похоже, что это не использует много памяти или мощности процессора и редко используется, поэтому я не понимаю, как это может быть проблемой. Что мне действительно нужно, так это способ увидеть, где происходит замедление / время в процессе с веб-сервера. Как лучше всего это сделать?

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

Вот первое, что я сделал бы в вашей ситуации:

  1. Загрузите и запустите Блиц диагностический скрипт от Brent Ozar. Обратите особое внимание на высокоприоритетные элементы, но не забудьте просмотреть весь отчет.
  2. Я бы дважды проверил, сколько оперативной памяти выделено для SQL на каждом сервере. По умолчанию SQL имеет неограниченное выделение оперативной памяти. Максимальный предел памяти должен быть на 4 ГБ меньше, чем общий объем ОЗУ в системе. И чем больше других вещей выполняется на этих серверах, тем больше должен быть разброс между максимальным объемом памяти SQL и установленным в системе объемом. Цель здесь - убедиться, что ОС не испытывает недостатка в оперативной памяти для поддержки задач, которые ставятся перед компьютером. ОС не может эффективно взаимодействовать между оборудованием и SQL, если ей не хватает оперативной памяти.
  3. Загрузите Пакет Microsoft SysInternals и запустите Process Explorer. Ищите узкие места в производительности с помощью мониторов ресурсов, особенно дискового ввода-вывода.
  4. Также из Sysinternals Suite используйте TCPView, чтобы проверить, сколько подключений к вашему серверу БД активно. Если число исчисляется сотнями, вам, вероятно, нужно будет обратить внимание на то, почему это так, и убедиться, что ничего не застревает.
  5. Наконец, после двойной проверки простых вещей, отключите профилировщик SQL и начните искать медленные запросы и другие проблемы. https://www.red-gate.com/simple-talk/sql/performance/how-to-identify-slow-running-queries-with-sql-profiler/