Медленная работа 1С не всегда означает нехватку ресурсов сервера. Разбираем, почему модернизация без анализа архитектуры может не дать результата.
Автор статьи:
Алена Котова
Руководитель проекта развития 1С:РКЛ, Инфостарт
Это первая статья из серии с подробным разбором частых тем обращений в техническую поддержку 1С РКЛ Инфостарт. Общую картину по запросам в корпоративную поддержку собрали в обзорной статье «Корпоративная поддержка 1С:РКЛ: с какими проблемами заказчики обращаются чаще всего». Здесь остановимся на одном из характерных сценариев: сервер уже обновили, а 1С быстрее не стала.
Любое изменение инфраструктуры в идеале опирается на анализ объективных данных, а не на предположения. В противном случае значительные средства в модернизацию могут не принести ожидаемого результата.
Практика показывает, что больший эффект дает не столько покупка нового сервера, сколько последовательный анализ архитектуры системы и устранение реальных ограничений производительности. Такой подход позволяет добиться устойчивого результата и избежать повторного возникновения проблемы.
Производительность 1С – это не только вопрос оборудования
Когда пользователи начинают замечать, что документы открываются медленнее, отчеты формируются дольше обычного или возрастает время отклика системы, первое предположение часто связано с нехваткой вычислительных ресурсов. Система стала работать медленнее? Значит, сервер уже не справляется с нагрузкой.
В некоторых случаях это и правда так. Но далеко не всегда.
Производительность 1С зависит от множества взаимосвязанных компонентов: сервера приложений, СУБД, дисковой подсистемы, конфигурации кластера, особенностей распределения нагрузки и даже режима выполнения регламентных заданий. Ограничение может возникнуть на любом из этих уровней, поэтому увеличение вычислительной мощности не всегда приводит к заметному ускорению работы.
Именно поэтому перед модернизацией инфраструктуры важно определить, какой компонент действительно влияет на производительность системы.
Куда смотреть после графика загрузки процессора
При поиске причин медленной работы часто начинают с мониторинга сервера. Это логично, ведь показатели процессора, памяти и дисковой подсистемы позволяют быстро понять общее состояние инфраструктуры.
Однако сами по себе они редко дают полный ответ.
Например, средняя загрузка процессора может составлять всего 30-40%, но при этом отдельные ядра работают с максимальной нагрузкой. Или наоборот: процессоры свободны, а пользователи продолжают ждать открытия документов из-за длительных ожиданий на стороне СУБД или дисковой подсистемы.
Поэтому оценивать производительность только по одному показателю недостаточно. Более полезно рассматривать всю цепочку обработки операций от клиента 1С до сервера приложений, базы данных и системы хранения.
Из практики: модернизация сервера не изменила ситуацию
В одном из проектов заказчик обратился уже после обновления инфраструктуры. Компания установила новый двухпроцессорный сервер, увеличила объем оперативной памяти и перенесла базу данных на производительные NVMe-накопители. Ожидалось, что этого будет достаточно для устранения задержек при работе пользователей.
После модернизации жалоб действительно стало немного меньше, однако в часы пик система продолжала работать медленно.
Анализ показал, что вычислительных ресурсов серверу хватало с большим запасом. Ограничение возникало из-за неравномерного распределения рабочих процессов между NUMA-узлами. Один процессор был значительно загружен, тогда как второй использовался лишь частично.
После корректировки настроек кластера и распределения рабочих процессов производительность выросла без каких-либо дополнительных изменений оборудования.
Сам по себе новый сервер не был ошибочным решением. Но основной фактор, который ограничивал производительность, находился в настройках использования имеющихся ресурсов.
Какие области имеет смысл проверить в первую очередь
Когда производительность снижается постепенно или проблема проявляется только в определенные периоды, наиболее эффективным оказывается не полный аудит всех компонентов сразу, а последовательная проверка тех участков системы, которые чаще всего становятся источником ограничений.
Обычно начинают с нескольких направлений:
- загрузка процессоров (общая загрузка CPU, равномерность распределения нагрузки, использование отдельных ядер, влияние NUMA, работа рабочих процессов 1С);
- дисковая подсистема (длина очереди дисков, задержки чтения и записи, нагрузка на журналы транзакций, размещение файлов базы данных, работа TempDB);
- СУБД (актуальность статистик, обслуживание индексов, длительные запросы, планы выполнения, блокировки, ожидания, регламент обслуживания базы);
- кластер серверов 1С (настройки кластера, количество рабочих процессов, распределение сервисов, использование памяти, выполнение фоновых заданий, журналы платформы)
- поведение пользователей (одновременно запускаются тяжелые регламентные задания,
выполняются массовые перепроведения документов, работают ресурсоемкие отчеты, запускаются сложные обработки в рабочее время).
Такой подход позволяет сосредоточиться на действительно значимых факторах и не тратить время на анализ компонентов, которые не влияют на текущую проблему.
Из практики: проблема оказалась не в SQL Server
В другом проекте пользователи отмечали, что система начинает заметно замедляться ежедневно примерно в одно и то же время. Первоначально предполагалось, что причиной является недостаточная производительность SQL Server.
После анализа выяснилось, что несколько крупных информационных баз одновременно использовали одну дисковую группу. В часы пик возрастало количество операций чтения и записи, что приводило к увеличению времени отклика всех информационных баз.
После перераспределения нагрузки и корректировки размещения файлов базы данных ситуация стабилизировалась.
В этом случае изменения коснулись не СУБД как таковой, а архитектуры хранения данных.
Из практики: высокая загрузка процессора оказалась следствием
Еще в одном обследовании основной проблемой считалась постоянно высокая загрузка процессоров. Казалось очевидным, что серверу не хватает вычислительной мощности.
Однако детальный анализ показал, что значительная часть ресурсов расходовалась на выполнение нескольких тяжелых запросов, планы которых перестали быть оптимальными после изменения структуры данных. Дополнительно требовалось обновление статистик и обслуживание индексов.
После корректировки регламентов обслуживания базы данных и анализа наиболее ресурсоемких запросов нагрузка на процессоры снизилась без каких-либо изменений аппаратной части.
Этот пример хорошо показывает, что высокая загрузка оборудования не всегда является причиной проблемы, иногда она становится ее следствием.
Когда модернизация действительно необходима
Безусловно, существуют ситуации, когда дальнейшее развитие системы невозможно без обновления инфраструктуры. Рост количества пользователей, увеличение объема данных или переход на новые сценарии работы могут потребовать более производительного оборудования.
Но решение о модернизации проще принимать тогда, когда понятно, какой именно ресурс достиг своего предела.
Практика показывает, что во многих случаях предварительный анализ ключевых компонентов позволяет либо подтвердить необходимость обновления инфраструктуры, либо выявить другие факторы, которые оказывают большее влияние на производительность.
Вместо заключения
За годы работы с высоконагруженными системами мы не встречали двух абсолютно одинаковых причин снижения производительности.
Именно поэтому универсального ответа на вопрос «Почему тормозит 1С?» не существует.
Наиболее устойчивый результат дает подход, при котором решения принимаются на основе объективных данных и анализа тех компонентов системы, которые действительно влияют на производительность. Это позволяет сосредоточить усилия на устранении реальных ограничений, избежать лишних изменений инфраструктуры и получить ожидаемый эффект от дальнейшего развития системы.
