Когда в системе возникают проблемы с производительностью, специалисты начинают искать причины в коде, инфраструктуре или настройках платформы. Однако на практике многие часы диагностики уходят на проверку гипотез, которые изначально основаны на неверных представлениях о работе 1С.
По мотивам доклада Антона Дорошкевича разбираем пять распространенных мифа о платформе 1С.
Антон Дорошкевич
Руководитель проектов, ИнфоСофт
Выступил на INFOSTART TECH EVENT 2025 с докладом «Суеверия и фантомы платформы 1С», где разобрал распространённые мифы, с которыми регулярно сталкиваются администраторы, архитекторы и специалисты сопровождения.
Некоторые выводы оказались неожиданными и вызвали активное обсуждение.
После изменения оборудования лицензия продолжит работать еще сутки
Среди администраторов давно существует убеждение, что после изменения параметров сервера программная лицензия гарантированно будет работать еще 24 часа.
Такое мнение появилось не на пустом месте. В документации действительно указано, что ключевые параметры компьютера опрашиваются не чаще одного раза в сутки. Многие интерпретируют это как своеобразный «льготный период» после изменения конфигурации оборудования.
Однако на практике все не так однозначно.
Если в процессе работы изменяется один из значимых параметров сервера, лицензия может потребовать повторной активации значительно раньше, чем ожидают специалисты. Поэтому любые работы, связанные с модернизацией оборудования, переносом виртуальных машин или изменением конфигурации серверов, стоит планировать с учетом возможной переактивации лицензий.
Если загрузка процессора низкая, значит проблем с производительностью нет
Еще один популярный сценарий знаком многим специалистам.
Пользователи жалуются на медленную работу системы, а администраторы показывают мониторинг серверов:
- процессор загружен на 20–30%;
- памяти достаточно;
- сеть работает нормально.
На первый взгляд проблема отсутствует.
Однако есть показатель, который часто остается без внимания – очередь к процессору и время отклика сервисов.
В рамках доклада был показан фрагмент технологического журнала, где загрузка CPU оставалась относительно невысокой, но при этом среднее время отклика превышало 11 секунд. Пользователь в такой ситуации видит зависания и задержки, хотя классические показатели мониторинга выглядят вполне благополучно.
Поэтому при анализе производительности важно смотреть не только на загрузку оборудования, но и на показатели очередей, доступной производительности и данные технологического журнала. Именно они зачастую помогают увидеть проблему, которую не показывают стандартные графики мониторинга.
Если требование назначения создано, значит оно уже работает
Требования назначения (ТНФ) давно стали привычным инструментом настройки кластеров 1С. Но вокруг них существует еще один распространенный фантом.
Многие считают, что после создания требования назначения и нажатия кнопки «Применить» настройка сразу начинает работать.
В докладе был разобран пример с сервисом DataAcceleratorService, который показал, что между понятиями «создано» и «применено» может существовать существенная разница.
Внешне все выглядит корректно: требование назначения присутствует в настройках кластера, ошибок нет, администратор уверен, что изменения вступили в силу. Однако при детальном анализе оказывается, что фактически кластер продолжает работать по прежней схеме.
Именно поэтому при диагностике проблем с распределением сервисов недостаточно проверить наличие ТНФ в консоли администрирования. Без проверки фактического применения настроек подобные ситуации могут привести к долгому и бесполезному поиску причин проблемы.
Рост памяти RPHOST означает утечку
Пожалуй, самый живучий миф в мире 1С связан с рабочими процессами RPHOST.
Если процесс постепенно увеличивает объем потребляемой памяти, большинство специалистов автоматически ставят диагноз «утечка памяти».
Однако докладчик подробно показал, почему такая интерпретация далеко не всегда верна.
Память внутри процесса работает не по принципу «освободил – вернул операционной системе». Когда пользователь завершает работу или освобождаются какие-либо объекты, внутри процесса действительно появляются свободные области памяти. Но сам процесс при этом не обязан уменьшаться в размерах.
Представим, что один пользователь занял часть памяти, затем вышел из системы. Освободившееся место остается внутри процесса. Если следующий запрос или пользователь сможет поместиться в этот участок памяти, он будет использован повторно. Если нет – процесс запросит дополнительную память у операционной системы и продолжит расти.
При этом память внутри процесса не дефрагментируется, а освобожденные участки нельзя произвольно объединять или перемещать.
Именно поэтому со временем возникает картина, которую многие принимают за утечку: процесс становится все больше и больше, хотя значительная часть памяти внутри него уже многократно переиспользуется.
Особенно показательным оказался пример из практики.
За четыре часа один из рабочих процессов увеличил объем потребляемой памяти до 39 ГБ. На первый взгляд это выглядело как серьезная утечка. Однако анализ технологического журнала показал, что за это время процесс обработал около 940 ГБ данных.
Только за двухчасовой промежуток он переработал порядка 580 ГБ данных, увеличив объем памяти всего на 14 ГБ.
По сути, процесс десятки раз переиспользовал уже выделенную память, а рост был связан с особенностями работы аллокатора памяти и фрагментацией, а не с ошибкой платформы.
Отсюда следует еще один важный вывод: регулярный перезапуск рабочих процессов – это не борьба с утечками памяти, а штатный механизм поддержания производительности и контроля накопленной фрагментации.
Полнотекстовый поиск всегда помогает пользователям находить нужные данные
Большинство пользователей воспринимают его буквально: если поиск называется полнотекстовым, значит он должен находить совпадения по любой части слова.
Однако документация платформы говорит об обратном: полнотекстовый поиск выполняется с начала слова.
Чтобы проверить это на практике, был проведен небольшой эксперимент.
В справочнике были созданы элементы со словом «цемент» в разных вариантах написания:
- «Новосибирск-цемент»;
- «СибЦемент»;
- «Сиб-цемент»;
- другие варианты написания с дефисами и заглавными буквами.
После этого выполнялся поиск по фрагменту «мент».
Обычный поиск через СУБД без проблем находил все совпадения.
Полнотекстовый поиск показал совершенно другую картину.
В первой версии полнотекстового поиска нашлась только часть записей. Во второй версии результаты оказались иными. Некоторые элементы обнаруживались только благодаря использованию заглавных букв, другие не находились вовсе.
Получилась парадоксальная ситуация: пользователь знает, что данные существуют, видит их в системе, но поиск их не возвращает.
Именно эта нерелевантность результатов является основной проблемой полнотекстового поиска. Когда система находит не все подходящие данные, пользователь начинает терять доверие к инструменту.
В качестве альтернативы следует использовать поиск по конкретным полям (Alt+F). Такой механизм лучше использует возможности СУБД, позволяет искать по нужным колонкам и зачастую работает быстрее и предсказуемее.
Кроме того, в современных версиях платформы разработчики могут программно управлять отображением стандартной строки поиска через расширения, не вмешиваясь в типовую конфигурацию.
Самая дорогая ошибка — искать проблему не там
Многие проблемы производительности возникают не из-за ошибок платформы, а из-за неверных представлений о том, как она работает.
«Утечка памяти», которой нет.
«Примененная настройка», которая фактически не работает.
«Низкая нагрузка», при которой пользователи ждут ответа системы по 10–15 секунд.
«Полнотекстовый поиск», который не находит нужные данные.
Такие заблуждения могут стоить компаниям гораздо дороже, чем реальные технические проблемы. Команды тратят время на поиск причин там, где их нет, а настоящие источники сбоев остаются незамеченными.
Именно поэтому особый интерес вызывают доклады, основанные не на теории, а на реальном опыте диагностики, эксплуатации и расследования сложных инцидентов.
Подобные технические разборы традиционно становятся частью программы INFOSTART TECH EVENT. Здесь обсуждают не только новые возможности платформы, но и реальные механизмы ее работы, особенности производительности, архитектурные решения и практические кейсы, с которыми специалисты сталкиваются каждый день.
Если вам интересны вопросы производительности 1С, внутреннего устройства платформы и современные подходы к диагностике сложных проблем, следите за программой INFOSTART TECH EVENT 2026.
8-10 октября, Санкт-Петербург
Время принять решение
С 1 июля стоимость участия вырастет. Успейте приобрести билет на TECH EVENT 2026 по текущей цене
Купить билет
