Настройка производительности Postgresql 1c

Обновлено: 21.11.2024

База данных Azure для PostgreSQL имеет функции, которые помогут вам понять и повысить производительность вашего сервера. В этом уроке вы узнаете, как:

Включить сбор статистики запросов и ожиданий
Доступ к собранным данным и их использование
Просмотр производительности запросов и статистики ожидания с течением времени.
Проанализируйте базу данных, чтобы получить рекомендации по эффективности.
Применить рекомендации по эффективности

Предпосылки

Вам потребуется база данных Azure для сервера PostgreSQL с PostgreSQL версии 9.6 или 10. Чтобы создать сервер, выполните действия, описанные в руководстве по созданию.

Хранилище запросов, данные о производительности запросов и рекомендации по производительности находятся в общедоступной предварительной версии.

Включение сбора данных

Хранилище запросов фиксирует историю запросов и статистику ожидания на вашем сервере и сохраняет ее в базе данных azure_sys на вашем сервере. Это дополнительная функция. Чтобы включить его:

Откройте портал Azure.

Выберите базу данных Azure для сервера PostgreSQL.

Выберите параметры сервера в разделе настроек меню слева.

Установите для pg_qs.query_capture_mode значение TOP, чтобы начать сбор данных о производительности запросов. Установите для pgms_wait_sampling.query_capture_mode значение ALL, чтобы начать сбор статистики ожидания. Сохранить.

Подождите до 20 минут, пока первый пакет данных сохранится в базе данных azure_sys.

Статистика эффективности

Представление Query Performance Insight на портале Azure будет отображать визуализацию ключевой информации из Query Store.

На странице портала базы данных Azure для сервера PostgreSQL выберите "Запрос данных о производительности" в разделе "Поддержка + устранение неполадок" в меню слева.

На вкладке "Длительные запросы" показаны 5 самых популярных запросов по средней продолжительности выполнения, объединенных с 15-минутными интервалами.

Вы можете просмотреть дополнительные запросы, выбрав их в раскрывающемся списке "Число запросов". При этом цвета диаграммы могут измениться для определенного идентификатора запроса.

Вы можете щелкнуть и перетащить диаграмму, чтобы сузить ее до определенного временного окна.

Используйте значки увеличения и уменьшения масштаба для просмотра меньшего или большего периода времени соответственно.

Просмотрите таблицу под диаграммой, чтобы узнать больше о длительных запросах в этом временном окне.

Выберите вкладку Статистика ожидания, чтобы просмотреть соответствующие визуализации ожиданий на сервере.

Очистить ресурсы

На предыдущих шагах вы создали ресурсы Azure в группе серверов. Если вы не предполагаете, что эти ресурсы потребуются в будущем, удалите группу серверов. Нажмите кнопку Удалить на странице Обзор для вашей группы серверов. При появлении запроса на всплывающей странице подтвердите имя группы серверов и нажмите последнюю кнопку Удалить.

Запуск сервера — это только начало. Работающий производственный сервер также нуждается в настройке производительности вспомогательных служб. Наиболее важным из этих факторов является производительность базы данных. В этом разделе вы можете работать с несколькими наиболее распространенными параметрами настройки производительности базы данных.

Настройка PostgreSQL по умолчанию предназначена для очень маленькой системы почти без оперативной памяти. Из-за этого он работает очень плохо даже для небольшого экземпляра, такого как наша виртуальная машина xnatdev. Значения по умолчанию в Ubuntu предполагают больший объем оперативной памяти, чем стандартные значения по умолчанию для Postgres.

Корректировки в этом практическом примере изначально взяты из вики-страницы PostgreSQL: Настройка вашего сервера PostgreSQL

Память, доступная для PostgreSQL

Перед настройкой PostgreSQL мы должны решить, какой максимальный объем оперативной памяти может использовать PostgreSQL. В нашем случае PostgreSQL использует общие ресурсы с Tomcat7 и ZFS на виртуальной машине объемом 2 ГБ. Мы уже выделили 512 МБ для ZFS. ОС обычно занимает еще 512 МБ. Это оставляет нам 1 ГБ для Tomcat7 и PostgreSQL. Равномерное разделение имеет смысл для XNAT. В этом примере мы выделим 512 МБ для PostgreSQL.

Редактировать postgresql.conf

Совет по редактированию длинных файлов в консоли

В большинстве текстовых редакторов с командной строкой есть функция, позволяющая находить термин. В nano используйте CTRL-W, чтобы открыть небольшую панель поиска в нижней части экрана. Вы можете ввести такой термин, как «shared_buffers», и нажать Enter, чтобы перейти к первому экземпляру этого термина в файле. Продолжая нажимать CTRL-W, вы сможете найти следующее вхождение этого термина или начать новый поиск нового термина.

общие_буферы

Для нашего экземпляра в Ubuntu по умолчанию достаточно 128 МБ.

Хорошее эмпирическое правило – 1/4 максимального распределения. Что в нашем случае составляет 128 МБ. Никаких изменений не требуется.

work_mem и Maintenance_work_mem

Линейное масштабирование не всегда выгодно. Для их установки я использую следующую логику:

эффективный_размер_кэша

Лучше всего установить 1/2 максимального распределения:

Перезапустите PostgreSQL

Если вы дошли до этого момента, теперь у вас есть работающая установка XNAT! Когда будете готовы, можете.

Расскажу для начала, какой путь мы прошли в 1С на PostgreSQL.

Версии Postgres для 1С

Но прежде чем окунуться в Enterprise, сначала напомню, какая версия PostgreSQL для 1С есть. В этом моменте у многих есть недопонимание.

PostgreSQL для 1С — самосборка

Версия №1 – это самосборка PostgreSQL для 1С на основе открытых исходников ванильной версии. Для тех, кто умеет собирать пакеты – это самая теплая ламповая сборка.

В чем ее особенности использования:

В чем ее особенности:

PostgreSQL для 1С от Postgres PRO

Стандарт Postgres PRO

Еще одна такая же сборка с небольшой цензурой Postgres PRO Standart.

Получить ее можно, зарегистрировавшись на сайте Postgres PRO.

Postgres PRO Enterprise

Коммерческая сборка Postgres PRO Enterprise – чем она отличается от версии Postgres PRO Standart:

Фишки Enterprise, полезные для 1С

Теперь подробнее поговорим о фишках Enterprise, которые важны именно для 1С.

Теперь давайте подробнее рассмотрим, как это в жизни работает.

pg_hint_plan

pg_hint_plan — это не фишка Enterprise, это открытие расширения, которое вы можете легко реализовать в своей сборке, но в Enterprise оно уже внедрено.

Для решения такого вида проблем есть pg_hint_plan. Вы можете изменить план выполнения запроса, добавляя в нужные вам операторы, как отображение на слайде.

Конкретно этот пример взятия меня из документации. Здесь указано:

HashJoin(a,b) — таблицы a и b необходимо соединить по хэшу.
SeqScan(a) — в таблице сделать SeqScan.

Ниже план выполнения, где видно, что Postgres выполняет так команду, как ему сказали.

Скорее всего, в коде 1С не может быть реализовано так, чтобы вся платформа правильно обработала и передала. Но в этом расширении есть крутая штука – таблица указана, где вы можете шаблонно указать запрос и что с ним сделать.

Тут надо иметь в виду уникальность одной – шаблон запроса это не маска, хоть и называется шаблоном. Чтобы эта настройка сработала, запрос должен прилетать всегда.

А с помощью указаний Установить, что вы можете на время планирования задать параметры планировщика GUC (например, указать join_collapse_limit=1 на ваш любимый отчет) – получается, что и запрос ускорится и база летать уменьшится.

Подробно запросы разбирать я не буду, но это незаслуженно забытое расширение, изучите его. Документации по этому поводу много, очень крутая вещь, будущее у нее есть.

Сжатие данных на уровне СУБД

Что дает сжатие данных на уровне СУБД:

Дает экономию места – в документации написано от 3 до 5 раз, на наших тестах от 5 до 8 раз от глубины.
Дает еще большее снижение деградации производительности смешанных нагрузок – именно у нас в 1С постоянно смешанные нагрузки OLAP+OLTP. Мы хотим, чтобы база данных записывала транзакционные операции в базе, и так же очень быстро все читалось из имеющихся в отчетах, которые соединяются между собой по 200 таблицам. От чего здесь идет уменьшение деградации? Все элементарно – вы собираете частицы на диск. В основном СУБД основные тормоза – это диски. Процессоры справляются, память очень дешевая, ее можно добавить сколько угодно. Диски, даже SSD, все равно тормозят по сравнению с процессорами и памятью. Да, сейчас активно начали использовать NVME, но и они не всесильны, а так же немалую роль играет стоимость 1 ГБ места на диске, которую можно уменьшить в разы, используя сжатие. При сжатии на уровне СУБД вы чисто физически измеряете объем поднимаемых данных в 5-8 раз. Получаются не только данные, но и индексы и временные таблицы тоже – они так же жмутся.
Еще одна фишка – шифрование данных. Это важная возможность для тех, кто хранит конфиденциальные данные. В этом случае при старте базы данных необходимо указать пароль.

Казалось бы, сжатие – крутая вещь, но когда мы начали использовать ее на 1С, мы начали не по-детски “штормить”.

На тот момент у нас были настройки видео, как на слайде. Не было только одной настройки – Сжать первый сегмент отношений.

Что это такое? По умолчанию сжатие происходит вообще всех элементов данных. Опять же напоминаю, что типовая Бухгалтерия содержит 5,5 тысяч таблиц и 27 тысяч индексов – всего 32 файла.

Кроме того, Postgres каждый следующий гигабайт записывает в новый файл. Может быть, одна наша база данных содержит 300 тысяч файлов.

По умолчанию CFS попробует сжать все 300 тысяч файлов.

В результате мы обнаружили у каждого вот такой файл-отражение с размером 1 мегабайт, поскольку именно в 1 мегабайте они могут удержать отражение 1 Гб данных.

Postgres не знает, что его жаловали, он обращается к номеру страницы на диске, который у него в базе написан.

Система видео перехватывает этот запрос, и запрашивает в CFM-файле, где эти данные теперь в реальности находятся – мы же сжали файлы, а оригиналы, грубо говоря, удалены, они доступны в другом месте. Размер файла составляет 1 мегабайт.

В чем случилась беда? Наш первый тест на базе 1С показал следующее: CFS-worker работает по всем файлам отражения и пытается их дефрагментировать – удалить откуда то, что мы удалили из данных. Грубо говоря, еще один вакуум еще один элемент. При таком количестве файлов, как в базе 1С, CFS-worker клали на лопатки любых дисковых систем. У нас система легла на 4 млн файлов – это 150 баз на сервере 1С.

После тестирования разработчиков PostgreSQL:

добавили параметр cfs_compress_small_relations, чтобы компрессия Работала только для файлов больше 1 ГБ;
и в принципе, исправили поведение CFS-worker – теперь он меньше грузит диски, даже если вы не отключите сжатие всего и вся.

Дальнейшие исследования показывают, что нельзя сжать табличное пространство по умолчанию. использование Postgres создает и создает пространство-default. Но сжать уже созданное пространство невозможно, сжатие происходит путем создания пространства с сжатием.

Здесь можно пройти множеством путями:

Как я уже сказал, каждый файл отражения весит 1 МБ, но это не реальное место, которое занимает файл на диске, а просто атрибут файла. В итоге можно получить интересный эффект. После достижения 100-гиговой фазы в свойствах Postgres вы обнаружите, что 100-гиговая фаза начала весить 250 гигов. Как же так, мы же сжали? Все просто: у вас образовалось 150 тысяч файлов отражений. Это пока не исправлено, нет отдельных процедур, которые показывают правильный размер, либо я о ней не знаю.

Реальный размер в Linux увеличился с помощью утилиты du (использование диска) – на слайде изображена командная строка, как проверено. Эта утилита показывает вам реальный размер, который соответствует данным на диске, а не размеры, подсчитанные по атрибутам файлов. В pg_admin будет передана информация.

Еще одна особенность, обнаруженная случайно: оказывается, используется pg_repak (по факту вакуум_полный без блокировки данных), знает, но не посещает табличное пространство у таблиц.

Поскольку при сжатии мы создаем отдельное табличное пространство, то pg_repack, когда вы натравите его на сжатую базу, перепаковывает таблицу в несжатое пространство по умолчанию.

При этом при переупаковке индексов в них учатся. Но на всякий случай пришел вам команда и для индексов -S (большая). Это надо обязательно иметь в виду.

Что случилось в августе

Я впервые встречаю поставщика, с разработчиками которого можно общаться непосредственно на русском языке, и они тебе переходят в течение одной минуты, не ткнут носом в ошибку, проанализируй и очень быстро и аккуратно исправляй баги.

С 1 сентября, когда с нами сняли все карантины, заодно мы рассматриваем полную версию Enterprise версии PostgreSQL со сжатием данных. Огромное спасибо разработчикам движка данных и моей загрузки 1С-ников, которые все это протестили.

P.S. Все обнаруженные нами проблемы со сжатием появились в версии 12.5.1.

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Новосибирск. Больше статей можно прочитать здесь.

Оптимизация производительности PostgreSQL для работы с 1С:Предприятие

PostgreSQL набирает все большую популярность как СУБД для использования в связке с 1С:Предприятие. При этом из наиболее частых нареканий является низкая производительность этого решения. Во многом это связано с тем, что настройки PostgreSQL по умолчанию являются неоптимальными, а резерв запуска и работа СУБД на минимальном уровне. Поэтому имеет смысл потратить небольшое количество времени на оптимизацию производительности сервера, тем более что это не очень сложно.

Курс по сетевым технологиям от Дмитрия Скоромнова подходит и начинающим, и людям с опытом. Практикующие системные администраторы упорядочивают свои знания и исполняют обязанности по устранению неполадок. А те, кто только поступает в профессию, получают базовые знания, без воды и избыточной теории. После обучения вы должны ответить на вопросы:

• на каком уровне модели могут работать OSI?
• как лучше исследовать работу сети организации с уязвимыми отделами?
• для чего использовать протокол VLAN?
• для чего сервер стоит носить в DMZ?
• Как осуществляется объединение филиалов и удаленный доступ сотрудников по VPN?
и многие другие.

Уже знаете ответы на вопросы, перечисленные выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. 53 вопроса, всего в цикле теста проходит 10 вопросов. Каждый раз набор раз вопросы. Тест может проходить неоднократно без потери интереса. Бесплатно и без регистрации.

Существуют разные рекомендации по рекомендации PostgreSQL для совместной работы с 1С, мы будем опираться на официальные рекомендации, изложенные на ИТС, также можно использовать онлайн-калькулятор для быстрого расчета некоторых параметров. Если данные калькулятора и рекомендации 1С расходятся - предпочтение будет отдано рекомендации 1С.

Для тестирования мы использовали систему:

ЦП — Core i5-4670 — 3,4/3,8 ГГц
Оперативная память: 32 ГБ DDR3
Системный диск - SSD WD Green 120 ГБ
Диск для данных - 2 х SSD Samsung 860 EVO 250 ГБ - RAID1
СУБД - PostgresPro 11.6
Платформа - 8.3.16.1148
ОС — Debian 10 x64

Прежде всего выполним тестирование параметрами по умолчанию:

Полученный результат - 22,32 по Гилеву высокому не назовешь, для наблюдаемого мы использовали толщину Розница 2,2 с базой наблюдаемого объема потребления в 8 ГБ, в целом можно было наблюдать за наблюдениями, но местами наблюдения наблюдалась неопределенная "задумчивость", особенно при открытии ниспадающих списков.

Перейдем к близкому. Все изменения следует вносить в файл postgesql.conf, который появляется в Linux для сборки 1С по пути /etc/postgres/1x/main, а для сборки от PostgresPro в /var/lib/pgpro/1c-1x/data. В Windows данный файл отображается в каталоге данных, по умолчанию это C:\Program Files\PostgreSQL 1C\1х\data. Все параметры в определенной степени соответствуют их отслеживанию в конфигурационном файле.

Одним из основных параметров, требующим учета при расчетах, является объем оперативной памяти. При этом следует использовать то значение, которое вы готовы выделить серверу СУБД, за вычетом ОЗУ используемой ОС и другими службами, скажем, сервером 1С. В нашем случае это будет Ирландия на 24 ГБ.

Затем рассчитаем значения параметров с помощью калькулятора, для чего можно использовать ОС и версию Postgres, тип накопителя, доступный объем памяти и количество ядра процессора. В поле Тип БД размещаются Хранилища данных, количество продуктов, которые можно проигнорировать, так как вычисляемый результат будет значительным расходиться с рекомендациями 1С.

Теперь можно приступить к редактированию файла сборки. Многие значения в нем закомментированы и имеют значения по умолчанию, при использовании таких параметров следует строки раскомментировать.

Максимальное число соединений, 1С восстанавливаем выше значений, мы установили 1000.

Объем памяти для обмена кеша страниц, разделяется между всеми процессами Postgres, рекомендуемое значение - четверть доступного объема памяти, в нашем случае 6 ГБ.

Верхний лимит для временных таблиц в каждую сессию, рекомендуемое фиксированное значение.

Указывает объем памяти, который может быть использован для первичного запроса, чем задействованы временные файлы на диске. Применяется для каждого соединения и каждой операции, поэтому итоговый объем потребляемой памяти может значительно превосходить заданное значение. Это вычисляемое значение, которое существенно отличается от состава 1С. Для объема памяти в 24 ГБ рекомендуемыми значениями будут 375 - 750 МБ, мы выбрали 512 МБ.

Объем памяти для обслуживания их задач (автовакуум, реиндексация и т.д.), уведомленный калькулятором объема, в нашем случае 2 ГБ.

Максимальное количество открытых файлов в одном процессе, в сборке PostgresPro для Linux это значение по умолчанию.

Параметры процесса фоновой записи, который отвечает за синхронизацию страницы в shared_buffers с диском.

Допустимое количество одновременных операций ввода/вывода. Для жесткости дисков по количеству шпинделей, для массивов RAID5/6 следует настройка дисков четности. Для SATA SSD это значение назначается размером 200, а для быстрых дисков NVMe его можно увеличить до 500-1000. При этом следует понимать, что высокие значения в повышении с замедлением дискретизации обратного эффекта, поэтому подходят к этой настройке грамотно.

Важно! Параметр Effective_io_concurrency настраивается только в среде Linux, в Windows его значение должно быть одинаково использовано.

Настройки фоновых рабочих процессов, выбор значения зависит от количества процессорных ядер, берем значения из калькулятора. Выше указание для четырехъядерного СРU.

Заставляет сервер добиваться физических записей изменений на диске. Выключение данной опции хотя и позволяет повысить производительность, но значительно увеличивает риск необратимой порчи данных при внезапном отключении питания.

Альтернатива отключению fsync, позволяет серверу не открывать данные на диске, прежде чем сообщить клиенту об успешном завершении операции. Использовать достаточно безопасно повысить производительность труда. В случае внезапного выключения питания могут быть утрачены несколько последних транзакций, но сама основа принадлежит к рабочему состоянию, а также как и при штатной отмене потерянных транзакций.

Задает размер буфера журнала предварительной записи (WAL, он же журнал транзакций), если оставить одного экземпляра без изменений, то сервер будет автоматически обрабатывать это значение в 1/32 от shared_buffers, но не менее 64 КБ и не более размера сегмента WAL в 16 МБ.

Указывает на возможность задержки в мс перед записью транзакций на диск при включении открытых транзакций, приостановление во второй операции. Имеет смысл при количестве транзакций более 1000 в секунду, на меньших значениях эффекта не имеет.

Минимальный и максимальный размер файлов журнала предзаписи. В нашем случае это 4 ГБ и 16 ГБ.

Скорость записи изменений на диске, выявляется как время между точками назначения транзакций (чекпойнты) умноженное на показатель, позволяет растянуть процесс записи по времени и тем самым сократить однократную запись на диски. В нашем случае используется рекомендуемое калькулятором максимальное значение 0,9.

Стоимость последовательного чтения с диска, является относительным числом, в основе которого лежат все остальные переменные стоимости, вычисляется значением по умолчанию.

Стоимость случайного чтения с диском, чем ниже это число, тем более вероятно использование показателя по индексу, полное полное считывание таблицы, однако не следует применять слишком низкие значения, не соответствующие реальной производительности дисковой подсистемы, иначе когда производительность уточняется в медленный случайный доступ.

Таким образом, как это относится к значениям, но не имеет значения random_page_cost ниже seq_page_cost, однако при использовании производительных SSD имеет смысл понизить количество вычислений, чтобы повысить приоритетность выявленных нарушений к процессорным.

Для производителей SSD можно использовать значения:

Но еще раз помним, значения данных не являются панацеей и должны восприниматься осмысленно, с реальным пониманием производительности дисковой подсистемы сервера, бездумная установка настроек, способно показать обратный эффект.

Определяет размер кеша, который может распространяться по одному запросу. Этот параметр не имеет значения для объемной выборочной памяти, не резервирует ее, служит для ориентировочной оценки доступного размера кеша планировщиком документов. Чем выше, тем большая вероятность использования мощного индекса, а не последовательного сильного. При расчете следует использовать выделенный серверу объем ОЗУ, а не полный объем ОЗУ. В нашем случае это 18 ГБ.

Включение автовакуума, это очень важный для производителя параметр базы. Не отключайте его!

Количество рабочих процессов автовакуума, получаемых из процессорных ядер, не менее 4, в нашем случае 4.

Время загрузки процессов автовакуума, большое значение будет приводить к неэффективной работе, слишком мало только повысит нагрузку без видимого эффекта.

Отключает поиск защиты на уровне строк, обнаружение неиспользуемой платформы и ее отключение дает ключевые слова повышения производительности.

Максимальное количество блокировок в одной плотности, рекомендация от 1С.

Данные опции специфичны для 1С и регулируют использование символа \ для экранирования.

Сохраните файл конфигурации и перезапустите PostgreSQL, в Linux это можно контролировать командами:

В штатных обозначениях системы Windows, либо скриптами из сборки PostgreSQL:

После чего снова выполним тестирование производительности, в этот раз мы получили следующий результат:

Как видимые, достаточно несложные действия по предполагаемому серверу около 30% производительности, ощутимые ощущения от работы с конфигурацией Розница также повысилась, исчезло ощущение "задумчивости", повысилась чувствительность системы.

Указанные выше настройки и параметры являются базовым набором для сравнения PostgreSQL при совместной работе с 1С:Предприятие и даже начинающим администраторам. Для выполнения этих действий не требуется глубокого понимания работы СУБД, достаточно просто правильно рассчитать ряд показателей. Данные рекомендации основаны на официальной версии и рекомендуются в качестве базовой версии сервера СУБД сразу после установки.

Курс по сетевым технологиям от Дмитрия Скоромнова подходит и начинающим, и людям с опытом. Практикующие системные администраторы упорядочивают свои знания и исполняют обязанности по устранению неполадок. А те, кто только поступает в профессию, получают базовые знания, без воды и избыточной теории.После обучения вы должны ответить на вопросы:

Читайте также: