Администрирование · 11 мин
Как проверить производительность 1С: пошаговая инструкция
Как проверить производительность 1С: замеры времени операций, технологический журнал, ЦУП, APDEX, типичные узкие места и способы ускорения работы базы.
Медленная работа 1С почти всегда имеет конкретную причину: неоптимальный запрос, блокировки, перегруженный сервер СУБД или слабый диск. Проверка производительности начинается не с покупки оборудования, а с измерения — пока вы не знаете, где именно теряется время, любые действия будут гаданием.
В платформе 1С:Предприятие 8.3 есть встроенные инструменты диагностики: замеры производительности в конфигураторе, технологический журнал, счётчики в консоли кластера. Для комплексной оценки используется отраслевой стандарт APDEX и решение Центр управления производительностью (ЦУП). Этого набора достаточно, чтобы локализовать проблему на уровне конкретной операции, запроса или регламента.
Важно понимать: «тормозит 1С» — это симптом, а не диагноз. За ним может стоять как клиентская часть (слабый ПК бухгалтера, антивирус), так и серверная (СУБД, дисковая подсистема, сеть). Правильная проверка разделяет эти слои и измеряет каждый по отдельности.
Что измерять: ключевые показатели производительности
Прежде чем запускать инструменты, определите, что считать проблемой. Практика показывает, что пользователи начинают жаловаться, когда типовая операция (проведение документа, открытие отчёта) занимает больше 3–5 секунд, а целевое время для массовых операций — до 1–2 секунд. Это ориентиры, а не жёсткие нормы: для тяжёлых сводных отчётов допустимо и больше.
Основной количественный показатель — APDEX (Application Performance Index). Он показывает долю операций, уложившихся в целевое время, и выражается числом от 0 до 1. Значение ниже примерно 0,7 обычно означает, что пользователи систематически испытывают задержки. APDEX собирается автоматически решением ЦУП либо вычисляется по данным технологического журнала.
На уровне сервера отслеживайте загрузку CPU, очередь диска, свободную оперативную память и сетевые задержки между сервером 1С и сервером СУБД. Если 1С и СУБД разнесены на разные машины, пинг между ними должен быть минимальным — задержки даже в несколько миллисекунд заметно замедляют работу из-за большого количества мелких обращений к базе.
Быстрая проверка со стороны пользователя
Первый шаг не требует никаких настроек сервера. Замерьте секундомером время выполнения типовых операций на рабочем месте пользователя: открытие программы, проведение документа, формирование основного отчёта, поиск по справочнику. Повторите каждую операцию 3–5 раз и зафиксируйте среднее время — единичные замеры искажаются кэшированием.
Сравните результаты на разных компьютерах и под разными пользователями. Если медленно только у одного сотрудника — проблема в его ПК, сети до него или правах (RLS может сильно замедлять запросы для отдельных ролей). Если медленно у всех — смотрите на сервер.
Полезный приём — запустить ту же базу в файловом варианте на мощной машине с локальной копией. Если операции выполняются быстро, значит, конфигурация сама по себе не является узким местом, и искать нужно в серверной инфраструктуре: СУБД, сети, блокировках.
- 1Выберите 3–5 типовых операций: проведение документа, отчёт, открытие списка
- 2Замерьте время каждой операции 3–5 раз, запишите среднее
- 3Повторите замеры на другом компьютере и под другим пользователем
- 4Сравните: если разница между клиентами большая — проблема локальная, если одинаково — серверная
- 5Зафиксируйте результаты как точку отсчёта до любых изменений
Замеры производительности в конфигураторе
Для разработчиков и администраторов с доступом к конфигуратору базовый инструмент — замер производительности. Он запускается через меню «Отладка — Замер производительности» и показывает, сколько времени заняла каждая строка кода и каждый вызов процедуры, включая время выполнения запросов.
Сценарий работы: включите замер, выполните в клиенте «медленную» операцию, остановите замер и изучите отчёт. Сортируйте по колонке времени — обычно 80% времени съедают 2–3 вызова. Если наверху запрос к СУБД — проблема в запросе или индексах; если собственный код — в алгоритме (например, запрос внутри цикла).
Типичная находка на этом этапе — запросы в цикле и обращения к базе через точку от ссылки («разыменование») вместо одного запроса с соединениями. Такие места исправляются на уровне конфигурации и дают ускорение в разы без какого-либо апгрейда железа.
Замер производительности включайте только на время диагностики и только на тестовой копии или в непиковые часы: он замедляет выполнение кода и искажает реальную картину абсолютного времени, хотя относительную раскладку по строкам показывает верно.
Технологический журнал: сбор долгих операций и блокировок
Технологический журнал (ТЖ) — главный инструмент диагностики на сервере. Он настраивается файлом logcfg.xml в каталоге conf сервера 1С и позволяет фиксировать события: длительные запросы к СУБД (DBMSSQL, DBPOSTGRS, DBORACLE), взаимоблокировки (TDEADLOCK), ожидания на блокировках (TLOCK, TTIMEOUT), долгие вызовы сервера (CALL, EXCP).
Минимальный рабочий конфиг — собирать события DBMSSQL с длительностью и события блокировок. После сбора журналов за несколько часов работы пользователей проанализируйте их: какие запросы выполняются дольше всего, какие таблицы участвуют в блокировках, в какое время суток пики.
<config xmlns="http://v8.1c.ru/v8/tech-log"><log location="C:\1clogs" history="24"><event><eq property="name" value="DBMSSQL"/></event><event><eq property="name" value="TDEADLOCK"/></event><event><eq property="name" value="TLOCK"/></event><property name="all"/></log></config>Анализировать текстовые файлы вручную неудобно — используйте бесплатную обработку для разбора ТЖ или консольные средства поиска по ключевым словам Duration. Обращайте внимание не только на самые долгие запросы, но и на самые частые: запрос по 200 мс, выполняемый тысячи раз, вреднее разового отчёта на 10 секунд.
ЦУП и оценка по APDEX
Центр управления производительностью (ЦУП) — готовая конфигурация от фирмы «1С» для постоянного мониторинга. Она подключается к рабочим базам через сервисные обмены, собирает время выполнения ключевых операций и автоматически считает APDEX по каждой операции и по системе в целом.
ЦУП оправдан, когда баз несколько, пользователей много и нужна регулярная картина, а не разовая диагностика. Он показывает деградацию во времени: например, отчёт постепенно замедлялся месяц — значит, дело в росте объёма данных или сбросе статистики СУБД, а не внезапной поломке.
Для небольших внедрений ЦУП может быть избыточен: достаточно периодических замеров и анализа ТЖ. Но саму методику APDEX стоит применять в любом случае — задайте целевое время для каждой ключевой операции и считайте долю нарушений.
Проверка сервера и СУБД
Если клиентские замеры показали серверную проблему, проверьте инфраструктуру. На сервере СУБД смотрите: загрузку процессора, очередь диска (значения выше нескольких единиц — тревожный признак), объём доступной памяти и не уходит ли система в файл подкачки.
Для MS SQL Server полезны штатные отчёты по самым ресурсоёмким запросам и проверка актуальности статистики и фрагментации индексов. Необновлённая статистика — частая причина внезапного замедления: оптимизатор начинает строить плохие планы запросов. Регламентное обновление статистики и перестроение индексов должны выполняться по расписанию.
Отдельно проверьте размещение: сервер 1С и сервер СУБД должны быть в одном быстром сегменте сети, антивирус — с исключениями для каталогов базы и временных файлов. Дисковая подсистема под базу — SSD; размещение базы на медленных HDD или сетевых хранилищах без должной производительности — типичный источник проблем.
Как проверить результат
Стало заметно ниже исходного замера при повторных прогонах
Время не изменилось или колеблется случайно — причина не найдена
Близка к нулю, всплески кратковременны
Постоянно выше нескольких единиц — диск не справляется
Отсутствуют или единичны
Регулярные взаимоблокировки на одних и тех же таблицах
Стабильно выше 0,85
Ниже 0,7 — пользователи систематически ждут
Типичные узкие места и что с ними делать
Долгие запросы без подходящих индексов — лидер среди причин. Диагностируется через ТЖ и план запроса в СУБД; решается добавлением индекса в конфигурации или переписыванием запроса. Самостоятельное добавление индексов напрямую в СУБД в обход конфигуратора — рискованная практика: при обновлении конфигурации возможны конфликты.
Блокировки и взаимоблокировки возникают при одновременной работе пользователей с одними данными и при фоновых регламентах в часы пик. Решения: перевод регистров в режим разделения итогов, включение управляемых блокировок, перенос тяжёлых регламентных заданий на ночь.
Рост базы без свёртки и архивации постепенно замедляет всё. Если база выросла до сотен гигабайт, а регламенты СУБД не выполняются, производительность будет деградировать независимо от железа. Плановая свёртка периодов и выгрузка старых данных — обязательная часть эксплуатации.
Что важно запомнить
Проверка производительности 1С — это измерение, а не догадки: зафиксируйте время операций, соберите технологический журнал, найдите долгие запросы и блокировки, устраните причину и повторите замер. Без «до» и «после» невозможно понять, помогло ли решение.
Частые вопросы
Как понять, что тормозит сервер, а не компьютер пользователя?
Сравните одну и ту же операцию на нескольких рабочих местах. Если медленно у всех пользователей одновременно — причина на сервере или в конфигурации. Если только у одного — проверяйте его ПК, сеть и антивирус. Дополнительный тест — запуск копии базы в файловом варианте на мощной машине.
Какое время выполнения операции считать нормальным?
Жёстких норм нет, но практический ориентир: массовые операции (проведение документа, открытие формы) — до 1–2 секунд, тяжёлые отчёты — до нескольких десятков секунд. Главный критерий — стабильность: резкое ухудшение относительно привычного уровня всегда требует разбора.
Можно ли проверить производительность без доступа к серверу?
Частично. Замеры времени операций, сравнение между клиентами и замер производительности в конфигураторе доступны без серверных прав. Но анализ запросов к СУБД, блокировок и ресурсов сервера требует доступа администратора — без него полную картину получить нельзя.
Опасен ли технологический журнал для рабочей базы?
Сам по себе — нет, но подробный сбор событий создаёт большой объём логов и нагрузку на диск. Включайте только нужные события, ограничивайте глубину хранения и отключайте журнал после диагностики. Следите за свободным местом на диске с логами.
Поможет ли переход на SSD, если 1С тормозит?
Если диагностика показала высокую очередь диска и долгие операции ввода-вывода — да, эффект будет значительным. Если же узкое место в неоптимальных запросах или блокировках, замена диска почти ничего не даст. Поэтому сначала замеры, потом закупка оборудования.
Что делать, если взаимоблокировки повторяются регулярно?
Соберите события TDEADLOCK в технологическом журнале и определите, какие таблицы и операции конфликтуют. Типовые меры: включение управляемого режима блокировок, разделение итогов по регистрам, изменение порядка обращения к данным в коде, разнесение конфликтующих регламентных заданий по времени.