Повільний віддалений оператор 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-сервері).
• Додавання виділеної / конкретної NIC-карти / підмережі між серверами (веб-сервер і SQL Server).

Чи веб-сервер у тій самій підмережі, що і SQL-сервер?

Чи є між ними маршрутизатори / мости тощо?

Небагато можливих змін на SQL сервері:

• Вихідні дані надсилаються через SQL Server із фірмовим MS "TDS-протокол".
• За замовчуванням розмір буфера TDS становить 4 Кб. Дивіться в MSDB: "Варіант розміру мережевого пакету"
• Стиснення даних (за допомогою SQL Server або зовнішньої програми) - залежить від характеру даних.

Ви використовуєте розмір за замовчуванням: див. Статистику: "TDS-пакети, отримані з сервера 1216" (4 МБ / 1 К = 4 КБ). Так, розмір буфера TDS можна змінити: див. У google: "Розмір партії протоколу TDS"

Гарне обговорення на тему: "чи дійсно розмір пакету мережі sql визначає трафік в обидва кінці?"

Однак зміна розміру пакету TDS (неминуче) матиме непередбачувані наслідки, і їх слід застосовувати у виробництві лише у виняткових випадках.

Зміна архітектури або введення кешування даних на середньому рівні також допоможе.

Зараз це питання вирішено.

Це була проблема з мережею, і в коробці SQL використовується NIC-карта 100 Мб / с , а не карта NIC 10 ГБ / с ...

Зміна конфігурації мережі для використання правильної мережевої картки усунула проблему. Зараз ми отримуємо аналогічну ефективність для всіх запитів із вікна Production SQL та інших вікон в мережі.

Дякуємо всім за допомогу.

При першому читанні це здається, що у вас виникають певні проблеми із затримкою у мережі. Ви подивилися деякі лічильники мережі Perfmon? Вони можуть дати вам певну інформацію про те, що відбувається з мережею.

Цитата з Яких лічильників Perfmon я повинен контролювати і що означає кожен з них?

МЕРЕЖА ІО

Для вимірювання мережевого вводу / виводу можна використовувати такі лічильники:

Мережевий інтерфейсBytes Всього / сек

Поріг: збережені значення понад 80 відсотків пропускної здатності мережі.

Значення: Цей лічильник вказує швидкість, з якою байти надсилаються та приймаються через кожен мережний адаптер. Цей лічильник допоможе вам дізнатися, чи насичений трафік вашого мережевого адаптера та чи потрібно додати інший мережевий адаптер. Наскільки швидко ви зможете визначити проблему, залежить від типу вашої мережі, а також від того, чи надаєте вам пропускну здатність іншим програмам.

Отримано мережевий інтерфейсBytes / сек

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

Мережевий інтерфейсBytes відправлено / сек

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

Всього ServerBytes / сек

Це значення не повинно бути більше 50 відсотків від ємності мережі.

Цей лічильник вказує кількість байтів, надісланих та отриманих по мережі. Більш високі значення вказують на пропускну здатність мережі як вузьке місце. Якщо сума байтів Всього / сек для всіх серверів приблизно дорівнює максимальній швидкості передачі вашої мережі, можливо, вам знадобиться сегментувати мережу.

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

Цей лічильник вказує відсоток часу, який процесор витрачає на отримання та обслуговування апаратних перерв. Це значення є непрямим показником активності пристроїв, які генерують перебої, наприклад мережевих адаптерів.

Мережевий інтерфейс (*) Довжина черги виводу

Цей лічильник перевіряє, скільки потоків чекає на мережевому адаптері. Якщо на мережевому адаптері чекає багато потоків, система, швидше за все, насичує мережевий введення / вивід, швидше за все, затримкою мережі або пропускною здатністю мережі.

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

Деякі попередні запитання: 1) Сервер має клієнт SQL у Prod. налаштована серверна машина, правда? Тож якщо ви зробите той самий запит у клієнта, що знаходиться на одній машині, він буде виконаний за 2 секунди? Ви намагалися це зробити? Це справді 2 секунди? 2) Ви згадали, що конфігурація вашого виробничого середовища була змінена (або виробничий сервер переміщений на іншу мережу / повне відновлення сервера зроблено), правда? Який час споживання запитів у старих виробничих умовах?

З будь-якого іншого поля в тій же мережі ... той самий запит займає 1 хвилину, 8 секунд. 3) Ви говорите, що запит повертається і споживається від клієнта, який знаходиться на будь-якій машині в даній мережі (очікуйте вашої конкретної машини) приблизно за 70 секунд? Я правильно зрозумів? 3.1 До речі, який час споживання цього запиту прийнятний для бізнесу? 4) Однак ви вказуєте, що для конкретної клієнтської машини, для якої ви використовуєте час споживання вихідного запиту, є: Час виконання клієнта 15:30: 48 15 хвилин? (а цей час явно не прийнятний)? Правильно? 5) тож проблема обмежується однією клієнтською машиною? Або на будь-яку машину клієнта / середнього рівня тощо (у нових умовах)? 6) яка затримка показана ping? від клієнтського комп'ютера до сервера? 7) Ви (або адміністратор мережі) запускали tracert обома способами (від клієнта до сервера, від сервера до клієнта)? Скільки хмелю? Який комбінований час? 8) Чи жива стара виробнича мережа? Чи можете ви порівняти, використовуючи Ping та Traceroute - який час та скачки між клієнтом та сервером там?

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