Тормозит 1С: как отличить проблему инфраструктуры от проблемы конфигурации
25 июня 2026
Сергей Романов
Технический директор Ай-Ти-Про, архитектор инфраструктурных решений. Более 10 лет проектирует и сопровождает серверную инфраструктуру и СХД для клиент-серверных баз 1С
«1С опять виснет» — формулировка, с которой обычно начинается тикет в техподдержку. Дальше начинается диагностика: системный администратор проверяет загрузку сервера, смотрит логи, иногда обновляет платформу или конфигурацию. Часть проблем так и закрывается. Но инфраструктурные причины — диски, сеть, виртуализация, настройка СУБД — часто остаются за периметром этой проверки. Их видно не из консоли 1С и не из стандартного мониторинга загрузки CPU, а только если целенаправленно снимать метрики латентности, IOPS и сетевых задержек в момент сбоя. По нашей практике сопровождения инфраструктуры для 1С (файловые базы на 8.3 и клиент-серверные на SQL/PostgreSQL), значительная часть обращений «1С тормозит» решается именно на этом уровне — на уровне инфраструктуры, на которой она работает.
По частоте, с которой мы видим эти причины на практике, картина обычно такая: на первом месте — дисковая подсистема (она физически лимитирует все остальное, поэтому и встречается чаще всего), на втором — настройка СУБД «по умолчанию» без тюнинга под нагрузку 1С, дальше — конкуренция за ресурсы при виртуализации и только потом — сетевые ограничения, которые актуальны в основном для распределенных филиальных структур. Технический долг (оборудование, не рассчитанное на текущий объем) обычно не самостоятельная причина, а фон, на котором обостряются первые две.
Дальше — по каждой причине: за счет чего возникает деградация, как ее отличить от чужих симптомов и где инфраструктурные доработки не помогут.
Содержание
Быстрый диагностический чек-лист
Прежде чем разбирать причины подробно — таблица, по которой можно сориентироваться сразу: какой симптом на что указывает и как это быстро проверить, не дожидаясь полноценного аудита.
| Симптом | Вероятная инфраструктурная причина | Как быстро проверить |
|---|---|---|
| Тормозит при одновременной работе нескольких пользователей, отдельно — быстро | Локальные диски / низкий IOPS хранилища | Disk Latency в момент пиковой нагрузки |
| Тормозит конкретный тяжелый отчет, у остальных все ок | Запрос / алгоритм конфигурации, не инфраструктура | План запроса в Центре управления производительностью 1С |
| Тормозит при закрытии месяца / перерасчете | Конкуренция за CPU / диск с регламентными заданиями | Загрузка CPU и диска СУБД в момент операции |
| Тормозит только у удаленных офисов / филиалов | Задержка и джиттер канала | Ping / traceroute с замером джиттера в рабочие часы |
| Деградация началась резко после переезда баз на виртуализацию | Конкуренция виртуальных машин за ресурсы хоста, отсутствие приоритизации нагрузки на хранилище | Утилизация хоста гипервизора, а не только гостевой ОС |
| Деградация постепенная, на протяжении года-двух | Рост базы обогнал запас мощности оборудования | Динамика объема БД и числа сессий за 12–24 месяца |
Какие гипотезы при диагностике чаще всего оказываются ложными
По нашему опыту, одна из самых распространенных ошибок при диагностике производительности 1С — начинать с анализа конфигурации. Если проблема проявляется одновременно у всех пользователей и затрагивает разные операции (а не одну конкретную обработку), вероятность инфраструктурной причины обычно выше, чем проблемы в конкретном запросе или коде.
Несколько типичных заблуждений, с которыми мы регулярно встречаемся на стороне заказчика:
«Раз тормозит конкретный отчет — значит, дело в отчете»
Не всегда: если этот отчет просто самый тяжелый по объему чтения с диска, он первым проявляет проблему дисковой подсистемы, которая на легких операциях пока не заметна.
«У нас мощный сервер, инфраструктура точно не виновата»
Объем CPU и RAM в спецификации ничего не говорит про латентность диска и настройку СУБД — мы видели мощные серверы с дисковой подсистемой, которая обнуляет весь этот запас.
«Стало тормозить после обновления конфигурации — значит, дело в обновлении»
Обновление часто просто увеличивает нагрузку (новый функционал, дополнительные регистры) и проявляет узкое место, которое существовало и раньше, но было ниже порога заметности.
«Виртуализация сама по себе медленнее физического сервера»
Чаще всего проблема не в виртуализации, а в конкуренции виртуальных машин за процессорные ресурсы, память или производительность хранилища. В этом случае помогает корректировка конфигурации виртуальной среды, а не перенос на физический сервер.
Практический вывод
Симптом «тормозит у всех и везде» — сильный сигнал в сторону инфраструктуры. Симптом «тормозит в одном конкретном месте у конкретной операции» — сигнал в сторону конфигурации. Это не железное правило, но рабочая эвристика для первого шага диагностики.
1. Дисковая подсистема: самая частая и самая недооцененная причина
1С — это прежде всего нагрузка на случайный ввод-вывод небольшими блоками: чтение/запись записей в таблицах СУБД, временные файлы, журнал регистрации. Для файловой базы (.1CD) — это еще и блокировки на уровне файла при многопользовательской записи. В обоих случаях критичный показатель — не пропускная способность диска в МБ/с, а IOPS и латентность при случайном доступе.
Типичная картина, с которой мы сталкиваемся: базы 1С размещены на локальных дисках сервера — часто это SATA SSD или, что хуже, HDD в RAID 1/5 на встроенном контроллере без кэша записи. Под пять-десять пользователей такая конфигурация работает приемлемо. При росте числа сессий, объема базы и параллельных регламентных операций (закрытие месяца, перерасчет себестоимости, обмен с маркетплейсами) дисковая подсистема становится узким местом: латентность отклика диска растет с долей миллисекунды до десятков миллисекунд, и каждая операция записи в СУБД встает в очередь.
Это ровно тот сценарий, который мы закрывали на проекте для ювелирного производства (RAIDIX 5 + ERA Engine, All-Flash NVMe, 160 ТБ): базы 1С лежали на локальных дисках разрозненных серверов, и рост объема данных уже создавал постоянное узкое место в производительности, плюс отсутствие отказоустойчивости и риски потери данных при отказе диска — три проблемы шли в комплекте, потому что у них одна архитектурная причина: данные хранятся локально, без выделенного хранилища. Подробности — в кейсе.
За счет чего решается
Перенос баз на выделенное хранилище (СХД) с NVMe или SAS SSD вместо локальных дисков — снижает латентность случайного доступа с десятков мс до десятых долей мс.
Программный RAID с эффективной параллелизацией (например, RAIDIX) позволяет не упираться в производительность одного аппаратного контроллера и держать смешанную нагрузку — 1С, ВМ, бэкап — без деградации друг на друге.
Выделенное хранилище с блочным доступом позволяет обеспечить стабильную производительность и снизить влияние конкурирующих нагрузок по сравнению с локальными дисками серверов.
Где это НЕ поможет
Если база 1С физически невелика (до 10-25 ГБ), а тормозит конкретный отчет или обработка — узкое место почти наверняка не на дисках, а в самом запросе/алгоритме конфигурации. Замена дисков в этом случае денег съест, а проблему не решит.
Как проверить, не гадая
Снять метрики латентности диска (Disk Latency, Avg. Disk sec/Read и sec/Write в Windows Performance Monitor) в момент, когда пользователи фиксируют зависание. Норма для SSD — единицы мс, для NVMe — доли мс. Если на момент жалобы латентность стабильно выше 10 мс — это инфраструктура.
2. Клиент-серверный режим: СУБД настроена «по умолчанию»
Отдельная категория — это базы на клиент-серверном варианте (1С + MS SQL Server или PostgreSQL), где сама СУБД развернута без тюнинга под нагрузку 1С.
Частые находки при диагностике:
MAXDOP не ограничен на MS SQL — параллелизм запросов 1С на многопроцессорных серверах приводит к избыточному дроблению планов запросов и росту накладных расходов вместо ускорения.
Auto-growth файлов БД задан мелким шагом (10% по умолчанию) — рост базы вызывает частые операции расширения файла, каждая из которых блокирует запись.
Регламентные задания обслуживания индексов отсутствуют или не настроены — фрагментация индексов растет месяцами, планы запросов СУБД деградируют незаметно, пока не происходит резкий скачок времени отклика.
Память СУБД не выделена явно (max server memory не ограничен) — СУБД конкурирует за RAM с самой ОС и другими службами на том же сервере, что особенно болезненно при совмещении ролей (1С-сервер + СУБД на одной машине).
За счет чего решается
Регламентная настройка параметров СУБД под профиль нагрузки 1С (рекомендации фирмы «1С» по MS SQL и PostgreSQL для этого существуют и регулярно обновляются), выделение под СУБД отдельного сервера/ВМ с зафиксированными ресурсами, настройка плана обслуживания индексов и статистики.
Где это НЕ поможет
Если база 1С физически невелика (до 10-25 ГБ), а тормозит конкретный отчет или обработка — узкое место почти наверняка не на дисках, а в самом запросе/алгоритме конфигурации. Замена дисков в этом случае денег съест, а проблему не решит.
3. Сеть: задержка, которую не видно в спецификации канала
Для распределенной 1С (несколько офисов, обмен через РИБ или прямое подключение к серверу через VPN) узким местом часто оказывается не полоса пропускания, а задержка (latency) и ее колебания (jitter).
1С-клиент в клиент-серверном режиме делает множество относительно небольших запросов к серверу. При задержке канала 30-60 мс (типично для VPN между регионами через интернет-провайдера без приоритизации трафика) каждое такое обращение ощущается как подвисание интерфейса, даже если полосы канала формально достаточно. Это особенно заметно при работе через терминальный доступ с плохо настроенным RDP/тонким клиентом — задержка складывается дважды: клиент-сервер 1С и пользователь-терминал.
За счет чего решается
Терминальный доступ (вместо тонкого клиента через WAN) переносит вычислительную нагрузку ближе к серверу и СУБД, оставляя по каналу только экранный трафик — но требует правильной настройки самого терминального сервера (иначе получаем узкое место уже там). Для филиальной структуры — выделенные каналы или MPLS вместо публичного интернета снижают джиттер, что для 1С критичнее, чем абсолютная пропускная способность.
Где это НЕ поможет
Если все пользователи работают в одном офисе по локальной сети, сетевая причина исключается сразу — там при «тормозах» нужно смотреть диски и СУБД, а не сеть.
4. Виртуализация: оверселлинг ресурсов и неправильное выделение CPU
Если 1С-сервер развернут как виртуальная машина (Hyper-V, VMware, отечественные гипервизоры — zVirt, РЕД Виртуализация), частая причина деградации — конкуренция за ресурсы хоста.
CPU oversubscription — суммарное количество vCPU, выделенных всем ВМ на хосте, кратно превышает физические ядра. В моменты пиковой нагрузки (утренний вход всех пользователей, закрытие периода) гипервизор начинает квотировать процессорное время, и именно в этот момент 1С «зависает» сильнее всего.
Динамическая память (Dynamic Memory) без нижнего порога — гипервизор может забрать память у ВМ с СУБД в пользу другой ВМ, что вызывает своппинг внутри гостевой ОС.
Виртуальные диски на той же СХД/локальном RAID, что и другие ВМ — без приоритизации трафика хранилища (QoS) тяжелая ВМ (например, бэкап-агент) может «забрать» IOPS у виртуального диска с базой 1С в момент резервного копирования.
За счет чего решается
Резервирование CPU/RAM для критичных ВМ (1С-сервер, СУБД), отдельные тома или QoS-политики хранилища для разделения нагрузок, мониторинг утилизации хоста, а не только гостевой ОС.
Где это НЕ поможет
Если 1С развернута на физическом сервере без виртуализации — этот блок неприменим, искать нужно на уровне ОС и оборудования напрямую.
5. Технический долг: оборудование и архитектура, заложенные «на старте»
Часть инфраструктурных причин — не следствие ошибки настройки, а следствие роста бизнеса быстрее, чем рассчитывалась инфраструктура.
Типичный путь: сервер и СХД (если она есть) подбирались под текущий на момент покупки объем данных и число пользователей — без запаса на 3–5 лет. База 1С за это время вырастает в 3–5 раз (рост штатной численности, новые юрлица, расширение номенклатуры), число одновременных сессий увеличивается, а оборудование остается тем же. Деградация в этом случае не разовая, а постепенная — производительность падает на 5–10% в квартал, что незаметно «по ощущениям», но накопленный эффект за два-три года ощущается как «1С внезапно стала тормозить».
Сюда же относится исторически нарощенная виртуальная инфраструктура: каждая новая задача решалась добавлением еще одной ВМ на тот же хост и ту же СХД, без пересмотра общей архитектуры хранения и без отдельного учета профиля нагрузки 1С на фоне остальных систем.
За счет чего решается
Не разовым «апгрейдом железа», а пересмотром архитектуры с запасом по масштабированию — расчетом на 3–5 лет вперед по числу пользователей, объему баз и плану резервного копирования, с учетом совместимости с текущим стеком (домен, СУБД, виртуализация) и требований импортозамещения, если заказчик — госсектор или объект КИИ (требование к использованию решений из реестра Минцифры).
Где это НЕ поможет
Если бизнес не планирует расти и нагрузка стабильна — инвестиция в запас мощности экономически не обоснована, и это стоит прямо проговаривать на этапе TCO-расчета, а не продавать «на будущее».
Когда дело не в инфраструктуре
Честно: не каждый случай «1С тормозит» лечится инфраструктурой. Если диагностика показывает нормальную латентность диска, не перегруженный CPU и адекватно настроенную СУБД — а тормозит конкретная операция — проблема в коде конфигурации: неоптимальные запросы, отсутствие нужных индексов на уровне метаданных 1С, избыточные циклы в обработках. Это зона ответственности 1С-разработчика, а не инженера по инфраструктуре. Смешивать эти две зоны — типичная ошибка, которая приводит к покупке нового сервера там, где требовалась доработка кода, и наоборот.
Поэтому первый шаг — не закупка оборудования, а диагностика: где именно теряется время — на диске, в сети, в СУБД, в виртуализации или в самой 1С. Без этого любая инвестиция в инфраструктуру — это угадывание.
Что с этим делать
Если узкое место подтверждается на уровне инфраструктуры — дальше вопрос конфигурации: выделенное хранилище под базы 1С, тюнинг СУБД, пересмотр виртуализации, расчет запаса на рост. Это можно сделать поэтапно, начиная с диагностики, без того, чтобы сразу менять всю инфраструктуру целиком.
За 1–2 недели диагностики можно понять, связана проблема с дисковой подсистемой, настройкой СУБД, виртуализацией или с самой конфигурацией 1С. Это избавляет от расходов на оборудование там, где на самом деле нужна доработка кода — и наоборот, от бесконечной оптимизации запросов там, где упирается железо.
Мы проводим такую диагностику для компаний, использующих 1С в критичных для бизнеса процессах. Результат — карта узких мест, подтвержденная метриками, и план изменений с оценкой их влияния на производительность. Это позволяет принимать решения на основе данных, а не предположений о том, где находится ограничение.
За годы работы с инфраструктурой для 1С я видел один и тот же паттерн десятки раз: компания меняет железо, не понимая, в чем реальная причина, — и тормоза возвращаются через полгода, потому что проблему не диагностировали, а угадали. Если в вашем случае похожая ситуация — напишите, разберем конкретно вашу конфигурацию.
Сергей Романов, технический директор Ай-Ти-Про
Не знаете, с чего начать диагностику?
Расскажите о вашей инфраструктуре 1С. Проверим дисковую подсистему, СУБД, виртуализацию и сеть, найдем причину тормозов и покажем, что с ней делать
- диагностика по метрикам
- карта узких мест
- план работ с приоритетами
