Проблемы с производительностью в тяжелых конфигурациях, таких как 1С:Комплексная автоматизация 2.4 или ERP, часто ставят в тупик даже опытных специалистов. Бывает так, что серверное оборудование кажется мощным, а синтетические тесты показывают неплохие результаты, но пользователи продолжают жаловаться на "тормоза" при подборе товара или расчете скидок. В этой статье мы разберем, как правильно интерпретировать результаты теста Гилева, какие инструменты диагностики использовать и как настроить сервер для максимально быстрой работы.
Рассмотрим один из самых популярных инструментов — Тест Гилева (TPC-1C). Это синтетический тест, который измеряет производительность связки «платформа 1С — СУБД — сервер» в однопоточном режиме. Это критически важный момент: тест показывает, насколько быстро процессор и дисковая подсистема могут обработать одну последовательную задачу.
Проанализируем результаты теста в условных единицах («попугаях»):
Важное замечание: Высокий балл в тесте Гилева (например, 100500, как шутят на форумах) не гарантирует, что форма подбора будет открываться мгновенно. Тест не учитывает блокировки, неэффективные запросы в коде и проблемы многопользовательской работы. Если тест показывает 40 единиц, а подбор тормозит — причину нужно искать не в "железе", а в логике работы программы или настройках СУБД.
Если пользователи жалуются на конкретную операцию, например, ПодборТоваров, первым делом необходимо выяснить, на что именно тратится время. Для этого разберем по шагам методику замера производительности.
Воспользуемся встроенным инструментом Замер производительности в Конфигураторе:
Проанализируем полученную таблицу. Обратите внимание на колонки "Число вызовов" и "Чистое время". Часто в 1С:КА 2.4 проблема кроется в динамическом расчете цен и остатков. Программа пытается в реальном времени рассчитать скидки для каждой строки, отображаемой в списке, что создает колоссальную нагрузку на сервер приложений и базу данных.
Выясним причину, по которой СУБД может "задумываться" при выполнении запросов. Если регламентные операции в SQL не выполняются, производительность будет неизбежно падать. Проанализируем основные настройки:
1. Обновление статистики (Update Statistics). Это самая частая причина деградации производительности. SQL Server строит план выполнения запроса на основе статистики о данных. Если она устарела, сервер выберет неоптимальный путь, и простейший подбор товара может выполняться минуты вместо секунд.
2. Настройка MAXDOP. Параметр Max Degree of Parallelism определяет, сколько ядер процессора может использовать один запрос. Для 1С рекомендуется устанавливать значение 1 (для старых версий) или небольшое число (2–4) для современных многоядерных систем. Значение 0 (использование всех ядер) часто приводит к взаимным блокировкам и "зависанию" всей системы из-за одного тяжелого отчета.
3. Сбор статистики ожиданий. Для глубокого анализа используйте скрипты (например, скрипты Пола Рэндала) для анализа Wait Statistics. Это поможет понять, во что упирается сервер: в чтение с дисков, в нехватку оперативной памяти или в ожидание блокировок от других пользователей.
Разберем ситуацию, когда "у админа всё летает, а у пользователей тормозит". В 1С это классический признак работы механизма RLS (Row Level Security) — ограничение прав на уровне записей.
Когда обычный пользователь открывает подбор, система автоматически добавляет к каждому запросу дополнительные условия, проверяя, имеет ли он право видеть конкретный склад, организацию или контрагента. Эти условия могут превратить простой запрос в огромный код на несколько страниц, который СУБД обрабатывает очень долго. У администратора 1С эти проверки игнорируются, поэтому работа идет быстрее.
Для решения этой проблемы рассмотрим следующие шаги:
Чтобы система работала стабильно, необходимо внедрить обязательный список регламентных работ. Рассмотрим их подробнее:
-- Пример команды для обновления статистики во всей базе
EXEC sp_updatestats;
Помимо обновления статистики, необходимо настроить:
Проанализируем настройки самого сервера. Для 1С критически важен режим "Высокая производительность" (High Performance). Это касается как настроек схемы электропитания в Windows Server, так и настроек в BIOS сервера (отключение C-States, Intel SpeedStep и т.д.). Если процессор постоянно сбрасывает частоту для экономии энергии, 1С будет работать рывками, а тест Гилева покажет низкий результат.
Часто причиной локальных "тормозов" у конкретных пользователей является разросшийся или поврежденный кэш 1С. Выясним, как это исправить:
.mdf, .ldf) и временные файлы сервера 1С.tempdb) SQL-сервера.Подводя итог, можно сказать: производительность подбора в КА 2.4 — это комплексная задача. Начните с замера производительности, чтобы найти "узкое место" в коде, проверьте настройки SQL и обязательно убедитесь, что сервер работает в режиме максимальной мощности. Только после устранения инфраструктурных проблем стоит переходить к оптимизации запросов и кода конфигурации.