Чому io_stall_writes_ms настільки вище для tempdb?

У нас є файли даних користувачів та системних даних на одному дисководі. У файлах користувача (io_stall_write_ms / (1.0 + num_of_writes)) нижче 2, але файли tempdb зазвичай перевищують 400. Я бачу, що на декількох серверах мені цікаво, якщо є причина, що потрібно більше часу писати в tempdb ніж звичайний файл даних бази даних.

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

Дякую,

Короткий відповідь: Бачення більш високих кіосків вводу-виводу може бути проблемою само по собі. Потрібно ознайомитися з додатковою інформацією, щоб дізнатися, чи є у вас проблеми. Це здається трохи високим, так, але ви страждаєте? Якщо це так, це, мабуть, тому, що або ваша система вводу-виводу не справляється з завантаженням правильно (бо не може, тому що у вас все є на одному диску або з іншої причини), або ви занадто багато робите в TempDB (змінюючи першу проблему - продуктивність IO - це, мабуть, простіше та ефективніше виправити, але спочатку визначте, чи є у вас проблеми)

Більш тривала дискусія / відповідь:

Тут є два питання -

1.) Що робити, коли бачу високі кінці IO?

По-перше, "високий" є в очах глядача. Якби ви запитали 10 DBA, що таке "занадто високий" для IO кіосків, ви, ймовірно, отримаєте 2-3 різні відповіді з цифрами в них, 5-6 відповідей "Це залежить" і один простий погляд. Моє припущення, що в середньому 400 мс тут потенційно занадто велике, особливо коли інші БД становлять 2 мс або менше за середній час зупинки.

Незалежно від того, яка база даних бачить високі кіоски, ви повинні підходити до неї однаково. Інтервал IO - це те, що це звучить ... Запит IO займає більше часу, ніж очікувалося. Такі трапляються. Вони відбуваються постійно в системі, де ресурси поділяються і обмежуються ресурсами (насправді всі наші системи). Вони стають проблемою, коли кіоски стають проблемами з роботою або призводять до них. Тож я вірю, що ви розглядаєте тут як проактивну частину моніторингу або тому, що у вас виникли проблеми з ефективністю, які ви вирішуєте. Ми також не хочемо загубитися лише в кіосках з IO. Ми дивимося на фрагмент головоломки, а не на велику картину. Ви можете просто переглядати статистику очікування або статистику файлів, оскільки SQL востаннє перезапущений, тому що ви переглядаєте весь час, і якесь вікно технічного обслуговування або велике вікно завантаження може перекосити лічильники. Тому переконайтесь, що ви подивіться на повну картину.

Але коли я підозрюю, що у мене є проблема продуктивності диска або я бачу щось вимкнене в такому запиті, я зазвичай дотримуюся процесу, який виглядає так:

1. Подивіться статистику очікування на сервері. @swasheck поділився чудовим посиланням як коментар у відповіді нижче. Це призведе до публікації Пола Рандала про перегляд та аналіз статистики очікування на SQL Server. Іти туди. Яке очікування ви бачите? Річ у тім чекає , пов'язані з виконанням IO ( PAGEIOLATCH_*, IO_COMPLETION, WRITELOGі т.д.?). Якщо ви це зробите, це ще одна ознака того, що у вас є деякі проблеми, пов’язані з роботою вводу-виводу, так само, як і прилавки для IO. Але це дає вам іншу форму згоди тут.
2. Подивіться на IO продуктивність. Зокрема, загляньте всередину парфмонів на стійки Physical Disk:Avg Disk Sec/Readта Avg Sec Disk Sec/Writeприлавки. Вони вимірюють вашу затримку. Переглядайте ці лічильники протягом певного періоду часу, збереженого у файлі журналу продуктивності. Що ти бачив середні? Якщо ви бачите номери за 0,020 секунд (20 мс), це може бути проблемою. Якщо ви бачите цифри, що перевищують 40-50 мс або більше, це є більш твердим ознакою проблеми. Подивіться також на свої колоски? Як високо вони піднімаються і як довго вони тривають? Якщо ви бачите сплески в сотні мс, і вони тривають десятки або десятки секунд і більше і / або трапляються часто, ви, швидше за все, матимете проблеми з продуктивністю IO для вашого навантаження.
3. Подивіться на ваш IO налаштування. Що це? Локальні диски? SAN? Зберігання масиву? Який вигляд і ВПЗ ви повинні бачити з цього? Чи достатньо для того, що ви намагаєтесь зробити? Можливо, ви підкреслили свій IO під час навантаження. Не дивіться лише на свої фізичні шпинделі, налаштування RAID тощо. Подивіться на шляхи до своїх дисків. Ви все просуваєте через одне посилання на 1 Гб, яким ви ділитеся з багатьма іншими трафіком? Чи можете ви дивитись показники продуктивності диска з точки зору пам’яті.

( Примітка: для цього аналізу статистики очікування та аналізу за парфмон - подивіться на різні періоди та тип використання. Чи є у вас різні статистичні дані щодо використання в нічний час, ніж у вас вдень? Пакетна обробка вікон? Вікна технічного обслуговування, де ви збираєте багато індексів? Перегляньте ці інструменти протягом кожного з цих періодів і зрозумійте, що ви бачите для кожного)

Ще один розгляд результатів роботи IO -

• Ви сказали, що системні БД та БД користувачів є спільними. Це виробництво? Якщо так, то це не завжди найкращий сценарій. Ви також обмінюєтесь файлами журналів та файлами даних на одних дисках? Це теж не найкращий сценарій. Що ще ділиться цим сховищем? У світі, де ти турбуєшся про шпинделі та рейдові групи та диски і мусиш приймати рішення щодо того, хто отримує найкращі диски, які я працюю, я схильний (як правило, як правило, що не дуже добре мати у світі БД але це, як правило, відповідає дійсності), перейдіть з моїм найшвидшим і найбільш відданим TempDB (докладніше про це нижче), потім файли журналу, потім файли даних. У світі, де у вас є велика купа дисків на таких пристроях, як NetApp, Dell Equal Logic або EMC VNX тощо.

2.) Які причини TempDB можуть бути вищими?

Отже, TempDB - це база даних, і вона може мати кіоски IO, як і будь-яка інша база даних, як я щойно обговорював. Але які причини TempDB можуть мати більш високі показники? (не вичерпно, я вітаю доповнення чи думки в редакціях, інших відповідях чи коментарях) -

1. Через ваш код - Чи багато ви використовуєте TempDB у своєму коді цілеспрямовано? Створено та знищено багато темп-таблиць та змінних таблиць? Робите багато тем у TempDB, як це? Це не погано або добре не обов'язково, але ви можете подивитися на це і зрозуміти свою навмисну ​​схему використання TempDB.
2. TempDB - це спільна робоча коня - TempDB - це одна база даних, яка використовується як тимчасовий простір для визначених користувачем тимчасових об'єктів та різних робочих таблиць та операцій, які використовуються вашим усім екземпляром SQL. Скільки баз даних користувачів є? Яке навантаження ви взагалі бачите? TempDB - це один ресурс для спільного використання всіх речей.
3. Неефективні запити та недостатня пам'ять. Можливо, є запити, які не використовують індекси досить чітко або виконують великі операції сканування та сортування. Великі хеш-операції, і пам'ять на сервері для цього недостатня. Ці операції "перекинуться" на TempDB як робочі таблиці за кадром. Іноді цього можна уникнути, переглянувши свої плани запитів та індексуючи або налаштувавши запити. Іноді це трапляється (тим більше, на складські навантаження, я вважаю). Якщо у вас достатньо пам’яті, це може допомогти, але ці запити можуть все-таки розпливатися. Подивіться і на це.
4. Чи використовуєте Ви проаналізований рівень Ізольований знімків знімків із достатньою кількістю оновлень у вашій системі? Це також може призвести до збільшення активності TempDB.

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

TempDB ділиться між усіма базами даних про екземпляр. Тому іноді в TempDB можуть виникати суперечки щодо певних сторінок: SGAM , GAM та PFS . У двох словах, ці сторінки відстежують те, що використовувалося в TempDB досі, і де доступний простір для нового використання.

Зазвичай це вирішується шляхом додавання декількох файлів даних до TempDB. Існує кілька різних філософій щодо правильного числа, але всі згодні, у вас повинно бути більше одного.

Ось кілька запитів для запуску ...

Цей покаже вам, скільки файлів має TempDB та де вони знаходяться.

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

Цей покаже вам, скільки процесорів і ядер у вас є.

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

Цей покаже вам, скільки NUMA-вузлів та ядер на NUMA-вузол у вас є.

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

Ця покаже вам, які сторінки ви чекаєте в TempDB.

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

Ось стаття, яка заглиблюється у проблему вмісту сторінки.

Гаразд, тепер філософська частина ... :-)

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

Якщо я перебуваю в системі NUMA , то мені потрібно лише стільки файлів, скільки ядер на вузол NUMA .

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

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