Администрирование · 13 мин
Как проверить скорость работы 1С
Как проверить скорость работы 1С: замеры времени операций, счётчики производительности, тест Гилёва, анализ СУБД и сети. Пошаговая диагностика тормозов 1С.
Медленная работа 1С — одна из самых частых жалоб бухгалтеров и менеджеров, но «тормозит» — слишком расплывчатая формулировка, чтобы по ней искать причину. Прежде чем менять сервер или докупать лицензии, нужно измерить производительность конкретными способами: замерить время типовых операций, проверить загрузку сервера и СУБД, оценить сеть и дисковую подсистему. Только после этого можно понять, где узкое место — в конфигурации, оборудовании или настройках.
Проверка скорости 1С сводится к трём уровням: клиентское рабочее место, сервер 1С и сервер базы данных (если база клиент-серверная). На каждом уровне есть свои инструменты и свои типичные проблемы. Ниже разобраны практические методы диагностики — от простого замера секундомером до технологического журнала и счётчиков производительности.
Что именно нужно измерять: метрики скорости 1С
Разговор о скорости имеет смысл, только когда есть конкретные цифры. Выберите 5–10 типовых операций, которые пользователи выполняют чаще всего: открытие списка документов, проведение реализации, формирование оборотно-сальдовой ведомости, запуск программы, запись элемента справочника. Для каждой операции замерьте время выполнения секундомером или встроенным замером — от нажатия кнопки до появления результата.
Сделайте замеры в разное время суток и на разных рабочих местах. Если одна и та же операция у бухгалтера занимает 2 секунды, а у менеджера в другом офисе — 20, проблема почти наверняка в сети или клиентском месте, а не в самой базе. Если операция медленная у всех и всегда — ищите причину на сервере или в конфигурации.
Полезно зафиксировать базовые значения («базлайн») в спокойный период, чтобы потом сравнивать с ними при жалобах. Без исходных цифр невозможно понять, стало ли хуже после обновления конфигурации или роста базы.
Проверить загрузку CPU, RAM и дисков сервера 1С и СУБД
Проверить ПК, антивирус, канал связи до сервера
Снять замер длительных запросов через технологический журнал
Снять счётчики производительности в период пиковой нагрузки
Быстрый замер скорости операций вручную
Самый простой способ — замерить время выполнения ключевых операций вручную. Откройте типовой документ, проведите его, сформируйте стандартный отчёт за месяц и запишите время каждого действия. Повторите замер 3–5 раз и возьмите среднее: первый запуск часто медленнее из-за прогрева кэша, и он искажает картину.
Для более точного замера внутри конфигурации используйте встроенные средства: в режиме предприятия многие типовые конфигурации содержат обработки оценки производительности, а разработчик может применить функции замера времени через ТекущаяУниверсальнаяДатаВМиллисекундах() в начале и конце участка кода. Это даёт точность до миллисекунд и позволяет локализовать медленный участок алгоритма.
- 1Выберите 5–10 типовых операций и зафиксируйте их список
- 2Замерьте время каждой операции 3–5 раз, отбросьте первый (холодный) запуск
- 3Повторите замеры на другом компьютере и в другое время суток
- 4Сравните результаты между пользователями и периодами
- 5Запишите средние значения как базовую точку для будущих сравнений
Тест производительности Гилёва
Общеизвестный способ оценить «сырую» производительность сервера или рабочей станции для 1С — тест Гилёва (TPC-1C). Это бесплатная обработка, которая выполняет серию типовых операций с данными и выдаёт условный балл. Чем выше балл, тем быстрее машина справляется с однопоточной нагрузкой, характерной для 1С.
Тест полезен для сравнения: запустите его на сервере и на проблемном клиентском ПК. Если на сервере балл в разы выше, чем на компьютере пользователя, при файловом режиме работы именно слабое клиентское место может быть причиной тормозов. При клиент-серверном режиме низкий балл сервера указывает на нехватку частоты процессора или медленные диски.
Важно понимать ограничения теста: он оценивает преимущественно однопоточную производительность и не учитывает особенности вашей конфигурации и объёма базы. Высокий балл не гарантирует, что конкретный отчёт будет формироваться быстро, — это лишь индикатор общего уровня железа.
Анализ загрузки сервера и клиентского ПК
Пока пользователь выполняет «тормозящую» операцию, откройте диспетчер задач на сервере (или на клиенте при файловой базе) и наблюдайте за загрузкой процессора, памяти и диска. Устойчивая загрузка CPU одного ядра на 100% при простаивающих остальных — типичная картина для 1С: многие операции выполняются в один поток, и здесь решает частота ядра, а не их количество.
Дисковая подсистема — второй частый виновник. Если диск загружен на 100% при умеренной нагрузке на процессор, а время отклика диска (в диспетчере задач или через Performance Monitor) исчисляется десятками миллисекунд, базе не хватает быстрого хранилища. Для файловых баз на сетевом диске дополнительно проверьте пропускную способность сети: копирование большого файла с сервера на клиент покажет реальную скорость канала.
На клиентском компьютере обратите внимание на антивирус: проверка файлов базы и каталогов 1С в реальном времени способна замедлить работу в разы. Добавление каталогов 1С и файлов базы в исключения антивируса — стандартная и безопасная при корректной настройке мера, но согласуйте её с политикой информационной безопасности организации.
Как проверить результат
Ниже 70–80% суммарно, отдельные ядра пиково до 100%
Все ядра постоянно под 100%, очередь процессов растёт
Единицы миллисекунд
Десятки и сотни миллисекунд, диск занят на 100%
Есть запас, файл подкачки почти не используется
Память заполнена, активный свопинг
Канал близок к заявленному, задержки малы
Реальная скорость в разы ниже, потери пакетов
Диагностика клиент-серверного варианта: СУБД и технологический журнал
В клиент-серверном режиме большинство тяжёлых операций выполняет СУБД (MS SQL Server, PostgreSQL и другие). Основной инструмент поиска медленных запросов — технологический журнал сервера 1С. Включите в настройках журнала (файл logcfg.xml) сбор событий DBMSSQL или DBPOSTGRS с длительностью, и вы получите список запросов, которые выполняются дольше заданного порога, с текстом запроса и контекстом.
Дополнительно собирайте события SDBL и CALL с порогом длительности — они покажут медленные обращения к базе и долгие вызовы на уровне платформы. Анализ журнала обычно показывает несколько «чемпионов» по суммарному времени: именно их оптимизация (индексы, переписывание запроса, изменение алгоритма) даёт основной эффект.
На стороне MS SQL Server полезны стандартные средства: Activity Monitor, динамические административные представления (sys.dm_exec_query_stats) и план выполнения конкретного запроса. Проверьте также регламентные операции СУБД: давно не обновлявшаяся статистика и фрагментированные индексы — классическая причина постепенной деградации скорости по мере роста базы.
Файловый режим: особенности проверки
В файловом режиме вся работа с данными идёт через сетевой доступ к файлу базы, поэтому скорость критически зависит от сети и диска того компьютера, где лежит файл. Проверьте скорость копирования файла базы по сети, задержки (ping до сервера должен быть минимальным и стабильным) и отсутствие потерь пакетов. Работа файловой базы через Wi-Fi или VPN почти всегда означает заметные тормоза.
Размер файла 1Cv8.1CD тоже имеет значение: при росте базы до нескольких гигабайтов файловый режим начинает ощутимо замедляться, особенно при одновременной работе нескольких пользователей. Если замеры показывают, что сеть и диски в порядке, а база продолжает тормозить при росте объёма и числа пользователей, — это объективный сигнал рассмотреть переход на клиент-серверный вариант.
Сравнение вариантов диагностики
Подходит для первичной оценки и фиксации базовых значений; не показывает причину медленной работы
Быстро сравнивает железо между собой; не отражает поведение конкретной конфигурации и базы
Показывают нехватку CPU, RAM, диска или сети; не объясняют, какой запрос виноват
Находит конкретные медленные запросы и вызовы; требует навыков анализа и осторожности в настройке
Типичные ошибки при проверке скорости
Самая частая ошибка — выводы по единичному замеру. Первый запуск операции после перезагрузки или входа в программу всегда медленнее из-за загрузки кэшей; замер нужно повторять несколько раз. Вторая ошибка — проверка «в вакууме»: сервер тестируют ночью без нагрузки, а жалобы возникают днём, когда одновременно работают десятки пользователей и идёт обмен данными.
Третья типичная ошибка — оптимизация вслепую: добавление оперативной памяти или смена дисков без предварительной диагностики. Если узкое место — один тяжёлый запрос в отчёте, никакое железо его не ускорит сколько-нибудь значимо. Сначала замеры и анализ, потом вложения.
Что делать с результатами замеров
После диагностики у вас должна быть картина вида: «операция X занимает N секунд, при этом загружен диск сервера СУБД» или «отчёт тормозит из-за запроса, выполняющегося 40 секунд». Каждому типу находки соответствует своё действие: нехватка ресурсов решается апгрейдом или перераспределением нагрузки, медленные запросы — оптимизацией кода и индексов, сетевые проблемы — настройкой инфраструктуры.
Зафиксируйте результаты и повторите замеры после внесённых изменений — только так можно объективно подтвердить эффект. Если причина в коде конфигурации, а конфигурация типовая и находится на поддержке, учитывайте, что доработки усложнят обновления; взвешивайте выигрыш в скорости и стоимость сопровождения.
Как выбрать действие
Что важно запомнить
Скорость 1С проверяют цифрами: замеры типовых операций, тест железа, счётчики загрузки и технологический журнал. Сначала локализуйте проблему (клиент, сеть, сервер 1С, СУБД, код конфигурации), затем устраняйте именно её — и подтверждайте эффект повторным замером.
Частые вопросы о проверке скорости 1С
Какая скорость работы 1С считается нормальной?
Единых нормативов нет: всё зависит от конфигурации, объёма базы и числа пользователей. Ориентируйтесь на субъективный комфорт пользователей — типовые операции вроде открытия документа обычно должны занимать секунды, а не десятки секунд. Главный критерий — сравнение с вашим же базовым замером: если операция стала выполняться заметно дольше, чем раньше, это повод для диагностики.
Можно ли проверить скорость без прав администратора?
Частично да. Ручные замеры операций и тест Гилёва доступны обычному пользователю. А вот технологический журнал, счётчики сервера и анализ СУБД требуют административного доступа к серверу 1С и серверу баз данных — эти работы выполняет администратор или привлечённый специалист.
Тормозит только один отчёт — это проблема сервера?
Скорее всего, нет. Если остальные операции работают нормально, причина почти всегда в самом отчёте: неоптимальный запрос, отсутствие подходящего индекса или обработка слишком большого объёма данных. Снимите замер через технологический журнал во время формирования отчёта — вы увидите конкретный запрос, который занимает основное время.
Поможет ли увеличение оперативной памяти серверу?
Только если диагностика показала её нехватку: память заполнена, активно используется файл подкачки, СУБД не хватает буферов. Если память свободна, а тормоза вызваны медленным диском или тяжёлым запросом, добавление RAM эффекта не даст. Всегда подтверждайте узкое место замерами до покупки оборудования.
Насколько точен тест Гилёва для оценки реальной работы?
Тест измеряет однопоточную производительность машины на типовых операциях платформы и хорош для сравнения железа между собой. Но он не учитывает вашу конфигурацию, объём данных и параллельную нагрузку, поэтому высокий балл не гарантирует быструю работу конкретной базы. Используйте его как один из инструментов, а не как единственный критерий.
Как часто нужно повторять проверку скорости?
Разумный подход — контрольный замер после значимых событий: обновления конфигурации или платформы, замены оборудования, заметного роста базы, увеличения числа пользователей. Внештатные замеры делаются при появлении жалоб. Регулярное сравнение с базовыми значениями позволяет заметить деградацию до того, как она станет критичной.