Що стосується частоти розливу хеш / сортування в tempdb?

Наша корпоративна програма використовує SQL Server для зберігання даних і в першу чергу є системою OLTP. Однак важливим компонентом нашої програми є значне навантаження OLAP.

Наша затримка запису до tempdb становить близько 100 мс. Ця тенденція має місце в протягом довгого часу, і ALLOW_SNAPSHOT_ISOLATIONповернута від . Ми вирішуємо цю проблему щодо проблеми, і єдине, що ми виявили до цього часу, - це те, що tempdb має значну кількість хешу та сортування. Ми вважаємо, що це відбувається від нашого навантаження OLAP.

Питання

Яка частота розливів стосується? Будь-який? Скільки розливів / сек? Наші попередні дані свідчать про те, що у нас є близько 2 розливів хешу в секунду і 25 сортування розливів в хвилину.

Чи можливо, що ця частота розливів може бути першочерговим винуватцем нашої високої затримки написання tempdb?

Інша інформація

Ми використовуємо кілька файлів для tempdb, як рекомендується, на кількість ядер. Файли tempdb знаходяться на RAID 1 + 0 SAN (з високопродуктивними SSD), але це той самий пристрій, що і основні файли даних БД та журнали. Файли tempdb розміром досить великі, що вони ростуть дуже рідко. Ми не використовуємо прапорці слідів 1117 або 1118. Іншою змінною є те, що ця настройка поділяється на декілька різних баз даних, які мають усе середнє та велике навантаження.

Наші затримки запису в 100 мс набагато перевищують допустимі діапазони затримки запису tempdb, які ми знайшли на MSDN, SQL Skills та інших сайтах. Однак затримка запису для інших наших баз даних хороша (нижче 10 мс). На основі інших статистичних даних, схоже, ми використовуємо tempdb активно, особливо для внутрішніх об'єктів. Тож ми копаємося, щоб спробувати з’ясувати, чому наша програма так активно використовує внутрішні об’єкти.

На нашій платформі у нас є реальні проблеми, що проявляються різними способами. Ми проводили моніторинг лічильників парфумів, переглядали погляди DM та аналізували поведінку програми, щоб спробувати заглибитись у характеристики використання ресурсів нашої системи. Зараз ми зосереджені на розливі, оскільки ми читали, що розливи мають різкий негативний вплив, оскільки вони виконуються на диску, а не в пам'яті. І у нас, мабуть, дуже велика кількість розливів, але я хотів отримати деякий внесок у те, що люди вважають "високим".

Чи можливо, що ця частота розливів може бути першочерговим винуватцем нашої високої затримки написання tempdb?

Так, можливо , хоча це, як правило, значення середнього розміру розливів і те, наскільки вони глибокі (тобто рекурсивні розливання хешу, багатопрохідні сорти) має значення більше, ніж частота сама по собі.

SQL Server надає широкий спектр метрик та інформації DMV, щоб допомогти вирішити різні фактори, що сприяють тиску tempdb, багато з яких обговорюються в технічній статті Microsoft "Робота з tempdb в SQL Server 2005" (стосується всіх версій 2005 року і далі ).

Ви повинні мати можливість використовувати вказівки щодо діагностики, що містяться в цьому документі, щоб почати ідентифікувати основні причини будь-якого тиску tempdb. Не ігноруйте, наприклад, діяльність магазину версій просто тому ALLOW_SNAPSHOT_ISOLATION, що не ввімкнено. У багатьох функціях використовується сховище версій (наприклад, тригери, MARS, RCSI) окрім ізоляції знімків.

Якщо сортування та розсипання хесів виявляться значними на високому рівні, вам, ймовірно, потрібно буде встановити для цього певний моніторинг. Залежно від вашої версії SQL Server, це не завжди просто, як можна сподіватися. Для з'єднання сортування та хеш-розливу з конкретним запитом, який їх викликав, потрібні сповіщення про події або розширені події. Стаття SolidQ, " Визначення та вирішення попереджень про сортування ", містить детальну інформацію та кілька хороших загальних порад щодо вирішення поширених причин.

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