Автор: Search Engine Q&A #12: Should you create multiple files for a user DB on a multi-core box?
На сайте SQLServerCentral.com развернулась очень интересная дискуссия о том, стоит ли создавать несколько файлов для пользовательской базы данных, потому что на сервере несколько ЦП. Я написал пару длинных ответов в ходе дискуссии и хотел продублировать их здесь, так как считаю, что это представляет широкий интерес.
Мой первый ответ был:
Не имеет смысла разделять любую базу данных на несколько файлов для производительности на ЦП, за исключением tempdb, которая может страдать от того, что несколько ЦП пытаются одновременно изменять одни и те же битовые карты распределения при высокой нагрузке, когда временные таблицы создаются и удаляются небольшими порциями (подробности тут). Однако есть исключение — и это когда база данных, не являющаяся tempdb, испытывает те же проблемы с конкуренцией за битовые карты распределения, но это случается только на очень высококлассном оборудовании при тысячах однострочных вставок в секунду на каждом ЦП. Это довольно редко. Я никогда этого не видел, но Кимберли видела.
Вместо этого следует рассмотреть разделение базы данных на файловые группы (filegroups), чтобы изолировать критически важные таблицы в отдельных файловых группах, или разделить секционированную таблицу по нескольким файловым группам.
За этим последовало обсуждение, в котором указывалось, что различные производители оборудования подразумевают обратное, как и несколько источников от Microsoft. Вот мой последний ответ:
Привет всем,
В литературе Microsoft действительно неясно, что множественные файлы в базе данных в основном относятся только к tempdb. Даже для tempdb не нужно создавать один файл на ядро — скорее, 1/4–1/2 от числа ядер.
Проблема с tempdb такова: типичные рабочие нагрузки создают и удаляют множество рабочих таблиц в секунду. Выделения для таблицы изначально являются одиночными страницами, а не целыми экстентами. Это означает, что необходимо выполнить поиск по странице SGAM в интервале 4 ГБ, чтобы найти смешанный экстент со свободной страницей для выделения. Несколько ЦП, одновременно атакующих эту страницу, вызывают конкуренцию за неё и проблемы с производительностью. Затем необходимо выделить страницу для первой страницы IAM — происходит то же самое. Затем эти страницы нужно пометить как выделенные на странице PFS — снова то же самое. И, наконец, эти страницы нужно вставить в строку sysindexes для таблицы — ещё больше конкуренции. Раньше это было особенно плохо, поэтому T1118 плюс несколько файлов было решением, при котором SQL Server распределял выделения одиночных страниц по файлам в tempdb в циклическом порядке, несколько уменьшая конкуренцию.
Начиная с SQL Server 2005 мы изменили механизм временных таблиц так, что при удалении временной таблицы кэшируются одна страница данных, одна страница IAM и записи системных таблиц (вместо sysindexes теперь используется «скрытая» таблица sys.allocation_units). Когда выделяется новая временная таблица, если есть кэшированный «шаблон временной таблицы», он используется, что уменьшает конкуренцию за различные битовые карты распределения. В сильно загруженной системе конкуренция всё ещё может возникать, поэтому несколько файлов для SMP-сервера всё ещё нужны, но не в таком большом количестве. И вам больше не нужен T1118 для пользовательских баз данных, но для tempdb он всё ещё нужен.
Итак, это более распространено для tempdb, но МОЖЕТ случиться и в пользовательской базе данных при экстремальной нагрузке на монструозном оборудовании. Тестирование должно показать, происходит ли это у вас. Если нет, не создавайте несколько файлов ради производительности.
Что касается того, что подходит для масштабируемости ввода-вывода вашего конкретного поставщика оборудования — это уже за пределами моей компетенции, и вам, возможно, придётся подумать об этом, если они это рекомендуют. Однако я бы всё равно отнёсся к этому с долей скептицизма и провёл собственное тестирование. Смотрите технический документ для получения информации о тестировании.
Комментариев нет:
Отправить комментарий