При работе в клиент-серверном варианте 1С:Предприятия пользователи часто сталкиваются с проблемой «подтормаживания» системы при формировании тяжелых отчетов или проведении документов. Если при этом открыть системный монитор производительности СУБД, можно обнаружить, что дисковая подсистема (особенно если используется традиционный жесткий диск HDD) загружена на 100%. Мы разберем по шагам, поможет ли перенос файлов базы данных PostgreSQL на твердотельный накопитель (SSD), какие еще сопутствующие настройки необходимо выполнить на уровне СУБД и сервера приложений 1С, чтобы выжать максимум производительности из вашего оборудования.
Для начала проанализируем ситуацию, почему обычный жесткий диск испытывает колоссальные перегрузки при работе с PostgreSQL. СУБД по умолчанию проектируются с расчетом на максимальную сохранность данных. При транзакционной нагрузке критически важными параметрами СУБД являются fsync и full_page_writes. Когда эти параметры включены (что является стандартом для рабочих баз данных), СУБД после каждой транзакции принудительно заставляет дисковый контроллер сбрасывать кэш на физический накопитель.
Для классического HDD с механическими головками это означает постоянное позиционирование на разные участки диска, из-за чего скорость случайной записи падает до критически низких значений. Ситуация усугубляется, когда на одном физическом диске установлена операционная система, запущен сервер 1С:Предприятия со своими временными файлами, крутится служба PostgreSQL и лежат сами файлы баз данных. Такая конфигурация нарушает базовое правило системного администрирования: база данных должна располагаться отдельно от операционной системы и файлов подкачки.
Перенос файлов базы данных на SSD действительно является самым простым и в то же время наиболее эффективным способом решения проблемы «бутылочного горлышка» дисковой подсистемы. Скорость обработки случайных запросов блоками по 4 Кб на SSD в десятки и сотни раз выше, чем на HDD. Однако при переходе на твердотельные накопители важно учитывать несколько нюансов:
Многие ошибочно полагают, что достаточно перенести только СУБД. Однако сам сервер 1С:Предприятия создает огромную нагрузку на дисковую подсистему. Интенсивную запись генерирует технологический журнал (если он включен) и, самое главное, журнал регистрации. В современных версиях платформы 1С журнал регистрации хранится в формате SQLite, который крайне чувствителен к скорости случайного доступа.
Чтобы перенести служебные файлы кластера 1С (включая журнал регистрации и кэш) на быстрый диск SSD, нам потребуется отредактировать параметры запуска службы ragent. Для этого используется специальный ключ -d.
Рассмотрим по шагам, как перенести общие данные кластера:
"C:\Program Files\1cv8\8.3.22.1709\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo"
-d на каталог, расположенный на вашем новом быстром SSD-диске:
"C:\Program Files\1cv8\8.3.22.1709\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "D:\1C_ClusterData"
srvinfo в новый каталог на диске D, после чего запустите службу заново.Иногда даже после перехода на SSD отчеты могут продолжать подтормаживать. Проанализируем специфику работы конфигурации «Бухгалтерия государственного учреждения 1.0». В отличие от более новых решений, в БГУ 1.0 отсутствует автоматический сдвиг границы расчета итогов.
Если пользователи формируют отчеты за текущие периоды, а итоги рассчитаны на дату полугодичной или годичной давности, то сервер СУБД вынужден каждый раз динамически просчитывать все движения по регистрам, начиная с даты последних рассчитанных итогов до даты отчета. Для PostgreSQL это выливается в необходимость полного сканирования огромных таблиц итогов ЕПСБУ.
Решение: регулярно выполняйте операцию пересчета и установки актуальной границы итогов через монопольный режим в режиме «1С:Предприятие» или через управление итогами в конфигураторе.
Также стоит упомянуть проблему оптимизатора PostgreSQL, связанную со сложными запросами с соединениями (JOIN) и подзапросами. В некоторых релизах БГУ (например, при заполнении документов инвентаризации) система может зависать. В этом случае помогает временное отключение использования вложенных циклов оптимизатора. Для этого в файле настроек postgresql.conf установите параметр:
enable_nestloop = off
Обратите внимание: отключение этого параметра является крайней мерой и может как ускорить выполнение специфических отчетов 1С, так и замедлить другие стандартные операции, поэтому данную настройку следует тщательно тестировать на конкретной базе данных.
Помимо физического переноса данных, обязательно скорректируйте ключевые параметры производительности в конфигурационном файле СУБД:
2GB. Это позволит наиболее часто запрашиваемые индексы и таблицы держать непосредственно в оперативной памяти.64MB или 128MB. Тяжелые отчёты 1С перестанут активно использовать медленный диск для промежуточных вычислений.В отличие от СУБД MS SQL, PostgreSQL использует механизм многоверсионности строк (MVCC). Это означает, что при изменении или удалении записей в базе физически строки не удаляются, а лишь помечаются как неактивные. Со временем база «раздувается» (эффект bloat), что приводит к существенному замедлению чтения таблиц даже на SSD-накопителях.
Для борьбы с этим эффектом настройте регулярное выполнение регламентных процедур СУБД:
ANALYZE для обновления статистики оптимизатора запросов.VACUUM (или VACUUM FULL в периоды наименьшей активности пользователей).REINDEX) наиболее нагруженных таблиц базы данных 1С.Выполнение этих комплексных мер гарантирует стабильную, быструю и отзывчивую работу ваших прикладных решений 1С:Предприятия под управлением PostgreSQL.