почему 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 (изменив первую проблему - производительность ввода-вывода - это, вероятно, более простое и эффективное решение, но сначала определите, есть ли у вас проблемы)

Чем дольше обсуждение / ответ:

Здесь есть два вопроса:

1.) Что мне делать, когда я вижу высокие IO Stalls?

Во-первых, «высокий» в глазах смотрящего. Если бы вы спросили 10 администраторов баз данных о том, что «слишком высоко» для киосков ввода-вывода, вы, вероятно, получили бы 2-3 разных ответа с цифрами в них, 5-6 ответов «Это зависит» и один пустой взгляд. Я предполагаю, что среднее значение 400 мс здесь потенциально слишком велико, особенно если для других баз данных среднее время ожидания составляет 2 мс или меньше.

Независимо от того, какая база данных видит высокие киоски, вы должны подходить к ней одинаково. IO stall - это то, на что это похоже ... IO-запрос занимает больше времени, чем ожидалось. Stalling. Это случается Они происходят постоянно в системе с общими ресурсами и ограниченными ресурсами (на самом деле во всех наших системах). Они становятся проблемой, когда киоски становятся проблемами производительности или приводят к ним. Поэтому я надеюсь, что вы смотрите здесь как на упреждающую часть мониторинга или потому, что у вас возникли проблемы с производительностью, которые вы устраняете. Мы также не хотим заблудиться только в прилавках. Мы смотрим на часть головоломки, а не на общую картину. Может быть проблематично просто посмотреть статистику ожидания или статистику файла с момента последнего перезапуска SQL, потому что вы просматриваете все время, и некоторые окна обслуживания или окна большой нагрузки могут искажать счетчики. Поэтому убедитесь, что вы смотрите на полную картину.

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

1. Посмотрите статистику ожидания на сервере. @swasheck поделился отличной ссылкой в качестве комментария в ответе ниже. Это приведет вас к публикации Пола Рэндала о просмотре и анализе статистики ожидания в SQL Server. Иди туда. Какие ожидания вы видите? Видите ли ждет , связанные с исполнением IO ( PAGEIOLATCH_*, IO_COMPLETION, WRITELOGи т.д.?). Если вы это сделаете, это еще один признак того, что у вас есть некоторые проблемы с производительностью, связанные с IO, как в случае с IO. Но это дает вам другую форму соглашения здесь.
2. Посмотрите на производительность ввода-вывода. В частности, взгляд изнутри PerfMon на Physical Disk:Avg Disk Sec/Readи Avg Sec Disk Sec/Writeсчетчиках. Они измеряют вашу задержку. Наблюдайте за этими счетчиками в течение периода времени, сохраненного в файле журнала производительности. Что вы видели в среднем? Если вы видите числа более 0,020 секунд (20 мс), это может быть проблемой. Если вы видите числа более 40-50 мс или более, это более твердое указание на проблему. Также посмотрите на ваши шипы? Как высоко они поднимаются и как долго они служат? Если вы видите скачки в сотни мс, и они длятся десятки или десятки секунд или более и / или случаются часто, у вас, скорее всего, будут проблемы с производительностью ввода-вывода для вашей рабочей нагрузки.
3. Посмотрите на ваши настройки ввода-вывода. Что это? Локальные диски? SAN? Массив хранения? Какой вид повсюду и IOP вы должны увидеть из этого? Достаточно ли этого для того, что вы пытаетесь сделать? Вы, возможно, недооценили свой IO для своей рабочей нагрузки. Не просто смотрите на свои физические шпиндели, настройки RAID и т. Д. Посмотрите на ваши пути к дискам. Вы продвигаете все через одну ссылку 1GB, которой вы делитесь с большим количеством другого трафика? Можете ли вы взглянуть на показатели производительности диска с точки зрения хранилища.

( Примечание: для этого анализа статистики ожидания и анализа производительности - посмотрите на различные периоды и тип использования. У вас есть другая статистика использования ночью, чем днем? Окна пакетной обработки? Окна обслуживания, где вы перестраиваете много индексов? Посмотрите на эти инструменты во время каждого из этих периодов и поймите, что вы видите для каждого)

Еще один аспект производительности ввода-вывода здесь -

• Вы сказали, что системные и пользовательские базы данных являются общими. Это производство? Если так, то это не всегда лучший сценарий. Вы также обмениваетесь файлом журнала и файлами данных на тех же самых дисках? Это тоже не лучший сценарий. Что еще делит это хранилище? В мире, где вы беспокоитесь о шпинделях, рейд-группах и дисках и должны принимать решения о том, кто получит диски с лучшими рабочими характеристиками, я склонен (как правило), что не очень хорошо иметь в мире БД. но этот имеет тенденцию быть верным), перейдите к моему самому быстрому и самому посвященному TempDB (подробнее об этом ниже), затем файлам журнала, затем файлам данных. В мире, где у вас есть большая куча дисков на таких устройствах, как NetApp, Dell Equal Logic или EMC VNX и т. Д.

2.) По каким причинам TempDB может быть выше?

Так что TempDB - это база данных, и она может иметь IO-киотки, как и любая другая база данных, как я только что обсуждал. Но по каким причинам TempDB может иметь более высокое чтение? (не исчерпывающий, я приветствую дополнения или мысли в редактировании, другие ответы или комментарии) -

1. Из-за вашего кода - Вы целенаправленно используете в своем коде TempDB? Много временных таблиц и табличных переменных создано и уничтожено? Делать много вещей в TempDB, как это? Это не плохо и не обязательно хорошо, но вы можете посмотреть на это и понять свой намеренный шаблон использования TempDB.
2. TempDB является общей рабочей лошадкой - TempDB - это одна база данных, которая используется в качестве временного пространства для пользовательских временных объектов и различных рабочих таблиц и операций, используемых всем экземпляром SQL. Сколько существует пользовательских БД? Какую нагрузку вы видите в целом? TempDB - это единый ресурс для всех.
3. Неэффективные запросы и недостаточно памяти - возможно, есть запросы, которые недостаточно плотно используют индексы или выполняют большие операции сканирования и сортировки. Большие хэш-операции, и памяти на сервере недостаточно для них. Эти операции будут «перетекать» в TempDB как рабочие столы за сценой. Иногда этого можно избежать, просматривая ваши планы запросов и индексируя или настраивая запросы. Иногда это происходит (особенно на складах, я нахожу). Если у вас достаточно памяти, это может помочь, но эти запросы все равно могут время от времени появляться. Посмотри это тоже.
4. Используете ли вы уровень чтения Read Committed Snapshot Isolation с достаточным количеством обновлений в вашей системе? Это также может привести к увеличению активности 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. Поэтому я обычно начинаю с четырех и отслеживаю конфликты, как описано в статье, на которую я ссылаюсь.

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