Медленный удаленный оператор SELECT из-за длительного «времени обработки клиента», но быстрый локально

При подключении к нашему производственному серверу (SQL Server 2008, очень мощный компьютер) этот оператор SELECT занимает 2 секунды , выполняя все поля (всего 4 МБ данных).

SELECT TOP (30000) *
FROM person
WITH(NOLOCK);

Из любого другого блока в той же сети (подключение с использованием проверки подлинности SQL или проверки подлинности Windows) тот же запрос занимает 1 минуту 8 секунд .

Я тестирую это очень простое утверждение, чтобы проиллюстрировать, что это не проблема индексации или проблема, связанная с запросами. (У нас проблемы с производительностью по всем запросам на данный момент ...)

Ряды бывают кусками, а не все сразу. Я получаю свои первые ряды мгновенно, а затем жду более 1 минуты, пока не появятся партии рядов.

Вот клиентская статистика запроса, когда он запускается из удаленного окна:

Query Profile Statistics
  Number of INSERT, DELETE and UPDATE statements 0
  Rows affected by INSERT, DELETE, or UPDATE statements 0
  Number of SELECT statements  2
  Rows returned by SELECT statements 30001
  Number of transactions 0

Network Statistics
  Number of server roundtrips 3
  TDS packets sent from client        3
  TDS packets received from server 1216
  Bytes sent from client         266
  Bytes received from server 4019800

Time Statistics
  Client processing time 72441 ms (72 seconds)
  Total execution time   72441 ms
  Wait time on server replies 0

Мы видим, что «Время обработки клиента» равно общему времени выполнения.

Кто-нибудь знает, какие шаги я могу предпринять, чтобы диагностировать, почему передача фактических данных занимает много времени?

Существует ли параметр конфигурации SQL, который ограничивает или ограничивает скорость передачи данных между компьютерами?

Ваша проблема определенно связана с сетью, основываясь на вашей информации. Как таковой, он должен иметь дело с сетевыми профессионалами (я не один).

Вещи, которые могут помочь:

• Быстрее NIC карты (на сервере SQL).
• Добавление выделенной / определенной сетевой карты / подсети между серверами (веб-сервер и SQL Server).

Находится ли веб-сервер в той же подсети, что и SQL-сервер?

Есть ли между ними маршрутизаторы / мосты?

Не много возможных изменений на сервере SQL:

• Выходные данные отправляются SQL Server с проприетарной MS "TDS protocol".
• Размер буфера TDS по умолчанию составляет 4 КБ. Смотрите в MSDB: «Опция размера сетевого пакета»
• Сжатие данных (с помощью SQL Server или внешнего приложения) - зависит от характера данных.

Вы используете размер по умолчанию: смотрите статистику: «Пакеты TDS, полученные с сервера 1216» (4MB / 1K = 4KB). Да, размер буфера TDS можно изменить: см. В Google: «Размер пакета протокола TDS»

Хорошая дискуссия на тему: "действительно ли размер сетевого пакета sql определяет двусторонний трафик?"

Однако изменение размера пакета TDS неизбежно приведет к непредсказуемым последствиям и должно использоваться только в исключительных случаях.

Также может помочь изменение архитектуры или введение кеширования данных на промежуточном уровне.

Эта проблема теперь решена.

Это была проблема с сетью, и в блоке SQL использовалась карта NIC 100 МБ / с вместо карты NIC 10 ГБ / с ...

Изменение конфигурации сети для использования правильной сетевой карты устранило проблему. Теперь мы получаем аналогичную производительность для всех запросов из блока «Рабочий SQL» и из других блоков в сети.

Спасибо всем за вашу помощь.

При первоначальном чтении звучит так, как будто вы испытываете некоторые задержки в сети. Вы смотрели на некоторые счетчики Network Perfmon? Они могут дать вам некоторое представление о том, что происходит с сетью.

Цитата Какие счетчики Perfmon я должен контролировать и что каждый из них означает?

СЕТЬ IO

Для измерения сетевого ввода-вывода вы можете использовать следующие счетчики:

Сетевой интерфейсБайт Всего / сек

Порог: устойчивые значения более 80 процентов пропускной способности сети.

Значение: этот счетчик показывает скорость, с которой байты отправляются и принимаются через каждый сетевой адаптер. Этот счетчик помогает узнать, насыщен ли трафик на вашем сетевом адаптере и нужно ли добавить другой сетевой адаптер. Как быстро вы сможете определить проблему, зависит от типа вашей сети, а также от того, используете ли вы пропускную способность для других приложений.

Сетевой интерфейсБайт получено / сек

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

Сетевой интерфейсБайт отправлено / сек

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

Всего байт сервера / сек

Это значение не должно превышать 50 процентов емкости сети.

Этот счетчик указывает количество байтов, отправленных и полученных по сети. Более высокие значения указывают пропускную способность сети как узкое место. Если сумма байт / сек для всех серверов примерно равна максимальной скорости передачи в вашей сети, вам может потребоваться сегментировать сеть.

% Прерывания процессора

Этот счетчик показывает процент времени, которое процессор тратит на получение и обслуживание аппаратных прерываний. Это значение является косвенным индикатором активности устройств, генерирующих прерывания, таких как сетевые адаптеры.

Сетевой интерфейс (*) Длина очереди вывода

Этот счетчик проверяет, сколько потоков ожидает на сетевом адаптере. Если на сетевом адаптере ожидает множество потоков, то система, скорее всего, насыщает сетевой ввод-вывод, скорее всего, из-за задержки в сети или пропускной способности сети.

Длина очереди вывода - это длина очереди выходного пакета (в пакетах). Если это дольше, чем два, есть задержки, и узкое место должно быть найдено и устранено, если это возможно. Поскольку в этой реализации запросы помещаются в очередь спецификацией интерфейса сетевого драйвера (NDIS), это всегда будет 0.

Некоторые предварительные вопросы: 1) На сервере есть клиент SQL на Prod. сервер настроен, верно? Так что, если вы сделаете тот же запрос от клиента, расположенного на той же машине, он будет выполнен через 2 секунды? Вы пытались это сделать? Это действительно 2 секунды? 2) Вы упомянули, что конфигурация вашей производственной среды была изменена (или рабочий сервер перенесен на другую сеть / полное восстановление сервера выполнено), верно? Сколько времени занимал запрос в старой производственной среде?

Из любого другого окна в той же сети ... тот же запрос занимает 1 минуту 8 секунд. 3) Вы говорите, что запрос возвращается и поступает от клиента, расположенного на любом компьютере в данной сети (кроме вашего конкретного компьютера), примерно за 70 секунд? Я правильно поняла? 3.1 Кстати, какие сроки для этого запроса приемлемы для бизнеса? 4) Однако вы указываете, что для определенного клиентского компьютера, который вы используете, время потребления вывода запроса: Время выполнения клиента 15:30: 48 15 минут? (а это время явно не приемлемо)? Верный? 5) так проблема ограничена одним клиентским компьютером? Или ЛЮБОМУ клиенту / машине среднего уровня и т.д. (в новой среде)? 6) Какую задержку показывает пинг? с клиентского компьютера на сервер? 7) Вы (или сетевой администратор) запускали tracert в обе стороны (от клиента к серверу, от сервера к клиенту)? Сколько хмеля? Что такое общее время? 8) жива ли старая производственная сеть? Можете ли вы сравнить использование Ping и Traceroute - сколько времени прошло между клиентом и сервером?

Из любопытства: это пример запроса? или точная формулировка запроса? Запрос действительно НЕ содержит предложения WHERE? Согласитесь со мной, что это очень необычно .. Таблица имеет кластерный индекс или это куча? Таблица содержит сколько строк всего? Стол сильно фрагментирован? Из любопытства: почему ВЫБРАТЬ ТОП NNN? Почему бы не установить ROWCOUNT NNN - тогда ВЫБРАТЬ *? Этот запрос выдается клиентом сколько раз в день? 1? 100? 1млн? Базовые данные статичны или динамичны и сильно изменены? Сколько (0,01 процента в день? 1 процент в день? 10 процентов в день?) Вывод запроса обрабатывается программно? (не пользователем?) Почему он не кэшируется / не сохраняется на промежуточном уровне? спасибо Алексей