1С тормозит: 10 причин и способов ускорить

Звонок в пятницу, полтретьего дня. Главбух строительной компании «СтройАльянс»: «Евгений, 1С зависает по 20 секунд при открытии любого документа. Бухгалтерия стоит, отчётность горит, закрытие квартала послезавтра». Выезжаем. Смотрим — сервер 2012 года выпуска, 8 ГБ оперативки, обычный HDD на 7200 оборотов, и на этом хозяйстве работают 15 пользователей одновременно. SQL Server 2008 R2. Файловая база на 12 гигабайт. Антивирус Касперского сканирует каждый чих, включая файлы базы данных.

Классика. Мы видим такие ситуации минимум раз в месяц. Компания растёт, пользователей становится больше, база раздувается — а сервер всё тот же, что ставили «на первое время» шесть лет назад.

За неделю мы перевели «СтройАльянс» на новое железо с SSD, подняли SQL Server 2019, настроили tempdb, добавили исключения в антивирус и перевели базу в клиент-серверный режим. Результат: открытие документа — 1.5 секунды вместо 20. Формирование оборотно-сальдовой ведомости за год — 8 секунд вместо 4 минут. Закрытие месяца — 12 минут вместо полутора часов.

В этой статье я разберу 10 самых частых причин, по которым тормозит 1С, и расскажу, как каждую из них устранить. С конкретными цифрами, командами и рекомендациями из нашей практики. Никакой теории — только то, что реально работает.

Причина 1 — Жёсткий диск HDD вместо SSD

Это причина номер один. Не потому что самая сложная — а потому что встречается чаще всего и даёт самый заметный эффект после устранения.

1С — это, по сути, бесконечные операции чтения и записи на диск. Открыли документ — чтение. Записали проводки — запись. Сформировали отчёт — тысячи операций чтения из разных таблиц. Обычный HDD на 7200 оборотов выдаёт 80-120 операций ввода-вывода в секунду (IOPS). SSD — от 20 000 до 100 000 IOPS. Разница в сотни раз.

Что мы увидели у «СтройАльянса»: диск загружен на 100% практически постоянно. В диспетчере задач — среднее время отклика диска 45 мс. Для сравнения, у SSD это 0.1-0.5 мс.

Что делать:

• Минимум — SSD SATA (Samsung 870 EVO, Crucial MX500). Стоимость 1 ТБ — около 8 000 рублей
• Оптимально — NVMe SSD (Samsung 980 PRO, WD Black SN850). Стоимость 1 ТБ — 10-14 000 рублей
• Для серверов — серверные SSD с защитой от потери данных при отключении питания (Intel DC, Samsung PM883)
• Если бюджета на полный переход нет — перенесите на SSD хотя бы файлы базы данных SQL и tempdb. Остальное может остаться на HDD

Проверить загрузку диска просто: откройте Диспетчер задач → Производительность → Диск. Если активное время стабильно выше 80% — диск является узким местом.

-- Проверка задержек дисковой подсистемы в SQL Server
SELECT
    DB_NAME(database_id) AS [База],
    file_id,
    io_stall_read_ms / NULLIF(num_of_reads, 0) AS [Avg чтение мс],
    io_stall_write_ms / NULLIF(num_of_writes, 0) AS [Avg запись мс]
FROM sys.dm_io_virtual_file_stats(NULL, NULL)
ORDER BY io_stall_read_ms DESC;

Если средние задержки чтения больше 20 мс — дисковая подсистема однозначно тормозит вашу 1С.

Причина 2 — Мало оперативной памяти

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

Типичная картина: сервер с 8 ГБ RAM, на нём Windows Server (съедает 2-3 ГБ), SQL Server, сервер 1С, антивирус и ещё пара служб. SQL Server получает жалкие 3-4 ГБ и постоянно сбрасывает кэш на диск.

Формула расчёта памяти для сервера 1С:

• ОС Windows Server: 4 ГБ
• SQL Server: минимум 4 ГБ, оптимально — чтобы вся база помещалась в RAM
• Сервер 1С (rphost): 1-1.5 ГБ на каждого активного пользователя
• Прочее (антивирус, мониторинг): 1-2 ГБ

Для 15 пользователей: 4 + 8 + 22 + 2 = 36 ГБ минимум. Рекомендую 64 ГБ с запасом на рост.

-- Ограничение памяти SQL Server (пример для 24 ГБ)
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', 24576;
RECONFIGURE;

Как проверить, хватает ли памяти:

-- Проверяем, сколько памяти SQL Server реально использует
SELECT
    (physical_memory_in_use_kb / 1024) AS [SQL использует МБ],
    (total_physical_memory_kb / 1024) AS [Всего RAM МБ],
    (available_physical_memory_kb / 1024) AS [Свободно МБ]
FROM sys.dm_os_sys_memory
CROSS JOIN sys.dm_os_process_memory;

Если «Свободно МБ» стабильно меньше 500 — памяти не хватает. Добавляйте.

Причина 3 — Устаревший SQL Server

SQL Server 2008 R2. Мы до сих пор встречаем его у клиентов. Этот продукт вышел из расширенной поддержки Microsoft ещё в 2019 году. Он не получает обновлений безопасности, не умеет работать с современными механизмами оптимизации запросов, не поддерживает новые типы индексов и инкрементную статистику.

Каждая новая версия SQL Server содержит улучшения оптимизатора запросов. SQL Server 2019 и 2022 используют Intelligent Query Processing — набор автоматических оптимизаций, которые ускоряют типичные запросы 1С на 15-40% без каких-либо изменений в коде.

Конкретные улучшения, которые важны для 1С:

• Adaptive Joins (SQL 2017+) — оптимизатор выбирает оптимальный тип соединения таблиц на лету, а не при компиляции плана
• Memory Grant Feedback (SQL 2017+) — SQL Server учится на предыдущих выполнениях запроса и выделяет нужный объём памяти
• Batch Mode on Rowstore (SQL 2019+) — пакетная обработка данных даже для обычных таблиц, ускоряет аналитические отчёты в 2-5 раз
• Accelerated Database Recovery (SQL 2019+) — мгновенное восстановление после сбоя вместо долгого отката транзакций

Проверьте свою версию:

SELECT @@VERSION;

Если видите «2008», «2012» или «2014» — пора обновляться. Процедура миграции несложная: бэкап базы, установка новой версии, восстановление, обновление уровня совместимости базы.

Причина 4 — Файловая база вместо клиент-серверной

Файловая база 1С — это один большой файл 1Cv8.1CD, к которому все пользователи обращаются по сети одновременно. При каждой операции 1С читает и пишет данные напрямую в этот файл через SMB-протокол. Это всё равно что 15 человек пытаются одновременно редактировать один документ Word на сетевом диске. Работает? Формально да. Быстро? Нет.

Проблемы файловой базы при росте:

• Блокировки. 1С использует табличные блокировки. Пока один пользователь записывает документ, остальные ждут
• Сеть. Данные гоняются по сети туда-обратно. Запрос, который на SQL Server выполнится на сервере за 1 мс, в файловом режиме потребует передать мегабайты данных по сети
• Размер. При размере базы больше 4-5 ГБ файловый движок начинает откровенно тормозить
• Надёжность. Один скачок напряжения или обрыв сети во время записи — и база повреждена. Мы восстанавливали файловые базы после таких сбоев десятки раз. Не всегда успешно

Когда переходить на клиент-серверный вариант:

• Больше 3-5 одновременных пользователей
• Размер базы больше 2-3 ГБ
• Используются тяжёлые отчёты (оборотно-сальдовые за период, анализ субконто)
• Нужна надёжность — бэкапы SQL Server в разы удобнее и надёжнее копирования файла

Перевод базы на SQL Server делается штатными средствами 1С: выгрузка в .dt-файл из файловой базы и загрузка в новую клиент-серверную базу. Процедура занимает от 30 минут до нескольких часов в зависимости от размера базы. Данные не теряются.

Причина 5 — Не настроен tempdb

Это та причина, о которой знают далеко не все, но эффект от правильной настройки — огромный. tempdb — системная база данных SQL Server, которая используется для временных таблиц, сортировок, промежуточных результатов запросов и операций с версиями строк. 1С создаёт множество временных таблиц при формировании отчётов и проведении документов. Все они идут через tempdb.

По умолчанию SQL Server создаёт tempdb с одним файлом данных. Когда несколько пользователей одновременно формируют отчёты в 1С, они конкурируют за доступ к этому одному файлу. Возникают блокировки на уровне распределения страниц (allocation contention), и все ждут.

Правильная настройка tempdb:

1. Количество файлов = количеству ядер процессора, но не более 8. Для 4-ядерного сервера — 4 файла
2. Одинаковый размер всех файлов. SQL Server распределяет нагрузку пропорционально размеру файла. Если файлы разные — распределение неравномерное
3. Размещение на отдельном SSD, если есть возможность. Хотя бы не на том же диске, где основная база
4. Начальный размер — достаточно большой, чтобы избежать автоувеличения. Для 1С рекомендую 1-4 ГБ на файл

-- Настройка tempdb: добавляем файлы (пример для 4 ядер)
-- Сначала проверим текущее состояние
SELECT name, physical_name, size/128 AS [Размер МБ]
FROM sys.master_files WHERE database_id = 2;

-- Если файл один, добавляем ещё три
ALTER DATABASE tempdb ADD FILE (
    NAME = tempdev2, FILENAME = 'T:\tempdb\tempdev2.ndf', SIZE = 2048MB, FILEGROWTH = 512MB);
ALTER DATABASE tempdb ADD FILE (
    NAME = tempdev3, FILENAME = 'T:\tempdb\tempdev3.ndf', SIZE = 2048MB, FILEGROWTH = 512MB);
ALTER DATABASE tempdb ADD FILE (
    NAME = tempdev4, FILENAME = 'T:\tempdb\tempdev4.ndf', SIZE = 2048MB, FILEGROWTH = 512MB);

-- Не забываем привести первый файл к тому же размеру
ALTER DATABASE tempdb MODIFY FILE (
    NAME = tempdev, SIZE = 2048MB, FILEGROWTH = 512MB);

Также включите флаг трассировки 1118 (для SQL Server до 2016) — он отключает смешанные экстенты в tempdb и снижает конкуренцию:

-- Для SQL Server 2014 и ранее
DBCC TRACEON (1118, -1);

В SQL Server 2016 и новее это поведение включено по умолчанию.

Причина 6 — Раздутая база (нужна реструктуризация)

Базы 1С имеют свойство расти. Иногда — необоснованно. Мы видели базу 1С:Бухгалтерии на 45 ГБ у компании из 20 человек, которая вела учёт всего три года. После анализа выяснилось: 18 ГБ — это журнал регистрации, 8 ГБ — версии объектов (история изменений), 5 ГБ — удалённые, но не очищенные объекты. Реальных данных — 14 ГБ.

Что раздувает базу:

• Журнал регистрации. Записывает каждое действие каждого пользователя. За год может занять 10-20 ГБ. При этом никто его не читает
• История данных (версионирование). Если включено — каждое изменение документа сохраняет предыдущую версию. Удобно, но очень прожорливо
• Удалённые помеченные объекты. Пользователи «удаляют» документы, но 1С только помечает их. Физически они остаются в базе
• Итоги. Устаревшие рассчитанные итоги регистров, которые не пересчитывались годами
• Фрагментация. Индексы в SQL Server со временем фрагментируются, запросы выполняются медленнее

Что делать:

1. Тестирование и исправление через конфигуратор: Администрирование → Тестирование и исправление информационной базы. Отмечаем «Реструктуризация таблиц», «Сжатие таблиц», «Пересчёт итогов»
2. Удаление помеченных объектов: в режиме 1С:Предприятие — Администрирование → Удаление помеченных объектов
3. Сокращение журнала регистрации: оставьте записи за последние 3-6 месяцев, остальное — в архив
4. Пересчёт итогов: Администрирование → Управление итогами — пересчитать и установить актуальный период
5. Обслуживание SQL: регулярная дефрагментация индексов и обновление статистики

-- Проверка фрагментации индексов в базе 1С
SELECT
    OBJECT_NAME(ips.object_id) AS [Таблица],
    i.name AS [Индекс],
    ips.avg_fragmentation_in_percent AS [Фрагментация %],
    ips.page_count AS [Страниц]
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ips
JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE ips.avg_fragmentation_in_percent > 30 AND ips.page_count > 1000
ORDER BY ips.avg_fragmentation_in_percent DESC;

Рекомендую создать регламентное задание на обслуживание SQL Server — дефрагментация индексов и обновление статистики по ночам. В Management Studio это делается через Maintenance Plan за 15 минут.

Причина 7 — Антивирус сканирует базу 1С

Самая обидная причина тормозов. Обидная — потому что устраняется за две минуты, а эффект может быть колоссальным.

Что происходит: антивирус перехватывает каждую операцию чтения и записи файлов. SQL Server постоянно читает и пишет файлы базы данных (.mdf, .ldf), файлы tempdb, файлы бэкапов. Антивирус проверяет каждый из этих запросов. На загруженном сервере это десятки тысяч проверок в минуту.

Ещё хуже ситуация с файловой базой 1С. Файл 1Cv8.1CD постоянно модифицируется, и некоторые антивирусы начинают его полностью пересканировать при каждом изменении. Мы видели случаи, когда Kaspersky Endpoint Security увеличивал время проведения документа в 3-4 раза.

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

• Папку с файлами баз данных SQL Server (обычно C:\Program Files\Microsoft SQL Server\MSSQL*\MSSQL\DATA\)
• Папку tempdb (если вынесена на отдельный диск)
• Папку с бэкапами SQL Server
• Папку с файловыми базами 1С (если используются)
• Процессы: sqlservr.exe, ragent.exe, rphost.exe, rmngr.exe
• Расширения файлов: .mdf, .ndf, .ldf, .bak, .1CD

Для Kaspersky Endpoint Security: Настройки → Защита от файловых угроз → Область защиты → Исключения. Для Windows Defender: PowerShell от администратора:

# Исключения Windows Defender для SQL Server
Add-MpPreference -ExclusionPath "C:\Program Files\Microsoft SQL Server"
Add-MpPreference -ExclusionPath "D:\SQLData"
Add-MpPreference -ExclusionPath "T:\tempdb"
Add-MpPreference -ExclusionProcess "sqlservr.exe"
Add-MpPreference -ExclusionProcess "rphost.exe"
Add-MpPreference -ExclusionExtension ".mdf"
Add-MpPreference -ExclusionExtension ".ldf"
Add-MpPreference -ExclusionExtension ".ndf"

Причина 8 — Сетевые проблемы (для терминального доступа)

Если пользователи подключаются к 1С через терминальный сервер (RDP) или работают с файловой базой по сети — качество сетевого соединения напрямую влияет на скорость работы.

Для RDP-подключения критична задержка (latency), а не полоса пропускания. Можно иметь гигабитный канал, но если задержка 50 мс — каждый клик в 1С будет ощущаться с паузой. Для комфортной работы нужна задержка не более 20-30 мс.

Для файловой базы по сети критичны обе характеристики. Файловая 1С передаёт по сети огромные объёмы данных — при формировании отчёта может уходить несколько сотен мегабайт в обе стороны.

Что проверить:

• Пинг до сервера: ping -n 20 server_ip. Смотрите не только среднее время, но и потери пакетов. Даже 1% потерь — это заметные тормоза
• Скорость сети: скопируйте файл 500 МБ на сервер и обратно. Если скорость ниже 50 МБ/с в гигабитной сети — что-то не так
• Дуплекс сетевых карт: проверьте, что на сервере и коммутаторе установлен полный дуплекс (Full Duplex). Автосогласование иногда договаривается на Half Duplex
• Коммутатор: дешёвые неуправляемые коммутаторы за 2000 рублей иногда «захлёбываются» под нагрузкой. Для сервера 1С нужен хотя бы нормальный управляемый коммутатор

Для удалённых офисов, подключённых через VPN:

• Не гоняйте файловую базу через VPN. Только терминальный сервер или публикация на веб-сервере
• Проверьте MTU — неправильный MTU на VPN-туннеле вызывает фрагментацию пакетов и жуткие тормоза
• Рассмотрите тонкий клиент 1С вместо толстого — он передаёт меньше данных

Причина 9 — Устаревшая платформа 1С

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

Если у вас платформа 8.3.18 или старше — вы теряете производительность. В более новых версиях улучшены механизмы блокировок, оптимизирована работа с временными таблицами, ускорено формирование отчётов на СКД (системе компоновки данных).

Ключевые улучшения по версиям:

• 8.3.20 — оптимизация работы с временными таблицами, улучшенный механизм кэширования
• 8.3.21 — новый механизм управляемых блокировок, снижение количества deadlocks
• 8.3.22 — оптимизация СКД (отчёты формируются быстрее), улучшенная работа с большими списками
• 8.3.23 — параллельное выполнение фоновых заданий, ускорение интерфейса
• 8.3.24-8.3.26 — дальнейшие оптимизации движка запросов и работы с памятью

Обновление конфигурации — отдельная тема. Старые конфигурации (например, 1С:Бухгалтерия редакции 2.0) не оптимизированы под современные механизмы платформы. Если у вас стоит конфигурация 3-5 летней давности — обновите её. Разработчики 1С постоянно оптимизируют типовые конфигурации, ускоряют закрытие месяца, проведение документов, формирование отчётов.

Как проверить версию платформы: в 1С нажмите Справка → О программе. Или через командную строку:

:: Посмотреть установленные версии платформы 1С
dir "C:\Program Files\1cv8\" /AD /B
dir "C:\Program Files (x86)\1cv8\" /AD /B

Причина 10 — Плохо написанные отчёты и обработки

Бывает так: всё настроено идеально — SSD, 64 ГБ RAM, SQL Server 2022, tempdb на 8 файлов — а 1С всё равно тормозит. Но тормозит не вся, а при определённых операциях. Обычно это значит, что проблема в коде конкретного отчёта или обработки.

Типичные проблемы в коде 1С, которые убивают производительность:

• Запросы в цикле. Программист написал цикл по документам и внутри цикла выполняет запрос к базе. 1000 документов = 1000 запросов. Должен быть один запрос, который возвращает все данные сразу
• Отсутствие индексирования. Запрос фильтрует по полю, которое не проиндексировано. SQL Server вынужден сканировать всю таблицу. На таблице с миллионом записей это секунды ожидания
• Неоптимальные соединения. Соединение (LEFT JOIN) таблиц без условий или с условиями, которые не используют индексы. Результат — Cartesian product, миллиарды строк во временных таблицах
• Получение всех полей. ВЫБРАТЬ * ИЗ Документ.РеализацияТоваров вместо выборки конкретных полей. Передаются гигабайты ненужных данных
• Неправильное использование СКД. Вложенные наборы данных, слишком сложные группировки, вычисляемые поля с подзапросами

Как найти проблемный запрос:

-- Топ-10 самых тяжёлых запросов в SQL Server
SELECT TOP 10
    qs.total_elapsed_time / qs.execution_count / 1000 AS [Avg время мс],
    qs.execution_count AS [Выполнений],
    qs.total_elapsed_time / 1000 AS [Общее время мс],
    SUBSTRING(qt.text, 1, 200) AS [Запрос]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY qs.total_elapsed_time DESC;

Ещё полезнее — технологический журнал 1С. Включается в настройках сервера 1С и записывает все длительные запросы с полным текстом. Файл настройки:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\Logs\1C" history="24">
    <event>
      <eq property="name" value="DBMSSQL"/>
      <ge property="Durationus" value="5000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Этот конфиг записывает все SQL-запросы, которые выполняются дольше 5 секунд. Файл кладётся в C:\Program Files\1cv8\conf\logcfg.xml.

Бонус: чеклист ускорения 1С

Распечатайте и повесьте рядом с сервером. Или отправьте своему сисадмину.

Необязательно делать всё сразу. Начните с пунктов 1 (SSD) и 7 (антивирус) — они дают максимальный эффект при минимальных затратах. Потом — tempdb и реструктуризация. И так далее по списку.

Часто задаваемые вопросы

Заключение

1С тормозит не просто так. За каждым «зависанием» стоит конкретная причина: медленный диск, нехватка памяти, неправильная настройка SQL Server, раздутая база или плохой код. И у каждой причины есть конкретное решение.

Вернёмся к нашему «СтройАльянсу». Вот что мы сделали за неделю:

1. Заменили HDD на SSD Samsung 870 EVO 1 ТБ — 10 000 руб.
2. Добавили 16 ГБ RAM (было 8, стало 24) — 5 000 руб.
3. Обновили SQL Server с 2008 R2 до 2019 Express — бесплатно
4. Перевели базу с файловой на клиент-серверную — 3 часа работы
5. Настроили tempdb (4 файла по 2 ГБ) — 15 минут
6. Провели реструктуризацию (база сжалась с 12 до 7 ГБ) — 2 часа
7. Добавили исключения в антивирус — 2 минуты

Итог: 15 000 рублей на железо и день работы. Время открытия документа — с 20 секунд до 1.5 секунды. Бухгалтерия закрыла квартал вовремя. Главбух перестала звонить по пятницам.

Если ваша 1С тормозит и вы не знаете, с чего начать — начните с SSD и исключений в антивирусе. Это два действия, которые занимают минимум времени и дают максимальный эффект. А если хотите комплексный аудит и оптимизацию — мы в АйТи Фреш этим занимаемся каждый день.

Полезные ссылки: ИТС — Оптимизация производительности 1С, Microsoft Learn — Производительность SQL Server