У нас є один екземпляр SQL Server 2016 SP1, що працює у віртуальній машині VMware. Він містить 4 бази даних, кожна для різних програм. Ці програми є на окремих віртуальних серверах. Жоден з них ще не використовується у виробництві. Люди, які тестують програми, повідомляють про проблеми з ефективністю.
Це статистика сервера:
- 128 ГБ оперативної пам’яті (максимальна пам'ять 110 ГБ для SQL Server)
- 4 ядра при 4,6 ГГц
- Підключення до мережі 10 ГБ
- Усі сховища засновані на SSD
- Програмні файли, файли журналів, файли бази даних та tempdb знаходяться на окремих розділах сервера
- асд
Користувачі здійснюють доступ до одного екрана через ERP-додаток на основі C ++.
Коли я підкреслюю тест SQL Server із Microsoft, ostressвикористовуючи чималі невеликі запити, чи великі запити, я отримую максимальну продуктивність. Єдина річ, яка замовчує - це клієнт, тому що він не може відповісти досить швидко.
Але коли користувачів майже немає, сервер SQL ледь нічого не робить. Однак людям доведеться вічно чекати, щоб зберегти що-небудь у програмі.
Відповідно до запиту Пола Рандала " Скажи мені, де це болить ", 50% усіх подій на очікування є ASYNC_NETWORK_IO.
Це може означати або проблему з мережею, або проблему продуктивності з сервером додатків або клієнтом. Жоден із них навіть не віддалено використовує свої ресурси на максимальній потужності. Більшу частину часу процесор становить близько 26% на всіх машинах (клієнт, додаток, сервер db).
Затримка підключення до мережі становить близько 1-3 мс. IO сервера db досягає максимальної швидкості запису 20 Мб / с під час звичайного використання програми (середня сума становить 7-9 МБ / с). Коли я здаю стрес-тест, я отримую максимум 5 Гб / с.
Розмір кеш-пам'яті становить 60 Гб для БД нашої системи ERP, 20 ГБ для нашого програмного забезпечення для фінансування, 1 ГБ для забезпечення якості програмного забезпечення, 3 ГБ для системи архівування документів.
Я дав обліковому запису SQL Server право використовувати миттєву ініціалізацію файлів . Це нітрохи не підвищило продуктивність.
Тривалість життя сторінки становить приблизно 15 тис. + При нормальному використанні. Під час закінчення важких стресових випробувань впаде приблизно до .05k, чого можна очікувати. Пакети / сек - це приблизно 2-8 к, залежно від завантаженості.
Я б сказав, що додаток ERP написано погано, але я не можу, оскільки це впливає на всі програми. Навіть при мінімальному навантаженні.
Але я не можу точно визначити, що це викликає. Чи є якісь поради, підказки, підручники, додатки, документи найкращого / найгіршого досвіду чи щось інше, що ви маєте на увазі щодо цієї проблеми?
Це результати sp_BlitzFirst:
Я пробіг його 600 секунд. Я запустив це під час великої завантаженості програми. 1/3 часу це ASYNC_NETWORK_IO. Я також перевірив мережеве з'єднання з NTttcp, PsPing, ipferf3і pathping. Нічого незвичайного. Час реакції становить максимум 3 мс, середній 0,3 мс. Пропускна здатність становить близько 1000 МБ / с.
Моє розслідування завжди призводить до ASYNC_NETWORK_IOтого, що я є номером очікування номер один.
Ми дослідили результат відключення Large-Receive-Offloadфункції у VMware. Ми все ще проводимо тестування, але результати здаються непослідовними. Перший наш «орієнтир» призвів до тривалості 19 хвилин (найкращий результат - 13 хвилин, що досягається лише тоді, коли додаток працює у ВМ із самим SQL сервером). Другий результат - 28 хвилин, що справді погано.
Перший результат нашого «орієнтиру» склав 19 хвилин. Що добре. Тому що головний результат становив 13 хвилин (що досягається лише тоді, коли орієнтири додатків у ВМ із самим SQL сервером). Це рівно натякає на певну мережеву проблему. Або проблема з конфігурацією VMware.
Наразі я втрачаю, які методи використовувати, щоб прибити це до вузького місця.
Максимальна продуктивність із програмою досягається лише тоді, коли додаток працює у VM із самим SQL сервером. Якщо додаток виконано на будь-якому іншому віртуальному комп'ютері або віртуальному робочому столі, тривалість нашого бенчмарку збільшується втричі (від 13 хвилин до 40 хвилин і більше). Усі кінцеві точки (VM сервера SQL, VM сервера додатків та віртуальний робочий стіл) використовують одне і те ж фізичне обладнання. Ми перемістили всі інші кінцеві точки до іншого обладнання.
EDIT: Схоже, проблема повернулася. Після встановлення режиму економії енергії від збалансованого до високої продуктивності ми фактично покращили час реагування. Але сьогодні я знову запустив sp_BlitzFirst із зразком 300 секунд. Це результат:
Він показує більше секунди часу очікування для ASYNC_NETWORK_IO, ніж секунди, що пробігла sp_blitzfirst.