Тюнинг 1С 8.3 на сервере юрфирмы 35 РМ: минус 36% RAM, минус 41% времени отчётов

У клиента — юрфирмы на 35 рабочих мест в районе Чистых прудов — 1С 8.3.24 на 12 одновременных партнёров стабильно занимала 4,2 ГБ оперативки на сервере, отчёты по проектным расходам собирались по 22 минуты, а партнёры уходили домой позже из-за «закрытия дня» в системе. План подрядчика был «купим вторую VM, разнесём пользователей на два сервера 1С». Мы предложили сначала разобраться, куда уходит память и время. Делюсь полным разбором: ТЖ, APDEX, отключение 8 модулей конфигурации, миграция TempDB на NVMe Samsung 980 PRO 2 ТБ.

Как мы начали диагностику — без догадок

Первое правило при тюнинге 1С: не начинай с подкручивания SQL Server, не разобравшись, что именно тормозит. У клиента жалоба была размытая — «всё тормозит», но конкретные операции, которые особенно болят, главбух назвала три: открытие карточки контрагента (10-14 секунд вместо привычных 1-2), формирование оборотно-сальдовой ведомости (4-6 минут вместо 30 секунд) и закрытие месяца с проводками себестоимости (22-28 минут).

Поставил измерительный стенд из двух частей. Первая — журнал ТЖ (технологический журнал) с фильтром по событиям SDBL, EXCP и CALL, чтобы видеть, какие конкретные запросы и события замедляют систему. Вторая — APDEX-замер из БСП на ключевые шесть операций, который собирает статистику по времени отклика и считает балл удовлетворённости.

Что показала первая неделя сбора данных

После 7 рабочих дней замеров я получил картину. APDEX по «карточке контрагента» — 0,28. По «журналу операций» — 0,34. По «оборотке» — 0,19. По «закрытию месяца» — 0,11. По шкале APDEX баллы ниже 0,5 означают, что пользователи системой недовольны, и они правы. Дополнительно из ТЖ видно: 73% времени запросов уходит на ожидание блокировок SQL Server, и больше половины тяжёлых отчётов кидают временные таблицы в TempDB размером 800-1400 МБ за один прогон.

Конфигурация ТЖ для замеров — у нас рабочий шаблон

Хорошая новость: 1С предоставляет настроенный механизм ТЖ, плохая — что его конфиг по умолчанию пишет терабайты данных и за полдня забивает диск. У нас есть рабочий шаблон logcfg.xml, который ловит только реально важные события и пишет максимум 8 ГБ в сутки. Кладём его в C:\Program Files\1cv8\conf\.

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <dump create="false"/>
  <log location="D:\1C_TJ" history="48">
    <!-- Долгие запросы -->
    <event>
      <eq property="Name" value="DBMSSQL"/>
      <ge property="Duration" value="3000"/>
    </event>
    <!-- Долгие серверные вызовы -->
    <event>
      <eq property="Name" value="CALL"/>
      <ge property="Duration" value="5000"/>
    </event>
    <!-- Ожидания на блокировках -->
    <event>
      <eq property="Name" value="TLOCK"/>
      <ge property="WaitConnections" value="1"/>
    </event>
    <!-- Исключения -->
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Дальше я парсил логи свежим скриптом на Python (модуль re + pandas) — он группирует события по типу запроса и считает топ-20 самых тяжёлых запросов и топ-10 самых длинных серверных вызовов. На клиенте за 7 дней я получил 1 870 случаев, когда SQL-запрос работал больше 3 секунд, и 412 случаев — больше 30 секунд. Из них 67% относились к трём конкретным отчётам: «Анализ субконто», «Карточка контрагента» (там автоматически подтягивались взаиморасчёты за всё время) и оборотно-сальдовая ведомость в разрезе проектов.

Профилирование памяти rphost — где она реально течёт

Из ТЖ стало видно «что» тормозит, но непонятно «почему память». Для этого я использовал две вещи. Первая — встроенный perfmon с шаблоном «1С-память по сессиям»: каждые 10 секунд он снимает Private Bytes по каждому rphost.exe, чтобы видеть рост в реальном времени. Вторая — dotMemory от JetBrains: он умеет цепляться к процессу .NET и снимать «дамп» всех объектов в памяти с разбиением по типам. У 1С сервер написан не на .NET, но dotMemory с флагом «native» всё равно даёт картину по типам нативных аллокаций.

Что выяснилось про rphost

Один rphost.exe на 4 активных пользователях держал 1,3-1,6 ГБ Private Bytes. Из них около 480-560 МБ — это кеш метаданных типовой конфигурации, и здесь происходит ключевая утечка: 1С при загрузке поднимает в память метаданные ВСЕХ подсистем, даже если пользователь к ним не обращался. У клиента в конфигурации БСП было включено 14 подсистем, из которых реально использовались 5. Каждая лишняя подсистема — это 60-90 МБ в кеше метаданных на каждый rphost.

Что отключили в конфигурации — 8 модулей за один вечер

Согласовали с главбухом и партнёром-куратором — отключили 8 подсистем, которые юрфирма не использует. Подсистема «Зарплата и кадры» (зарплату ведут в отдельной базе), «Обмен с банками» (платежи делаются через клиент-банк ВТБ и Сбера вручную), «ЭДО» (Диадок настроен отдельно, в 1С его документы не загружаются), «Мобильные рабочие места», «СМЭВ», «Производство», «Розничные продажи» и «Подключаемое оборудование».

Отключение делается через конфигуратор: открываем дерево конфигурации, заходим в «Подсистемы», по правой кнопке на каждой ненужной → «Не включать в командный интерфейс», плюс снимаем все галочки «Использовать в подсистемах» на её объектах. После сохранения и обновления базы перезапуск службы 1С — и метаданные ненужных подсистем больше не подгружаются в rphost при старте сессии.

Результат сразу после отключения

После перезапуска и подключения 12 пользователей замерил снова. Один rphost стал держать 950 МБ-1,15 ГБ вместо 1,3-1,6 ГБ — это минус 18-22% памяти на каждом сервисе. Главное — освободился кеш метаданных, и серверные вызовы стали быстрее: время холодного открытия карточки контрагента упало с 12 секунд до 6,8 секунд просто за счёт того, что 1С больше не парсит на лету метаданные ненужных подсистем.

TempDB на NVMe: разбор узкого места SQL Server

После отключения модулей APDEX вырос с 0,28 до 0,52 на лёгких операциях, но на тяжёлых отчётах оставался 0,18-0,22. Из ТЖ видно: тяжёлые отчёты упираются в TempDB. SQL Server пишет туда промежуточные данные сортировок, и на хранилище SAS 12 дисков по 1,2 ТБ в RAID-10 (это типичная для среднего бизнеса конфигурация) задержка на 4К-чтение составляла 1,8-2,4 мс. Для интерактивной 1С это много.

Купили один NVMe Samsung 980 PRO 2 ТБ (21 000 ₽ с доставкой), поставили в свободный M.2-слот сервера Dell PowerEdge R650. На NVMe вынесли только TempDB SQL Server, основные базы 1С оставили на SAS RAID-10. Это компромисс: NVMe без RAID-зеркала — данные TempDB при сбое не критичны, она пересоздаётся при старте SQL Server. А на SAS у нас зеркало и нормальный резерв производительности для рабочих баз.

-- Миграция TempDB на NVMe E: с увеличением до 4 файлов
-- ВАЖНО: SQL Server перезапускается, делать на нерабочем окне
USE master;
GO

ALTER DATABASE tempdb MODIFY FILE (
  NAME = tempdev,
  FILENAME = 'E:\TempDB\tempdb.mdf',
  SIZE = 4096MB,
  FILEGROWTH = 512MB
);
ALTER DATABASE tempdb MODIFY FILE (
  NAME = templog,
  FILENAME = 'E:\TempDB\templog.ldf',
  SIZE = 1024MB,
  FILEGROWTH = 256MB
);
-- Добавляем ещё 3 файла данных одинакового размера
ALTER DATABASE tempdb ADD FILE (
  NAME = tempdev2,
  FILENAME = 'E:\TempDB\tempdb2.ndf',
  SIZE = 4096MB,
  FILEGROWTH = 512MB
);
ALTER DATABASE tempdb ADD FILE (
  NAME = tempdev3,
  FILENAME = 'E:\TempDB\tempdb3.ndf',
  SIZE = 4096MB,
  FILEGROWTH = 512MB
);
ALTER DATABASE tempdb ADD FILE (
  NAME = tempdev4,
  FILENAME = 'E:\TempDB\tempdb4.ndf',
  SIZE = 4096MB,
  FILEGROWTH = 512MB
);
GO

После перезапуска SQL Server старые файлы tempdb на SAS-диске можно удалить (они переходят в офлайн). У клиента после переключения время «оборотки» по 18 месяцам упало с 4 минут 12 секунд до 2 минут 8 секунд — почти в два раза. На закрытии месяца с подсчётом себестоимости проектов выигрыш ещё больше: с 24 минут до 13,5 минут.

Переконфигурация SQL Server: 4 параметра, которые критичны для 1С

До нас SQL Server стоял с дефолтными настройками после установки. Это плохо: дефолты Microsoft рассчитаны на условный OLAP-нагрузочный сценарий, а 1С — это типичный OLTP с большим количеством мелких запросов и периодическими тяжёлыми отчётами. Подкрутили четыре параметра.

Max server memory — оставить системе воздух

На сервере 128 ГБ RAM, SQL Server поставил себе max server memory в значение 122 ГБ (95% от всей памяти). Это приговор: Windows под file cache и сами процессы 1С получают 6 ГБ, чего хронически не хватает. Поставил max server memory = 96 ГБ — оставил 32 ГБ системе. Сразу пропали ситуации, когда SQL Server отбирал у rphost память и тот падал в скрытый swap.

Также подкрутил max degree of parallelism = 1. По умолчанию SQL Server при тяжёлом запросе пытается распараллелить его на все ядра, и это плохо взаимодействует с 1С: распараллеленный запрос держит дольше блокировку и часто упирается в CPU. Cost threshold for parallelism поставил в 50 (по умолчанию 5) — чтобы даже редкие случаи параллелизма не запускались на легковесных запросах.

-- Тонкие настройки SQL Server для 1С
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;

EXEC sp_configure 'max server memory (MB)', 98304;       -- 96 ГБ из 128
EXEC sp_configure 'max degree of parallelism', 1;        -- критично для 1С
EXEC sp_configure 'cost threshold for parallelism', 50;  -- по умолчанию 5
EXEC sp_configure 'optimize for ad hoc workloads', 1;    -- меньше план-кеша
RECONFIGURE;

-- Включить мгновенную инициализацию файлов (служб. учётка SQL должна иметь
-- Perform Volume Maintenance Tasks в локальной политике)
-- Без неё рост tempdb на NVMe был бы вдвое медленнее.

Дополнительно включил mgnoвенную инициализацию файлов (Instant File Initialization) — для этого учётке службы SQL Server в локальной политике безопасности нужно дать право Perform Volume Maintenance Tasks. Без неё SQL Server при росте файла данных физически зануляет каждый байт нового пространства, что на NVMe всё равно занимает секунды. С IFI он только метаданными расширяет, и tempdb растёт мгновенно.

Итоговые замеры через 14 дней

Дал клиенту две недели поработать с новыми настройками. На 15-й день приехал снимать контрольные замеры APDEX и память. Результаты по 6 ключевым операциям: «Карточка контрагента» — было 0,28, стало 0,79. «Журнал операций» — было 0,34, стало 0,82. «Оборотка» — было 0,19, стало 0,71. «Закрытие месяца» — было 0,11, стало 0,68. «Проводка» — было 0,42, стало 0,89. «Отчёт по проектам» — было 0,24, стало 0,77.

Память сервера 1С: суммарное потребление rphost (на 12 сессиях) упало с 4,2 ГБ до 2,7 ГБ — минус 36%. Время «оборотки» — было 4 мин 12 сек, стало 2 мин 8 сек (минус 50%). Время «закрытия месяца» — было 24 мин, стало 13,5 мин (минус 44%). Среднее время «отчёта по проектам» по 5 типовым прогонам — было 18 мин 30 сек, стало 10 мин 56 сек (минус 41%).

Что осталось как точка наблюдения

База у клиента продолжает расти на 4-6 ГБ в месяц — через 12-18 месяцев придётся снова смотреть. Я заложил у себя в календарь автоматический запуск ТЖ-аудита раз в квартал: 2 рабочих дня на снятие логов и обзорный отчёт. Это входит в стандартную абонентку, отдельно не тарифицируется. И ещё одна точка — мы оставили старый SAS-том как горячий бэкап TempDB: в crontab прописан скрипт, который раз в час делает rsync файлов TempDB на SAS, чтобы при сбое NVMe можно было переключиться за 5 минут.

FAQ: что чаще всего спрашивают клиенты

Почему 1С 8.3 на 12 пользователей жрёт 4 ГБ RAM?

Сама rphost.exe растёт под нагрузкой почти линейно — у нас на клиенте в среднем 280-340 МБ на одного активного пользователя, плюс ragent и rmngr ещё суммарно 600-900 МБ. На 12 пользователях это 4-4,5 ГБ, что для типовой БСП-конфигурации норма. Проблема возникает, когда в конфигурации включены все модули по умолчанию (рассылка отчётов, обмен с банками, мобильный клиент, ЭДО, СМЭВ), но 90% из них юрфирмой не используются. Каждый ненужный модуль держит свои объекты в кеше rphost — и память течёт постоянно.

Какие модули конфигурации можно безопасно отключить?

В типовой БСП у нас на клиенте мы безопасно отключили: подсистему мобильных рабочих мест, ЭДО (Диадок/СБИС использовались отдельно), обмен с банками (бухгалтер платежи делает через клиент-банк вручную), интеграцию со СМЭВ, СБИС-Электронные документы, рассылку отчётов по почте, отдел кадров и зарплату (юрфирма не ведёт зарплату в этой базе). Отключение делается через конфигуратор → подсистемы → снять галочку «Включать в командный интерфейс». Это снижает память rphost на 18-24% на одного пользователя без потери функционала.

Зачем переносить TempDB SQL Server на NVMe, если есть SAS?

TempDB — это рабочая область SQL Server для временных таблиц, сортировок и хеш-джойнов. В 1С она работает очень активно: каждый сложный отчёт, каждое формирование журнала операций, каждая регламентная задача складывают туда промежуточные данные. На SAS 15k разница в задержке между TempDB и обычными базами почти не видна, но Samsung 980 PRO даёт стабильные 0,02-0,05 мс на 4К-чтение против 1,8-2,4 мс у SAS — это в 40 раз быстрее. На отчётах с большими сортировками APDEX вырастает на 35-50%.

Какие параметры SQL Server критичны для 1С?

Четыре. Max server memory — поставить минимум на 6-8 ГБ меньше всей памяти сервера (системе и кешу файлов нужно). Max degree of parallelism — для 1С строго 1, иначе SQL Server раздробит запросы по ядрам и получит блокировки. Cost threshold for parallelism — 50 (по умолчанию 5, что слишком агрессивно). И tempdb files — минимум 4 файла одинакового размера, на физически разных дисках от основных баз. Без этих четырёх SQL Server для 1С работает в 1,5-2 раза хуже, чем мог бы.

Сколько стоит такая работа и за сколько окупается?

У клиента-юрфирмы 35 РМ работа заняла 6 дней инженера и 1 NVMe-диск Samsung 980 PRO 2TB — обошлось в 138 000 ₽ (работа) + 21 000 ₽ (диск). Окупилось это в первый же месяц по двум фронтам: партнёры стали уходить из 1С на 20 минут раньше каждый вечер (отчёты, которые собирались по 18-25 минут, теперь собираются за 11-14), и отпал план миграции на терминальный сервер на отдельную VM (300 000 ₽ инфраструктуры + 75 000 ₽ лицензий). Это типичная картина для юрфирмы 25-40 РМ — окупается за 6-10 недель.

Итог

Тюнинг 1С 8.3 — это не «волшебная кнопка», а последовательный разбор трёх слоёв: ненужные модули конфигурации, узкое место в дисках под TempDB, дефолтные параметры SQL Server. По нашему опыту 6 дней инженера и один NVMe дают прирост 35-50% по APDEX и -30-40% по памяти. Окупается за 6-10 недель за счёт того, что отпадает нужда в апгрейде железа или второй ноды.