Postgres Pro — Тюнингуем «Слона» под 1С и суровый прод — 27 апреля 2026 г. в 06:57:28.307
Postgres Pro — Тюнингуем «Слона» под 1С и суровый прод Если вы думали, что импортозамещение БД — это просто apt install postgrespro-std-16, то у меня для вас плохие новости. «Из коробки» он настроен так, чтобы запуститься даже на калькуляторе, а на сервере с 128 ГБ оперативы он будет скромно использовать 128 МБ, пока ваши пользователи будут седеть в ожидании отчетов. Сегодня превращаем «ванильного слона» в боевую машину. 🛠 Шаг 1: Shared Buffers — Дай слону поесть Это самый важный параметр. По умолчанию там стоят копейки. Если у вас выделенный сервер под БД, отдаем 25% оперативной памяти под кэш. Лезем в конфиг: sudo nano /var/lib/pgpro/std-16/data/postgresql.conf (Путь может меняться в зависимости от версии, ищите свой через find / -name postgresql.conf) Меняем (на примере сервера с 64 ГБ RAM): shared_buffers = 16GB 🛠 Шаг 2: Настройка под SSD (random_page_cost) PostgreSQL по умолчанию думает, что вы всё еще живете в 2005-м и используете медленные HDD. Он завышает стоимость случайного доступа к данным. На современных NVMe/SSD это заставляет планировщик игнорировать индексы. Исправляем несправедливость: random_page_cost = 1.1 effective_io_concurrency = 200 Теперь планировщик поймет, что диски быстрые, и запросы полетят. 🛠 Шаг 3: Магия для 1С (Специфические патчи) Postgres Pro хорош тем, что в нем уже есть патчи для 1С. Но их нужно включить в конфиге, иначе будете ловить странные ошибки блокировок. Добавляем в конец файла: row_security = off standard_conforming_strings = off escape_string_warning = off 🛠 Шаг 4: Автовакуум — чистим мусор вовремя В 1С таблицы постоянно пухнут и обновляются. Если автовакуум не будет приходить вовремя, база превратится в тыкву. Ускоряем уборку: autovacuum_max_workers = 4 autovacuum_vacuum_scale_factor = 0.01 autovacuum_analyze_scale_factor = 0.005 Теперь очистка начнется при изменении 1% данных, а не 20%, как в дефолте. 🧪 Проверяем, что не накосячили После правок перезагружаем службу: sudo systemctl restart postgrespro-std-16 И проверяем реальные настройки через SQL-запрос: sudo -u postgres psql -c "SELECT name, setting, unit FROM pg_settings WHERE name IN ('shared_buffers', 'random_page_cost', 'max_connections');" Результат: Если в таблице выдачи вы видите свои 16GB и 1.1 — поздравляю, ваш деплой через колено прошел успешно, и база готова к нагрузкам! 🔥 Админский совет: Никогда не ставьте max_connections больше 500-1000 без использования Pgbouncer. Иначе ваша память закончится быстрее, чем вы допьете утренний кофе, просто на поддержание соединений. Вопрос к знатокам: Кто уже пробовал инкрементальные бэкапы в Enterprise версии? Стоят они своих денег или по старинке сидим на pg_dump и молитвах? 👇 #PostgresPro #1C #АдминскиеБудни #ДеплойЧерезКолено #Database #DBA