tempdb для 1С: сколько файлов, какого размера и где их держать

tempdb — общая на весь инстанс временная база, и 1С грузит её сильнее почти любого другого приложения. Каждый мало-мальски сложный запрос платформы создаёт временные таблицы, и при трёх десятках активных пользователей они создаются сотнями в минуту. Если tempdb настроена по умолчанию, она становится узким местом раньше, чем сама база. Разберём, как это увидеть и что настроить.

Дело в том, как платформа строит запросы.

Язык запросов 1С активно использует временные таблицы: они создаются при работе с виртуальными таблицами регистров, при соединениях, в механизме ограничения доступа, при формировании отчётов на СКД. Программист пишет запрос с конструкцией помещения во временную таблицу — и это буквально превращается в создание таблицы в tempdb.

Помимо явных временных таблиц, tempdb используется под сортировки, не поместившиеся в память, версии строк при определённых уровнях изоляции, промежуточные результаты хеш-соединений.

Порядок величин из наших замеров: на базе УТ с 40 активными пользователями создаётся от 200 до 900 временных объектов в минуту в обычный рабочий день. В момент формирования тяжёлых отчётов — больше.

Отсюда следствие, которое стоит принять сразу: tempdb для 1С — не служебная мелочь, а компонент, требующий отдельной настройки наравне с самой базой.

И ещё одно: tempdb одна на весь инстанс. Если на сервере несколько баз 1С, они конкурируют за неё все вместе.

Узкое место возникает не там, где ожидают. Это не пропускная способность диска, а конкуренция за служебные страницы.

В каждом файле базы данных есть специальные страницы, отслеживающие, какие экстенты свободны: PFS, GAM и SGAM. При создании любого объекта СУБД должна обновить эти страницы.

Когда сотня потоков одновременно создаёт временные таблицы в одном файле, все они выстраиваются в очередь за защёлкой на одну и ту же служебную страницу. Диск при этом может быть загружен на 5 %.

Проявляется это ожиданиями типа PAGELATCH_UP и PAGELATCH_EX на ресурсах вида 2:1:1, 2:1:3 — где двойка означает базу tempdb.

SELECT session_id, wait_type, wait_duration_ms, resource_description
FROM sys.dm_os_waiting_tasks
WHERE wait_type LIKE 'PAGELATCH%'
  AND resource_description LIKE '2:%';

Если этот запрос в час пик регулярно что-то возвращает — у вас классический tempdb contention.

Решение — несколько файлов данных. Каждый файл имеет собственный комплект служебных страниц, и SQL Server распределяет выделение между файлами по кругу. Очередь размывается на несколько независимых.

Правило, устоявшееся в индустрии и подтверждённое нашей практикой.

То есть на сервере с 4 ядрами — 4 файла, с 8 ядрами — 8, с 24 ядрами — тоже 8 для начала.

Заводить по файлу на каждое ядро при 32 ядрах не нужно: выигрыш перестаёт расти, а накладные расходы на управление файлами появляются.

Критически важное условие: все файлы должны быть одинакового размера и иметь одинаковый шаг роста. Механизм распределения в SQL Server использует пропорциональное заполнение — он предпочитает файл с большим объёмом свободного места. Если один файл на 8 ГБ, а три по 1 ГБ, все обращения пойдут в первый, и вы получите ту же очередь, что и с одним файлом.

ALTER DATABASE tempdb MODIFY FILE (NAME='tempdev', SIZE=4096MB, FILEGROWTH=512MB);
ALTER DATABASE tempdb ADD FILE (NAME='tempdev2',
  FILENAME='T:\\tempdb\\tempdev2.ndf', SIZE=4096MB, FILEGROWTH=512MB);
-- и так далее до нужного числа

Файл журнала tempdb — всегда один. Разделять его смысла нет, запись в журнал последовательная.

Проверить текущую конфигурацию:

SELECT name, physical_name, size/128 AS size_mb, growth, is_percent_growth
FROM tempdb.sys.database_files;

Колонка is_percent_growth должна быть нулевой у всех файлов: процентный рост для tempdb — плохая идея, шаг становится непредсказуемым.

tempdb пересоздаётся при каждом запуске службы SQL Server. Это значит, что после перезагрузки она возвращается к заданному размеру и начинает расти заново.

Рост файла — это пауза. Если tempdb растёт с 8 МБ до 20 ГБ за первый рабочий день, вы получаете сотни таких пауз.

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

Как узнать свою потребность: посмотреть, до какого размера tempdb вырастает за неделю работы.

SELECT SUM(size) * 8 / 1024 AS tempdb_mb FROM tempdb.sys.database_files
WHERE type_desc = 'ROWS';

Замеряем в конце недели, добавляем 30 % и делим на число файлов — получаем размер каждого.

Ориентиры, от которых мы отталкиваемся, если истории нет:

Место под tempdb резервируется на диске сразу, поэтому убедитесь, что оно есть. И включите мгновенную инициализацию файлов — тогда старт службы с большой tempdb не будет занимать минуты.

У tempdb есть свойство, которого нет у других баз: её содержимое не переживает перезапуск и не нуждается в восстановлении.

Из этого следует практический вывод: под tempdb можно и нужно использовать самый быстрый доступный диск, не заботясь об избыточности так же строго, как для боевой базы.

Приоритет размещения:

1. Отдельный локальный NVMe — идеальный вариант.
2. Отдельный SSD-том.
3. Отдельный том на общем массиве.
4. Тот же том, что и база — так делать не надо, но встречается чаще всего.

Почему разнесение важно: tempdb пишет интенсивно и вперемешку с чтением базы. На одном томе эти потоки конкурируют, и обе задачи страдают.

Отдельный нюанс для виртуальных машин. Некоторые платформы виртуализации позволяют создавать диски без резервного копирования и репликации. tempdb — идеальный кандидат: реплицировать её бессмысленно, а объём она занимает существенный. У клиента с базой 180 ГБ вынос tempdb на нереплицируемый диск сократил объём ежедневной репликации на 40 ГБ.

Что важно не забыть при переносе: после смены пути в ALTER DATABASE изменения вступают в силу только после перезапуска службы, и старые файлы надо удалить вручную — SQL Server их не подчистит.

Три проверки, покрывающие практически все проблемы с tempdb.

Первая — ожидания на служебных страницах. Запрос из раздела про contention. Выполнять в час пик, не утром.

Вторая — кто именно занимает tempdb. Полезно, когда она внезапно раздулась:

SELECT TOP 10 s.session_id, s.login_name, s.host_name,
       (u.user_objects_alloc_page_count - u.user_objects_dealloc_page_count) * 8 / 1024 AS user_mb,
       (u.internal_objects_alloc_page_count - u.internal_objects_dealloc_page_count) * 8 / 1024 AS internal_mb,
       t.text
FROM sys.dm_db_session_space_usage u
JOIN sys.dm_exec_sessions s ON s.session_id = u.session_id
OUTER APPLY (SELECT TOP 1 text FROM sys.dm_exec_requests r
  CROSS APPLY sys.dm_exec_sql_text(r.sql_handle)
  WHERE r.session_id = u.session_id) t
ORDER BY user_mb + internal_mb DESC;

Этот запрос показывает, какой сеанс сколько временного пространства держит, и текст его запроса. Обычно наверху оказывается один пользователь с тяжёлым отчётом — и это ответ на вопрос «почему tempdb выросла до 90 ГБ».

Третья — общий объём и свободное место. Стоит держать на мониторинге: заполнение tempdb под завязку останавливает работу всего инстанса, и сообщение об ошибке пользователи получают довольно невнятное.

Порог тревоги ставим на 80 % занятости.

Клиент — торговая компания, 44 рабочих места, УТ на MS SQL 2019, сервер с 16 логическими ядрами и 96 ГБ памяти.

Жалоба неспецифичная: «после обеда всё медленно». Классика, с которой мы начали методичную диагностику.

Счётчики ОС были в норме: процессор 35 %, память свободна, очередь к дискам меньше двойки. Диск не был узким местом.

Топ ожиданий SQL Server дал неожиданную картину: на первом месте с большим отрывом стоял PAGELATCH_UP — 62 % общего времени ожидания. Ресурсы в описании начинались с двойки, то есть tempdb.

Смотрим конфигурацию tempdb. Один файл данных. Размер 8 МБ — то есть дефолтный, ни разу не менявшийся с момента установки. Автоувеличение на 10 %.

Картина сложилась полностью. Каждый рабочий день tempdb начинала с восьми мегабайт и в течение дня доростала до одиннадцати гигабайт, совершая при этом несколько сотен операций увеличения. Плюс все сорок четыре пользователя создавали временные таблицы в одном-единственном файле, выстраиваясь в очередь за одной служебной страницей.

Что сделали за сорок минут в вечернее окно:

• перенесли tempdb на отдельный NVMe-том;
• создали 8 файлов данных по 2 ГБ каждый, шаг роста 512 МБ, одинаковые;
• журнал tempdb — один файл 4 ГБ;
• включили мгновенную инициализацию файлов.

Результат на замерах следующего дня: PAGELATCH_UP ушёл из топа ожиданий вообще. Среднее время проведения реализации упало с 4,1 секунды до 1,3. Формирование отчёта по остаткам — с 34 секунд до 9.

Заметьте: ни одного изменения в базе, конфигурации, коде или железе, кроме перемещения временной базы. Настройка, которая заняла меньше часа, дала ускорение основных операций втрое.

Мне этот случай кажется показательным ещё и потому, что tempdb — самая незаметная часть инстанса. Её не бэкапят, о ней не думают, и при этом она конфигурируется по умолчанию значениями из девяностых.

• Число файлов данных: по числу ядер до восьми, дальше восемь.
• Все файлы данных строго одинакового размера и с одинаковым шагом роста.
• Рост задан в мегабайтах, не в процентах.
• Размер задан с запасом, чтобы автоувеличение не срабатывало в рабочее время.
• Журнал tempdb — один файл разумного размера.
• tempdb вынесена на отдельный быстрый том, желательно локальный NVMe.
• Включена мгновенная инициализация файлов.
• На виртуальной машине диск tempdb исключён из репликации и бэкапа.
• Мониторинг свободного места с порогом 80 %.
• В час пик проверено отсутствие ожиданий PAGELATCH на ресурсах базы 2.

Настройка разовая и занимает меньше часа вместе с перезапуском службы. По соотношению затраченного времени к эффекту это одна из самых выгодных операций во всей оптимизации связки 1С и MS SQL.

Сколько файлов данных должно быть у tempdb?

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

Как понять, что tempdb стала узким местом?

По ожиданиям PAGELATCH_UP и PAGELATCH_EX на ресурсах, описание которых начинается с двойки — это идентификатор базы tempdb. Проверять надо в час пик. Характерная особенность: диск при этом может быть почти не загружен, потому что проблема в конкуренции за служебные страницы, а не в вводе-выводе.

Можно ли держать tempdb на диске без резервирования?

Не только можно, но и желательно. tempdb пересоздаётся при каждом запуске службы, её содержимое не нужно ни восстанавливать, ни реплицировать. Это идеальный кандидат на самый быстрый локальный NVMe и на исключение из бэкапов и репликации виртуальной машины.

Почему tempdb растёт до десятков гигабайт?

Обычно это один-два тяжёлых запроса с большими временными таблицами или сортировками. Найти виновника можно запросом к sys.dm_db_session_space_usage — он покажет, какой сеанс сколько временного пространства держит и какой запрос выполняет.