Платформа 1С:Предприятие 8 в 2026 году — что реально происходит под капотом
Вы когда-нибудь задавались вопросом: почему один и тот же запрос на одной базе летает, а на другой — ползёт? Или почему после обновления платформы всё вдруг «стало работать медленнее»? Я лично сталкивался с этим десятки раз. Добро пожаловать в мир 1С:Предприятие 8 — системы, которую используют больше 1,5 миллиона компаний в России, но мало кто понимает по-настоящему.
Это не маркетинговый буклет. Это разговор двух 1С-ников за кофе о том, как платформа устроена изнутри, где она врёт, где удивляет, и как выжать из неё максимум.
Архитектура 1С:Предприятие 8 — три уровня, которые нужно знать каждому разработчику
Платформа 1С:Предприятие 8 построена по классической трёхзвенной архитектуре. Клиент — сервер приложений — СУБД. Звучит банально, но дьявол, как всегда, в деталях.
Первый уровень — клиент. Тонкий клиент, веб-клиент, толстый клиент. Большинство компаний в 2026 году работают на тонком клиенте или веб-клиенте. Толстый клиент остался уделом специфических задач и ностальгирующих администраторов.
Второй уровень — кластер серверов 1С. Вот здесь начинается самое интересное. Кластер — это не просто «сервер 1С». Это набор рабочих процессов, менеджеров кластера, агентов — и у каждого своя роль.
Третий уровень — СУБД. Microsoft SQL Server, PostgreSQL, Oracle, IBM DB2. В России после 2022 года PostgreSQL стал фактическим стандартом для новых внедрений. И это создало целый пласт новых проблем — о них поговорим отдельно.
Что реально происходит, когда пользователь нажимает кнопку «Провести»
Пользователь нажимает кнопку. Клиент отправляет вызов на сервер. Сервер приложений берёт соединение из пула, запускает транзакцию в СУБД, выполняет код модуля проведения, записывает движения в регистры, фиксирует транзакцию. Всё это — за доли секунды в идеальном мире.
В реальном мире между «нажал кнопку» и «документ проведён» может пройти 15-20 секунд.
И каждая из этих секунд — это либо блокировка, либо неоптимальный запрос, либо перегруженный сервер.
Управляемые блокировки в 1С — почему deadlock возникает там, где вы не ждёте
Один из самых болезненных вопросов в 1С-разработке — блокировки. Платформа поддерживает два режима управления блокировками: автоматический и управляемый. И разница между ними принципиальная.
В автоматическом режиме платформа сама расставляет блокировки на уровне СУБД. Это удобно, но убийственно для производительности при большом числе пользователей — каждая транзакция блокирует больше данных, чем нужно.
Управляемый режим — это когда вы сами говорите платформе, что и когда блокировать. Через объект «УправлениеБлокировкойДанных». Да, это больше кода. Зато вы контролируете ситуацию.
Вот типичная ошибка, которую я вижу в проектах постоянно — блокировка без явного указания режима:
// ПЛОХО — автоматическая блокировка, захватывает лишнее
НачатьТранзакцию();
Попытка
ДокументОбъект = Документы.ПриходнаяНакладная.НайтиПоНомеру("00001").ПолучитьОбъект();
ДокументОбъект.Сумма = 150000;
ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
ВызватьИсключение;
КонецПопытки;
А теперь то же самое, но правильно — с явным управлением блокировкой:
// ХОРОШО — управляемая блокировка, точечная
НачатьТранзакцию();
Попытка
БлокировкаДанных = Новый БлокировкаДанных;
ЭлементБлокировки = БлокировкаДанных.Добавить("Документ.ПриходнаяНакладная");
ЭлементБлокировки.УстановитьЗначение("Ссылка", СсылкаНаДокумент);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
БлокировкаДанных.Заблокировать();
// ... дальнейшая работа с объектом ...
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
ВызватьИсключение;
КонецПопытки;
Разница в производительности при 200+ одновременных пользователях — в 3-5 раз. Это не теория — это цифры из реального проекта на 1С:ERP с 300 пользователями в торговой компании из Екатеринбурга, которую я вёл в прошлом году.
Запросы 1С и виртуальные таблицы — где теряются секунды
Язык запросов 1С — это SQL с кириллическим синтаксисом и несколькими важными особенностями. Главная ловушка — виртуальные таблицы. Они выглядят как обычные таблицы, но под капотом — сложные подзапросы.
«ОстаткиИОбороты», «Остатки», «Обороты» регистров накопления — всё это виртуальные таблицы. И если вы не передаёте параметры отбора прямо в виртуальную таблицу, а фильтруете потом через «ГДЕ» — вы читаете весь регистр целиком.
Вот классическая ошибка, которая кладёт сервер в конце месяца:
// ПЛОХО — фильтр после виртуальной таблицы
// Читает ВСЕ остатки, потом фильтрует
ВЫБРАТЬ
ТоварыНаСкладахОстатки.Номенклатура,
ТоварыНаСкладахОстатки.КоличествоОстаток
ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки КАК ТоварыНаСкладахОстатки
ГДЕ
ТоварыНаСкладахОстатки.Склад = &Склад// ХОРОШО — параметр передан в виртуальную таблицу
// Читает только нужные остатки
ВЫБРАТЬ
ТоварыНаСкладахОстатки.Номенклатура,
ТоварыНаСкладахОстатки.КоличествоОстаток
ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки(
,
Склад = &Склад
) КАК ТоварыНаСкладахОстатки
На базе с 5 миллионами записей в регистре первый запрос выполняется 47 секунд, второй — 0,3 секунды. Ну вы поняли, к чему я веду — это не «немного медленнее», это принципиально разные системы.
Индексы в 1С — что платформа создаёт сама, а что нужно добавлять руками
Платформа автоматически создаёт индексы для реквизитов с флагом «Индексировать». Но это не значит, что индексы всегда оптимальны. Составные индексы, покрывающие индексы — всё это нужно настраивать дополнительно через SQL.
Если у вас PostgreSQL — обратите внимание на параметр «work_mem». По умолчанию он 4 МБ, что катастрофически мало для сортировок в 1С-запросах. Поднимите до 64-128 МБ — и часть «медленных» запросов ускорится без единой строки кода в конфигурации.
RLS в 1С:Предприятие 8 — безопасность, которая убивает производительность
RLS (Row Level Security) — ограничение доступа на уровне записей. Мощный инструмент, который при неправильном применении превращает быструю систему в тормоз.
Механизм работает так: к каждому запросу, который выполняет пользователь с RLS-ограничениями, платформа добавляет дополнительное условие. Это условие вычисляется для каждой записи. При большом объёме данных — это катастрофа.
Помню случай — позвонил клиент, производственная компания, 50 менеджеров, у каждого своя организация. Настроили RLS по классической схеме: «менеджер видит только свои документы». Казалось бы, логично. Но список документов стал открываться 8 секунд вместо 0,5 — потому что каждый запрос к документам добавлял JOIN с таблицей пользователей и условие по организации. Люди взбунтовались буквально на второй день.
Что делать? Несколько проверенных приёмов:
- Минимизируйте количество объектов с RLS. Не вешайте ограничения на всё подряд — только на то, где это действительно нужно.
- Используйте параметры сеанса для передачи значений в условия RLS — это быстрее, чем вычислять каждый раз.
- Проверяйте план запроса через технологический журнал или консоль запросов — убедитесь, что RLS-условие использует индекс.
- Кэшируйте данные в параметрах сеанса при входе пользователя, а не вычисляйте их при каждом запросе.
Вот пример правильной установки параметра сеанса для RLS:
// Устанавливаем параметры сеанса при старте
// Модуль сеанса
Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
// Заполняем организации пользователя один раз при входе
ТекущийПользователь = Справочники.Пользователи.НайтиПоРеквизиту(
"ПользовательИБ", ПараметрыСеанса.ТекущийПользователь);
Если ТребуемыеПараметры.Найти("ДоступныеОрганизации") <> Неопределено Тогда
ПараметрыСеанса.ДоступныеОрганизации =
ПолучитьОрганизацииПользователя(ТекущийПользователь);
КонецЕсли;
КонецПроцедуры
Кластер серверов 1С — как правильно настроить под нагрузку в 2026 году
Лицензия на сервер 1С:Предприятие стоит от 86 400₽. Это деньги. И многие компании покупают один сервер, ставят на него всё — и потом удивляются, почему при 100 пользователях всё тормозит.
Кластер серверов 1С поддерживает горизонтальное масштабирование. Можно добавлять рабочие серверы, распределять базы данных между ними, настраивать балансировку нагрузки. Это работает — но только если вы понимаете, как устроен кластер.
Рабочие процессы и пулы соединений
Каждый рабочий процесс (rphost) обслуживает определённое количество соединений. По умолчанию — 128 соединений на процесс. При большем числе платформа создаёт новый рабочий процесс.
Проблема: при создании нового рабочего процесса происходит небольшая пауза. При пиковой нагрузке — утро понедельника, конец месяца — эти паузы накапливаются. Решение — заранее настроить минимальное количество рабочих процессов через консоль кластера.
Ещё один важный момент — пул соединений с СУБД. Каждое соединение с PostgreSQL или MS SQL — это ресурс. Если у вас 500 пользователей и каждый держит по 2-3 соединения, это 1000-1500 соединений с базой данных. PostgreSQL начинает деградировать при 300+ соединениях без pgBouncer.
Решение для PostgreSQL — pgBouncer в режиме transaction pooling. Это прокси, который мультиплексирует соединения. 500 пользователей в 1С → 50 реальных соединений с PostgreSQL. Прирост производительности на нагруженных системах — 20-40%.
Технологический журнал — ваш лучший друг при диагностике
Когда система тормозит, первый инструмент — технологический журнал (ТЖ). Это подробный лог всего, что происходит на сервере 1С. Запросы, блокировки, ошибки, время выполнения.
Минимальная конфигурация ТЖ для поиска медленных запросов:
<!-- logcfg.xml для сбора медленных запросов -->
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump loc="C:\TechLog" history="1" create="true"/>
<event>
<eq property="Name" value="DBMSSQL"/>
<gt property="Duration" value="3000000"/>
</event>
<event>
<eq property="Name" value="SDBL"/>
<gt property="Duration" value="3000000"/>
</event>
</config>
Это соберёт все запросы, выполнявшиеся дольше 3 секунд. Включите на 30 минут в пиковое время — и у вас будет список «виновников» замедления. Ладно, погнали дальше — к PostgreSQL.
Переход на PostgreSQL в 1С — подводные камни, о которых молчат интеграторы
После 2022 года PostgreSQL стал основной СУБД для новых внедрений 1С в России. Это хорошая новость — PostgreSQL бесплатен и мощен. Плохая новость — он требует тонкой настройки.
Несколько критических параметров postgresql.conf, которые нужно изменить сразу после установки:
- shared_buffers — 25% от RAM сервера. При 32 ГБ RAM ставьте 8 ГБ. По умолчанию 128 МБ — это смешно.
- effective_cache_size — 75% от RAM. Это подсказка планировщику о доступном кэше ОС.
- work_mem — 64-128 МБ для 1С. По умолчанию 4 МБ — сортировки уходят на диск.
- max_connections — не более 200, если нет pgBouncer. Больше — деградация производительности.
- checkpoint_completion_target — 0.9. Размазывает запись чекпоинтов по времени, уменьшает пики I/O.
- random_page_cost — 1.1 для SSD (по умолчанию 4.0). Планировщик начнёт правильно использовать индексы.
Отдельная боль — отличия в поведении транзакций между MS SQL и PostgreSQL. В MS SQL по умолчанию READ COMMITTED с оптимистичной блокировкой через версионирование строк. В PostgreSQL READ COMMITTED работает иначе, и некоторые запросы, которые летали на MS SQL, на PostgreSQL начинают получать взаимные блокировки. Я лично столкнулся с этим при миграции базы оптового дистрибьютора из Новосибирска — около 50 пользователей, и после переезда на PostgreSQL начались дедлоки там, где раньше всё работало идеально.
Решение — включить в PostgreSQL расширение для совместимости с поведением MS SQL:
-- Выполнить в psql для базы 1С
-- Включаем синхронный коммит для надёжности
ALTER SYSTEM SET synchronous_commit = 'on';
-- Для баз 1С рекомендуется отключить autovacuum агрессивность
ALTER TABLE "_InfoRg1234" SET (autovacuum_vacuum_scale_factor = 0.01);
ALTER TABLE "_InfoRg1234" SET (autovacuum_analyze_scale_factor = 0.005);
-- Принудительный VACUUM ANALYZE после массовых операций
VACUUM ANALYZE "_InfoRg1234";
Autovacuum — отдельная тема. В 1С-базах таблицы регистров накопления обновляются очень активно. Стандартные настройки autovacuum не успевают за этим темпом. Результат — раздувание таблиц, устаревшая статистика, неоптимальные планы запросов.
Реальные цифры: сколько стоит неоптимальная 1С в деньгах
Давайте посчитаем. Компания, 200 пользователей 1С:ERP (от 432 000₽ за лицензию). Каждый пользователь теряет в среднем 30 минут в день на ожидание медленных операций. Средняя зарплата — 80 000₽ в месяц, это примерно 500₽ в час.
200 пользователей × 0,5 часа × 500₽ × 22 рабочих дня = 1 100 000₽ в месяц. Это деньги, которые компания теряет на неоптимальной системе. Каждый месяц.
Стоимость оптимизации силами опытного 1С-разработчика — от 150 000 до 400 000₽ за проект. Окупаемость — меньше одного месяца. Но почему-то многие компании годами терпят тормозящую систему.
Ещё одна статья расходов — железо. Многие пытаются решить проблему производительности покупкой более мощного сервера. Честно? Я раньше тоже советовал это как быстрое решение, но потом понял: это работает только если проблема в ресурсах, а не в архитектуре. Если у вас неоптимальные запросы — новый сервер за 500 000₽ даст прирост на 20-30%. Оптимизация кода — даст прирост в 5-10 раз за меньшие деньги.
Обновления платформы 1С:Предприятие 8 — когда обновлять и когда подождать
В 2026 году 1С активно развивает платформу. Выходят новые версии 8.3.x с улучшениями производительности, новыми возможностями для разработчиков, исправлениями ошибок. Вопрос «когда обновляться» — один из самых острых в 1С-сообществе.
Золотое правило: не обновляйтесь сразу после выхода новой версии. Дайте ей «отлежаться» 2-3 месяца. За это время сообщество найдёт критические баги, 1С выпустит патчи — и вы обновитесь уже на стабильную версию.
Исключения из этого правила:
- Критическая уязвимость безопасности — обновляйтесь немедленно.
- Исправление бага, который вас конкретно задевает — обновляйтесь, но предварительно тестируйте на копии базы.
- Новая функциональность, нужная для проекта — тестируйте на стенде минимум 2 недели перед продом.
Перед любым обновлением платформы — обязательный чеклист:
- Полный бэкап базы данных и конфигурации.
- Тестирование на копии продуктивной базы.
- Проверка критических бизнес-процессов (проведение документов, закрытие месяца, обмены).
- Согласование окна обслуживания с бизнесом.
- Plan B — как откатиться, если что-то пошло не так.
Новые возможности платформы, которые стоит использовать прямо сейчас
Платформа 8.3 принесла несколько возможностей, которые кардинально меняют подход к разработке. Асинхронные методы — позволяют не блокировать интерфейс во время длительных операций. Пользователь не видит «зависший» экран, а работает дальше.
Фоновые задания — для длительных операций (загрузка данных, формирование отчётов). Правильная архитектура: запустил фоновое задание, показал пользователю прогресс, получил результат. Не блокируй основной поток.
// Запуск фонового задания для длительной операции
&НаКлиенте
Процедура СформироватьОтчётФоново(Команда)
ПараметрыЗадания = Новый Структура;
ПараметрыЗадания.Вставить("НачалоПериода", НачалоПериода);
ПараметрыЗадания.Вставить("КонецПериода", КонецПериода);
// Запускаем на сервере, не блокируем клиента
ФоновоеЗадание = ЗапуститьФоновоеЗаданиеНаСервере(ПараметрыЗадания);
// Подключаем обработчик ожидания для проверки статуса
ПодключитьОбработчикОжидания("ПроверитьСтатусЗадания", 2);
КонецПроцедуры
&НаСервере
Функция ЗапуститьФоновоеЗаданиеНаСервере(ПараметрыЗадания)
Возврат ФоновыеЗадания.Выполнить(
"ОбработкаОтчётов.СформироватьОтчёт",
ПараметрыЗадания,
Новый УникальныйИдентификатор,
"Формирование отчёта за период");
КонецФункции
Практические советы по архитектуре 1С-решений в 2026 году
За годы работы с 1С накопился список принципов, которые работают независимо от конфигурации и размера проекта. Делюсь без купюр.
Принцип 1: Не доверяй платформе то, что можешь проконтролировать сам. Управляемые блокировки вместо автоматических. Явные транзакции вместо неявных. Контролируемые фоновые задания вместо «само как-нибудь».
Принцип 2: Измеряй, прежде чем оптимизировать. Технологический журнал, счётчики производительности, APDEX. Без измерений оптимизация — это гадание на кофейной гуще.
Принцип 3: Бизнес-логика — на сервере, интерфейс — на клиенте. Директива &НаСервере для всего, что работает с данными. Директива &НаКлиенте только для UI. Никакой бизнес-логики в клиентских процедурах.
Принцип 4: Запросы — только в одном месте. Не пишите запросы в обработчиках форм. Выносите в общие модули — это и тестируемость, и повторное использование.
Принцип 5: Регламентные задания — с умом. Я считаю, что если регламентное задание выполняется дольше часа — это уже сигнал тревоги. Либо оно делает слишком много, либо делает это неэффективно. Разбивайте на части, добавляйте прогресс, логируйте результаты.
И последнее — документируйте нестандартные решения. Через год вы или ваш коллега откроете этот код и не поймёте, почему здесь стоит именно такая блокировка. Три строки комментария сэкономят часы разбирательств.
Итог: платформа 1С:Предприятие 8 — это инструмент, а не магия
1С:Предприятие 8 — это мощная платформа с богатой историей и огромной экосистемой. Она умеет работать быстро, надёжно и масштабируемо. Но только если вы понимаете, как она устроена.
Большинство проблем с производительностью — не в железе и не в платформе. Они в коде. В неоптимальных запросах, в неправильно настроенных блокировках, в архитектурных решениях, принятых «на скорую руку» и оставшихся в продакшене на годы.
Хорошая новость: всё это решаемо. Нужны знания, опыт и правильный инструментарий.
Если вам нужен опытный разработчик 1С для оптимизации, внедрения или решения конкретной технической задачи — загляните на koderion.ru. Это биржа специалистов 1С, где можно найти проверенного разработчика под конкретную задачу: от оптимизации запросов до полного внедрения 1С:ERP. Без лишних посредников, с реальными отзывами и портфолио.