Короткий ответ. Если 1С работает на PostgreSQL и стала заметно медленнее, проверять нужно всю цепочку: сервер 1С, саму СУБД, диски, запросы, блокировки, фоновые операции и недавние изменения. У PostgreSQL есть собственные задачи обслуживания: сбор статистики, очистка устаревших версий строк, контроль журналов, резервирование и наблюдение за запросами. В клиент-серверной 1С отдельная СУБД – это ещё один участок инфраструктуры, за который должен отвечать конкретный специалист. Перезапуск сервера может временно изменить картину, но причину повторяющихся задержек по нему не найти. Начинать стоит с фиксации симптома и данных за тот момент, когда пользователи действительно видят проблему.
PostgreSQL уже установили. Кто теперь за ним следит?
После перехода с файловой базы сотрудники часто замечают только одно изменение: раньше база лежала в папке, теперь есть сервер.
Часто PostgreSQL появляется и после ухода с MS SQL: базу перенесли, пользователи работают, а порядок обслуживания новой СУБД так и не описали.
Внутри схема стала сложнее. Платформа 1С работает отдельно, данные хранит PostgreSQL, а рядом остаются операционная система, диски, сеть и резервное копирование. «1С:Предприятие» официально поддерживает PostgreSQL в клиент-серверном режиме и публикует перечень поддерживаемых вариантов и версий СУБД. [1]
Проверьте, знакомы ли вам такие ситуации:
- версия PostgreSQL известна только специалисту, который когда-то настраивал сервер;
- 1С работает нормально большую часть дня, а отдельные операции внезапно занимают минуты;
- после массовой загрузки или закрытия месяца база несколько часов ведёт себя иначе;
- перезапуск сервера стал привычным способом вернуть скорость;
- диск постепенно заполняется, но никто не может объяснить, какие данные растут;
- резервные копии выполняются, а тест восстановления PostgreSQL никто не показывал;
- специалист по 1С говорит, что конфигурация работает штатно, администратор при этом не видит высокой загрузки процессора.
Каждый симптом сам по себе ещё не показывает причину. Полезен тот момент, когда можно сопоставить жалобу пользователя с состоянием сервера и базы данных.
Если у вас пока файловая 1С и вопрос PostgreSQL только рассматривается, сначала стоит прочитать материал про переход от файловой базы к клиент-серверной. В этой статье исходим из того, что PostgreSQL уже используется.
Что вообще приходится администрировать в PostgreSQL
PostgreSQL требует регулярного обслуживания. В официальной документации к таким задачам относятся работа VACUUM, обновление статистики для планировщика, обслуживание журналов и резервное копирование. [2]
В таблице ниже – те же задачи, но с точки зрения компании: что проверяет специалист и какой ответ должен быть у бизнеса.
| Участок | Что проверяет специалист | Что должно быть понятно компании |
|---|---|---|
| Версия и совместимость | Поддерживается ли установленная версия текущей платформой 1С и ОС | Когда систему можно обновлять и кто это согласует |
| Диски и ресурсы | Свободное место, задержки дисковой подсистемы, память, нагрузку | Есть ли запас ресурсов и что является ограничением |
| Соединения и блокировки | Какие сеансы ждут друг друга, есть ли длительные операции | Почему конкретная операция ждала |
| VACUUM и autovacuum | Успевает ли автоматическое обслуживание за изменениями в таблицах | Нет ли накопившейся технической проблемы в базе |
| Статистика планировщика | Актуальны ли данные, по которым PostgreSQL выбирает способ выполнения запросов | Есть ли основания проверять планы медленных операций |
| Запросы | Какие запросы чаще всего или дольше всего занимают ресурсы | С чего начинать оптимизацию |
| Журналы и ошибки | Повторяющиеся ошибки и события за время сбоя | Что происходило в момент жалобы пользователей |
| Копии и восстановление | Что копируется и можно ли получить рабочую базу | До какой точки можно вернуть данные и кто запускает восстановление |
Этот список не означает, что каждую задачу ежедневно выполняют вручную. Часть работы PostgreSQL автоматизирует. Задача администратора – проверить, что автоматика справляется с нагрузкой конкретной базы и что результат контролируется.
Если 1С тормозит, сначала зафиксируйте симптом
«1С медленная» – слишком широкое описание.
Для диагностики лучше ответить на несколько вопросов:
- медленно у одного пользователя или у всего офиса;
- проблема есть постоянно или появляется в определённое время;
- тормозит вход в базу, открытие списка, проведение документа, отчёт или закрытие месяца;
- что происходило перед этим: обновление, загрузка данных, изменение конфигурации, рост числа пользователей;
- как долго выполняется та же операция в обычный день;
- есть ли в это время другие тяжёлые задания или обмены.
Так специалист получает точку, с которой можно сопоставить данные PostgreSQL, сервера 1С и операционной системы.
Низкая загрузка процессора сама по себе не доказывает, что проблемы нет. Пользователь может ждать блокировку, диск, другой запрос или внешнюю систему.
Условный пример. Одна и та же операция стала выполняться заметно дольше. Низкая загрузка процессора сама по себе ничего не объясняет. Если в момент жалобы видно ожидание блокировки, специалист проверяет, какой процесс её создаёт и почему. Без снимка состояния в момент жалобы такая проверка невозможна, а после перезапуска данные уже недоступны.
Где искать причину
Для первого разбора подойдёт такая схема.
| Что происходит | Куда смотреть в первую очередь |
|---|---|
| Одна операция стала резко медленнее | Запрос, блокировки, изменение данных или конфигурации |
| Все пользователи жалуются одновременно | Сервер, диски, СУБД, сеть, фоновые задания |
| Проблема только в конце месяца | Нагрузка, тяжёлые операции, блокировки, состояние базы в этот период |
| После обновления стало хуже | Что обновилось, совместимость версий, изменения конфигурации и окружения |
| После перезапуска временно лучше | Состояние памяти, соединений, фоновых процессов; причину нужно искать до следующего рестарта |
| Постепенно растёт время выполнения одних и тех же операций | Размер данных, статистика, запросы, индексы и обслуживание таблиц |
Дальше поиск сужает технический специалист. Бизнесу не нужно выбирать параметры PostgreSQL по таблице из интернета, но полезно знать, какие данные у специалиста попросить. Ниже по тексту такие вопросы вынесены отдельно.
Как понять, что тормозит: 1С или PostgreSQL
Первая проверка обычно идёт с двух сторон: со стороны PostgreSQL и со стороны сервера 1С.
В PostgreSQL специалист смотрит стандартные представления и журнал:
pg_stat_activity: какие сеансы сейчас выполняются и чего они ждут;pg_locksи функцияpg_blocking_pids: какой сеанс блокирует другой; [9]pg_stat_user_tables: когда по таблицам последний раз работали autovacuum и autoanalyze и сколько в них старых версий строк; [8]pg_stat_statements: какие запросы занимают больше всего времени, если расширение подключено заранее;- журнал сервера PostgreSQL: ошибки и предупреждения за время жалобы.
В 1С проверяют технологический журнал и консоль кластера серверов. Пользователь может ждать управляемую блокировку самой 1С, и тогда PostgreSQL в этот момент выглядит спокойным.
Если ожидание видно в PostgreSQL, разбор продолжают по запросам и состоянию таблиц. Если база в момент жалобы свободна, а операция всё равно ждёт, причину ищут на стороне 1С, сети или внешних обменов.
Что попросить у специалиста. Снимок активных сеансов PostgreSQL в момент жалобы: кто что выполняет и чего ждёт. Если таких данных нет, стоит заранее определить, что фиксировать при следующем повторении проблемы.
Зачем PostgreSQL нужны VACUUM и ANALYZE
После изменения или удаления записей PostgreSQL сохраняет старые версии строк до последующей очистки. Обычный VACUUM освобождает это пространство для повторного использования. [7] В PostgreSQL есть autovacuum, который автоматизирует регулярную работу и включён по умолчанию. Его настройки могут отличаться для отдельных таблиц. [3]
ANALYZE собирает статистику о данных. Планировщик PostgreSQL использует её, чтобы выбрать способ выполнения запроса. При обычной конфигурации autovacuum также запускает автоматический анализ таблиц по мере изменения данных. [4]
Практический вывод: фраза «autovacuum включён» ещё не отвечает на вопрос, успевает ли он обслуживать конкретную нагруженную базу. В крупных и активно изменяемых таблицах отдельно проверяют, успевает ли автоматическое обслуживание за нагрузкой.
Что попросить у специалиста. По нескольким самым крупным таблицам базы: когда последний раз отрабатывали autovacuum и autoanalyze и сколько устаревших версий строк накопилось. Если это не проверяют, такую проверку стоит добавить в регламент обслуживания.
А можно просто запустить VACUUM вручную?
Иногда ручная операция нужна, но использовать её как универсальную кнопку ускорения не стоит.
Особенно аккуратно обращаются с VACUUM FULL: PostgreSQL переписывает таблицу, и такая операция требует эксклюзивной блокировки на время обработки. Для крупной таблицы это означает, что работа с ней в 1С остановится до завершения. Для обычного регулярного обслуживания используется другая логика. [5]
Поэтому совет из чата «сделайте VACUUM FULL и всё станет быстрее» сначала должен пройти через специалиста, который понимает размер базы, рабочее окно и причину проблемы.
Как понять, какие запросы занимают время
PostgreSQL умеет собирать статистику по SQL-запросам. Стандартное расширение pg_stat_statements хранит сведения о планировании и выполнении запросов и позволяет увидеть их вызовы и затраченное время. Для его работы требуется предварительная настройка сервера: расширение подключается заранее, а не в момент жалобы. [6]
Это полезно, когда жалоба звучит конкретно: «Отчёт раньше открывался быстро, последние две недели сотрудники ждут заметно дольше».
Тогда специалист может сопоставить пользовательскую операцию со статистикой запросов и проверить, где расходуется время.
Само наличие «медленного SQL» ещё не назначает виноватого. Источник может находиться в прикладной логике 1С, данных, плане выполнения, состоянии таблицы, ресурсах сервера или нескольких участках сразу.
Что попросить у специалиста. Собирается ли статистика запросов на сервере. Если нет, обсудите со специалистом, нужно ли настроить её заранее для следующей диагностики.
Почему перезапуск мешает диагностике
Когда после рестарта стало быстрее, возникает соблазн считать задачу закрытой.
Но часть диагностических данных уже потеряна или изменилась: исчезли текущие соединения, блокировки, очередь операций, поменялось использование памяти. Следующее повторение начинается почти с нуля.
Если система продолжает обслуживать пользователей, сначала зафиксируйте состояние и только затем согласуйте перезапуск. При аварии приоритетом может быть быстрое восстановление работы, но после него всё равно нужен разбор причины.
В статье «Сколько стоит час простоя 1С» мы отдельно разбираем, почему повторяющиеся короткие задержки тоже стоит учитывать как потери бизнеса. Здесь задача другая – собрать данные, по которым технический специалист найдёт источник.
Версию PostgreSQL нельзя обновлять отдельно от 1С
Перед обновлением СУБД нужно проверить совместимость с используемой версией платформы 1С и операционной системой. Фирма «1С» ведёт отдельный актуальный список поддерживаемых СУБД и выпускает собственную сборку PostgreSQL с патчами для работы с платформой. [1]
Это не единственный вариант: Postgres Professional публикует собственные сборки PostgreSQL для 1С, а также выпускает коммерческие редакции Postgres Pro. У разных дистрибутивов свой цикл обновлений и поддержки, поэтому фиксировать нужно не только номер версии, но и то, какой именно дистрибутив установлен. [10]
План обновления должен включать:
- текущую версию платформы 1С;
- текущую СУБД, её дистрибутив и сборку;
- серверную операционную систему;
- резервную копию и понятный порядок восстановления;
- проверку рабочих операций после изменения.
Если PostgreSQL появился во время недавнего внедрения, порядок обновлений стоит включить в общий план первых месяцев эксплуатации. Это логично связать со статьёй «Что настроить после внедрения 1С: план первых 90 дней».
Резервная копия PostgreSQL должна восстанавливаться
Для PostgreSQL действует тот же критерий, что и для любой резервной копии 1С: файл или архив сам по себе ещё не подтверждает готовность к аварии. Компания должна знать, что именно входит в копию, где она хранится, кто получает сообщение об ошибке, кто запускает восстановление и до какого момента вернутся данные.
Главный вопрос здесь один: когда последний раз из этой схемы получали рабочую базу и открывали её в 1С. Методику тестового восстановления мы подробно разбирали в статье «Как проверить, что бэкап 1С вас спасёт» – здесь её не повторяем.
Кто должен заниматься PostgreSQL
Этот вопрос лучше решить до первой серьёзной проблемы.
Специалист 1С может сопровождать конфигурацию и платформу. Системный администратор может вести сервер и операционную систему. PostgreSQL при этом должен быть закреплён за исполнителем, который понимает СУБД и участвует в диагностике, обслуживании и восстановлении. Распределение зон между франчайзи, хостером и администратором мы разбирали в статье «Кто должен обслуживать сервер 1С»: название подрядчика не определяет объём работ, его определяет договор и фактическая схема обслуживания.
Для PostgreSQL отдельно зафиксируйте:
Дистрибутив и версия СУБД: [дистрибутив, версия] Кто администрирует PostgreSQL: [ответственный + контакт] Кто следит за состоянием сервера: [ответственный] Кто получает уведомления об ошибках: [ответственный] Кто согласует обновление: [ответственный] Кто проверяет резервные копии: [ответственный] Кто выполняет восстановление: [ответственный] Дата последней проверки: [дата]
Пароли в такую карточку не вписывайте.
Что должно остаться после диагностики
Хороший результат диагностики – это больше, чем фраза «подкрутили PostgreSQL».
У компании должен остаться короткий вывод:
- какой симптом проверяли;
- где оказалось основное ограничение;
- какие изменения внесли;
- чем измерили результат после;
- что нужно наблюдать дальше;
- какое изменение требует отдельной работы.
Если причина не подтверждена, это тоже стоит написать. Тогда следующая диагностика начинается с уже проверенных гипотез.
Когда звать подрядчика
Диагностика нужна, если задержки повторяются, пользователи регулярно ждут одну и ту же операцию, после перезапуска проблема возвращается или никто не может показать состояние PostgreSQL и его обслуживание.
В «Доктор Сервер» можно обратиться для проверки инфраструктуры, на которой работает 1С, и согласования зон обслуживания PostgreSQL. Состав работ зависит от текущей архитектуры и состояния системы, стоимость определяется после аудита и предоставляется по запросу.