Производительность 1С: что нужно проверять в первую очередь

Как проявляется?

• Долгое выполнение операций: загрузка программы, открытие форм, формирование отчетов, различные загрузки-выгрузки, интеграции, регламентные операции, закрытие месяца и т.д.
• Ошибки, возникающие из-за нехватки памяти: высоконагруженный интерфейс, формирование «тяжелых» отчетов, интеграции, регламентные операции, закрытие месяца и т.д.

Что проверять?

• Расход памяти RAM: оптимальный необходимый объем оперативной памяти заранее рассчитать невозможно, можно сделать лишь приблизительный расчет, опираясь на средний расход памяти ОС, сервером приложений 1С, СУБД, клиентскими сессиями и т.д. Калькулятор для расчета можно найти на сайте 1С:ИТС. Но одних расчетов не достаточно, т.к. спрогнозировать поведение пользователей и интенсивность их работ невозможно, здесь лучше закладывать некоторый резерв.
• Загрузка дисковой подсистемы: оптимальные показатели дисков необходимо подбирать в зависимости от применения компонентов системы. Помимо скорости чтения/записи также важны и другие параметры, например, количество операций ввода/вывода (IOPS), время отклика (задержки), объем буфера и др.

Важно понимать, что при нехватке ресурсов необходимо выявить причины. Нехватка ресурсов может быть обусловлена неэффективной работой системы в целом, например: неоптимально выстроенной архитектурой, неоптимальными настройками системы, неэффективными алгоритмами и т.д. При проверке показателей ориентируйтесь на рекомендуемые вендором значения. Их можно найти на сайте 1С:ИТС.

ПРИМЕР ИЗ ПРАКТИКИ ФТО

У одного из клиентов была проблема с высоким потреблением памяти, свыше 90%. Виновниками оказались рабочие процессы кластера, они и потребляли оперативную память в значительной степени. Дополнительная сложность заключалась в огромном количестве баз в кластере. При этом не были определены явные номера сеансов, которые «тормозили» работу системы. Включить сбор всех клиент-серверных вызовов на огромном количестве баз для анализа не предоставлялось возможным из-за ограничений в ресурсах.

Для отказоустойчивой и производительной работы кластер-серверов «1С:Предприятие» предусматривает возможность перезапуска рабочих процессов, однако штатными настройками условия перезапуска были ограничены. В итоге мы решили написать скрипт для плавного перезапуска рабочих процессов при достижении граничного значения потребления памяти. Это позволило обеспечить равномерный перезапуск процессов и эффективное использование памяти.

Типичные проблемы:

• запросы в циклах, неоптимизированные рекурсии;
• избыточность и излишняя сложность в запросах и алгоритмах;
• отсутствие индексов там, где это необходимо;
• неэффективное использование индексов.

Как найти?

• Использовать технологический журнал. Позволит выявить длительные и «тяжелые» запросы, что позволит упростить точечную оптимизацию конфигурации.
• Использовать инструменты для анализа запросов SQL Server Profiler или Extended Events, выбор зависит от потребностей. Позволит выявить и оптимизировать неоптимальную структуру таблиц и индексов.

Важно: иногда «виноват» не ваш код, а типовые обновления конфигурации, которые могут конфликтовать с логикой вашей конфигурации. Из-за этого ранее эффективный код может начать работать медленнее. Мы всегда рекомендуем перед обновлением тестировать производительность на копии базы.

ПРИМЕР ИЗ ПРАКТИКИ ФТО

У одного из клиентов после обновления релиза появилась проблема с открытием различных форм списков. Конфигурация заказчика была значительно кастомизирована. В процессе анализа наша команда выявила, что те формы, с которыми наблюдаются проблемы, были доработаны: в динамических списках присутствовали соединения с таблицами нетиповых объектов, по которым индекс отсутствовал или использовался не оптимально.
Проблема была решена добавлением необходимых индексов и доработкой запросов динамических списков, там где это было необходимо. В результате достигли скорости открытия форм близкой к той, которая была до обновления.

Основные риски:

• фрагментация данных — увеличивает время выполнения запросов на 30-50%;
• неоптимальные настройки (например, размер кэша SQL Server);
• «мусорные» данные: старые документы, дубли, неиспользуемые регистры;
• устаревшая статистика (СУБД выбирает неоптимальный план выполнения).

Экспресс-проверка

• Запустите стандартные утилиты для проверки целостности БД (например, DBCC CHECKDB для MS SQL).
• Оптимизируйте индексы и таблицы (особенно, если база росла хаотично).
• Настройте регламентное обслуживание (очистка временных данных, обновление статистики).

Алгоритм диагностики: с чего начать?

1. Соберите жалобы пользователей — определите самые «болевые точки» (например, «отчёт по продажам грузится 10 минут»).
2. Начните проверку с инфраструктуры — исключите «железные» ограничения.
3. Далее проанализируйте код — даже небольшая оптимизация сложных запросов даёт заметный прирост скорости.
4. Не забывайте про БД — регулярное обслуживание предотвратит 50% типовых проблем (возможно, вам будет интересна наша услуга по поддержке БД)

Совет: для комплексных проблем используйте «1С:Корпоративный инструментальный пакет 8» (1С:КИП) — он поможет собирать и хранить информацию о динамике производительности системы во времени, искать и анализировать узкие места в коде системы, а также может решать ряд других задач.

ПРИМЕР ИЗ ПРАКТИКИ ФТО

Один из клиентов обратился с такой проблемой: пользователи жаловались на долго формирующиеся отчеты, долго открывающиеся формы. При выполнении регламентных заданий наблюдалось общее замедление работы системы. Мы провели анализ и выделили основную проблему всех бед — это проблемой оказались две таблицы общим объемом около 1,5 Тб (нетиповые объекты). Причем данные при работе с таблицами использовались часто без отборов, что в итоге сильно нагружало оперативную память. Клиенту было предложено пересмотреть бизнес-процессы, связанные с этими объектами. Для исправления ситуации был предложен следующий подход: ненужные данные в самих таблицах удалить, создать регламент по очистке старых данных и в объектах, использующих эти таблицы, ограничить выборки. После одобрения все работы были выполнены, производительность выросла примерно в 2,5 раза, клиент остался доволен.

Как избежать проблем в будущем?

• Внедрите регулярный мониторинг (хотя бы раз в квартал).
• Документируйте изменения — это поможет найти причину новых «тормозов».
• Обучите команду базовому анализу производительности.

Проблемы с производительностью 1С редко имеют одну причину — обычно это комплекс факторов: от устаревшего кода до неправильно распределённой нагрузки на серверы.

Не ждите, пока 1С «упадёт». Проактивная диагностика экономит до 70% бюджета на экстренные исправления.

Системный подход вместо точечных исправлений.

Проблемы с производительностью 1С редко имеют одну причину — обычно это комплекс факторов, а оптимизация 1С — не разовая процедура, а процесс.

Если внутренних ресурсов для глубокой диагностики не хватает, мы рекомендуем привлечь внешних экспертов. Ошибки на этапе анализа могут привести к неэффективным затратам (например, покупке ненужного оборудования).