Postgresql конфигурационный файл. Настройка типов данных. Вставка и удаление данных

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

Настройка PostgreSQL под 1С

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

  • Для начала отключаем Energy Saving (в противном случае могут непредсказуемо вырасти задержки ответов из БД) и запрещаем своппинг разделяемой памяти.
  • Настраиваем основные параметры сервера СУБД (рекомендации по настройке описаны достаточно подробно, как на официальном сайте вендора, так и компанией 1С, поэтому остановимся только на самых важных).
  • В типовых рекомендациях компании 1С предлагается отключать механизмы HyperThreading. Но тестирование Postgres-pro на серверах, с включенной SMT (simultaneous multi threading), показало другие результаты .
Установка параметра shared_buffers в RAM/4 является рекомендацией по умолчанию, но пример Sql Server говорит о том, что чем больше памяти ему выделяется, тем лучше его производительность (при отключенном сбросе страниц в файл подкачки). То есть, чем больше страниц данных располагаются в оперативной памяти, тем меньше обращений к диску. Возникает вопрос: почему такой маленький кэш? Ответ прост: если shared_buffers большой, то часть неиспользуемых страниц свопируется на диск. Но как отследить момент, когда сброс прекратится, и показатель параметра будет оптимальным? Для достижения и выхода на оптимальный показатель shared_buffers, его значение необходимо поднимать на продуктиве ежедневно (по возможности) с определенным шагом прироста и смотреть, в какой момент начнется сброс страниц на диск (увеличится своп).
  • Помимо этого, на «большой параметр» негативно влияет работа с множеством мелких страниц, которые по умолчанию имеют размер 8Кб. Работа с ними увеличивает накладные расходы. Что можно с этим сделать для оптимизации под 1С? В версии postgreSQL 9.4 появился параметр huge_pages, который можно включить, но только в Linux. По умолчанию включаются огромные страницы с размером по умолчанию 2048 kB. Дополнительно поддержку данных страниц необходимо включить в ОС. Таким образом, оптимизировав структуру хранения, можно выйти на больший показатель shared_buffers.
  • work_mem = RAM/32..64 или 32MB..128MB Задает объем памяти для каждой сессии, который будет использоваться для внутренних операций сортировки, объединения и пр., прежде чем будут задействованы временные файлы. При превышении этого объема, сервер будет использовать временные файлы на диске, что может существенно снизить скорость обработки запросов. Данный параметр используется при выполнении операторов: ORDER BY, DISTINCT, соединения слиянием и пр.
  • Посчитать дополнительно данный параметр можно следующим образом: (Общая память shared_buffers – память на другие программы) / число активных соединений. Это значение можно уменьшать, следя за количеством создаваемых временных файлов. Такую статистику по размеру и количеству временных файлов можно получить из системного представления pg_stat_database.
  • effective_cache_size = RAM - shared_buffers основная задача этого параметра подсказать оптимизатору запроса, какой способ получения данных выбрать: полный просмотр или сканирование по индексу. Чем выше значение параметра, тем больше вероятность использования сканирования по индексу. При этом сервер не учитывает, что данные при выполнении запроса могут оставаться в памяти, и следующему запросу не надо их поднимать с диска.
  • Установка PostgreSQL

    Установка 1С на PostgreSQL под Windows – достаточно простой процесс. При запуске установочного пакета необходимо указать кодировку UTF-8. По сути, это единственный интересный нюанс и еще какая-то настройка PostgreSQL для 1С 8.3 из-под Windows не потребуется. Установка и настройка PostgreSQL для 1С на ОС linux может вызвать ряд затруднений. Для их преодоления в качестве примера рассмотрим запуск работы (используя дистрибутивы ведущего российского вендора PostgreSQL-Pro и компании 1С) PostgreSQL на сервере Ubuntu 16.04 х64

    Установка дистрибутивов 1С для СУБД PostgreSQL

    1.Скачиваем указанную позицию дистрибутива СУБД PostgreSQL:

    2.Выкладываем PostgreSQL на сервер;

    3.Распаковать установщик СУБД PostgreSQL можно командой:

    tar -xvf postgresql-9.4.2-1.1C_amd64_deb.tar.bz2

    4.Перед установкой дистрибутива СУБД PostgreSQL проверим наличие в системе необходимой локали (по умолчанию ru_RU.UTF-8):


    5.Если система, с которой будет работать PostgreSQL, ставилась с языком отличным от русского, необходимо создать новые локали:

    locale-gen ru_RU update-locale LANG=ru_RU.UTF8 dpkg-reconfigure locales

    6.Если необходимая локаль все же имеется, устанавливаем ее по умолчанию:

    locale –a nano /etc/default/locale Заменяем содержимое на LANG=ru_RU.UTF-8

    7.После перезагрузки, установим необходимые пакеты для нашей версии PostgreSQL:

    apt-get install libxslt1.1 ssl-cert

    8.Версия PostgreSQL пакета 9.4.2-1.1C связана с пакетом libicu версии libicu48. В репозитории нужной версии уже нет, ее можно скачать ;

    9.Скачиваем и помещаем в каталог, где хранятся скачанные файлы для PostgreSQL;

    10.Перейдя в каталог с файлами PostgreSQL, производим установку, последовательно набирая следующие команды:

    cd <Путь к папке с файлами> dpkg -i libicu48_4.8.1.1-3ubuntu0.6_amd64.deb dpkg -i libpq5_9.4.2-1.1C_amd64.deb dpkg -i postgresql-client-common_154.1.1C_all.deb dpkg -i postgresql-common_154.1.1C_all.deb dpkg -i postgresql-client-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-contrib-9.4_9.4.2-1.1C_amd64.deb

    11.Готово. Дистрибутив СУБД PostgreSQL установлен.

    Установка дистрибутивов PostgreSQL-Pro

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

    sudo sh -c "echo "deb http:// 1c.postgrespro.ru/deb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/postgrespro-1c.list" wget --quiet -O - http:// 1c.postgrespro.ru/keys/GPG-KEY-POSTGRESPRO-1C-92 | sudo apt-key add - && sudo apt-get update sudo apt-get install postgresql-pro-1c-9.4

    Для доступа к серверу редактируем параметры в файле pg_hba.conf

    сd <Путь до каталога pg_hba.conf> cp pg_hba.conf pg_hba.conf.old bash -c "echo "local all postgres trust" > pg_hba.conf" bash -c "echo "host all all all md5" >> pg_hba.conf"

    Сам файл имеет следующую структуру:


    Файл хорошо документирован, но на английском языке. Кратко рассмотрим основные параметры:

    • Local локальное подключение только через unix
    • Host подключение по TCP/IP
    • Hostssl шифрованное SSL-подключение по TCP/IP (сервер должен быть собран с поддержкой SSL, также требуется установить параметр ssl)
    • Hostnossl нешифрованное подключение по TCP/IP
    • trust допустить без аутентификации
    • reject отказать без аутентификации
    • password запрос пароля открытым текстом
    • md5 запрос пароля в виде MD5
    • ldap проверка имени и пароля с помощью сервера LDAP
    • radius проверка имени и пароля с помощью сервера RADIUS
    • pam проверка имени и пароля с помощью службы подключаемых модулей

    Более подробную и развернутую информацию можно посмотреть в документации к продукту PostgreSQL.

    root@NODE2:/home/asd# service --status-all |grep postgres [ - ] postgresql root@NODE2:/home/asd# service postgresql start root@NODE2:/home/asd# service --status-all |grep postgres [ + ] postgresql

    После окончания основной установки, необходимо настроить конфигурационный файл сервера postgresql.conf, согласно специфики работы PostgreSQL, сервера 1С и конфигурации сервера Ubuntu.

    Оптимизация 1С под MS SQL Server

    Устанавливаем последние обновления для SQL Sever.

    Операционная система резервирует место и забивает его нулями, что занимает достаточно много времени при следующих событиях:

    • Создание базы данных;
    • Добавление файлов данных, журнал транзакций, к существующей базе данных;
    • Увеличение размера существующего файла (в том числе Autogrow-операций);
    • Восстанавливаем базы данных или группы файлов.

    Решается данная проблема добавлением роли (под которой запущен сервер) к пункту локальной политики безопасности «Выполнение задач по обслуживанию томов».

    При возможности необходимо разнести базу TempDB (особенно интенсивно она используется в режиме управляемых блокировок RCSI) и журнал транзакций на разные диски.

    На сервере, где работает SQL сервер, режим энергосбережения должен быть установлен в «Высокая производительность».

    В папке с файлами БД не должно быть сжатия.

    На вкладке «Память» для сервера устанавливаем минимальную планку в размере 50% от общего объема памяти. Максимальную рассчитываем по одной из формул:

    • Максимальная память = Общий объем – размер по ОС – размер под 1С (Если он есть, предварительно замерив счетчиками используемую память) или
    • Максимальная память = Общий объем – (1024* Общий объем/16384).

    Ограничиваем параметр DOP «Max degree of parallelism» и ставим его в значение «1».

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

    Периодически проводим реиндексацию таблицы и дефрагментацию индексов.

    Устанавливаем правильную политику резервирования. Если вам не надо восстанавливаться на последний момент времени к краху системы, а последние минут 5 или больше для вашего бизнеса не критичны, то установите модель восстановления в «Простая». Этим вы ускорите в разы скорость при записи. Главное, чтобы дифференцированный бекап успевал выполняться за указанное время.

    Добиваемся улучшения при работе с TempDB при вводе/выводе посредством создания дополнительных файлов данных. Если логических процессоров меньше 8, рекомендуется создать файл данных для каждого логического процессора. Если логических процессоров больше 8, рекомендуется создать 8 файлов данных и, увеличивая на один при кратности 4, обязательно оценить нагрузку на TempDB.

    Попробуйте PostgreSQL - объектно-реляционную СУБД. Она подходит для коммерческого использования. В ней много дополнительных модулей и функций. PgSQL-синтаксис этого приложения чем-то похож на знаменитую утилиту MySQL. Если вы умеете ей пользоваться, то переход на новую площадку будет лёгким. Чтобы установка PostgreSQL Ubuntu прошла успешно, не нужно вводить много команд.

    Установить и настроить СУБД PostreSQL на Ubuntu несложно — просто следуйте нашим инструкциям


    В программе доступны разные методы аутентификации. Лучше выбрать IDENT или MD5. Первый стоит по умолчанию. Чтобы использовать второй:

    1. Откройте файл pg_hba.conf. Он в каталоге «/etc/postgresql/[Версия программы]/main/».
    2. Найдите там параметр «local all postgres» и напечатайте рядом md5. Если такой строки нет, впишите её.

    Использование

    Руководство по использованию можно скачать прямо из терминала. Введите в «apt-get install postgresql-doc-[Версия утилиты]». Вот некоторые важные команды:

    Работа с таблицами

    • Добавление таблицы - «CREATE TABLE [Название таблицы]».
    • После этой команды в скобках напишите параметры сетки «[Название строки] [Тип] ([Количество позиций]) [Возможные ограничения]». Таким образом введите несколько строк, разделяя их запятыми. После каждой нажимайте Enter. У колонок могут быть разные названия и типы. Когда закончите записывать данные, закройте скобку и поставьте точку с запятой. Количество позиций тоже указывайте в скобках.
    • Посмотреть содержимое таблицы - «\d». А лучше - «SELECT * FROM [Имя]»
    • Удалить её - «DROP TABLE [Название]». После этого нажмите Enter и напишите «DROP TABLE» ещё раз.
    • Ввести данные - «INSERT INTO [Имя сетки] (Столбец1, Столбец2, Столбец3) VALUES (‘Запись1’, ‘Запись2’, ‘Запись3’);». В столбцы будут добавлены соответствующие записи. Можете повторять команду, чтобы вписывать новую информацию
    • Удалить значение - «DELETE FROM [Название таблицы] WHERE [Название столбца] = ‘[Значение]’;».
    • Новый столбец - «ALTER TABLE [Имя сетки] ADD [Имя колонки]».
    • Удалить столбец - «ALTER TABLE [Таблица] DROP [Название столбца]».

    1. Установка

    1.1. Установка из официального репозитория

    Если для Вас важна последняя доступная версия PostgreSQL (если нет, я советую Вам хорошенько подумать), то Вам необходимо установить ее из официального репозитория PostgreSQL. Сделать это можно, следуя официальной инструкции . Затем, следует обновить пакеты:

    $ sudo apt-get update

    И установить PostgreSQL командой:

    $ sudo apt-get install postgresql-x.x

    • x.x - необходимая версия

    Список всех доступных версий можно посмотреть командой:

    $ sudo apt-cache search postgresql

    1.2. Установка из репозитория ОС

    Установка PostgreSQL из репозитория ОС производится путем добавления двух основных пакетов:

    $ sudo apt-get install postgresql postgresql-contrib

    2. Консоль PostgreSQL

    Все доступные операции над базами данных и пользователями производится из консоли psql .

    2.1. Вход в консоль

    Для начала необходимо войти в систему от пользователя postgres , это возможно только с правами root :

    # su - postgres

    Пользователь postgres - это своеобразный суперпользователь для базы данных PostgreSQL. Затем, из-под пользователя postgres можно войти в консоль:

    Или проще, сразу входим в консоль psql под пользователем postgres :

    $ sudo -u postgres psql

    2.2. Выход из консоли

    Когда выполнены все операции над пользователями и базами данных PostgreSQL в консоли psql, не сразу можно сообразить, как из нее выйти. Тут все очень просто:

    Postgres=# \q

    И, если это необходимо, уходим от пользователя postgres :

    3. Пользователи PostgreSQL

    3.1. Создание пользователя

    Тут все достаточно просто:

    # CREATE USER username WITH PASSWORD "12345";

    • username - логин нового пользователя
    • ‘12345’ - Пароль пользователя. Вводится в кавычках

    3.2. Удаление пользователя

    Тут еще проще:

    # DROP USER username;

    • username - логин пользователя, которого необходимо удалить.

    4. Базы данных

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

    4.1. Создание базы данных

    Тут все также, как при создании пользователя:

    # CREATE DATABASE dbname;

    4.2. Удаление базы данных

    # DROP DATABASE dbname;
    • dbname - имя удаляемой базы данных

    Прошу заметить, что база данных откажется удаляться в определенных случаях:

    • Если имеются пользователи с правами на эту базу. Перед удалением базы данных их права необходимо отозвать. Об этом далее.
    • Если имеется хотя бы одна незакрытая сессия соединения с базой данных. В этом случае сессии необходимо будет закрыть. В крайнем случае, можно просто остановить сервера, взаимодействующие с этой базой данных на момент ее удаления (хотя, смысла их запускать после удаления базы данных мало)

    4.3. Назначение прав пользователям

    Наличие базы данных и пользователей в системе PostgreSQL само по себе не дает результатов. Для корректной работы определенного пользователя с определенной базой данных, ему необходимо назначить права на работу с ней. Для этого выполняем комманду:

    # GRANT ALL PRIVILEGES ON DATABASE dbname TO username;

    • dbname - имя базы данных, права над работой которой необходимо дать доступ
    • username - имя пользователя, которому будут предоставлены права над указанной базой данных

    4.4. Удаление прав пользователей

    Иногда, возникает необходимость сменить пользователя, управляющего базой данных, или просто отозвать права для ее последующего удаления. Рекомендую не пренебрегать этой командой и действовать по принципу “Один пользователь управляет одной базой данных”.

    PostgreSQL - это объектно-реляционная система баз данных, которая обладает признаками традиционной коммерческой базы данных, с расширениями, которые будут доступны следующему поколению СУБД (систем управления базами данных).

    Установка

    Для установки PostgreSQL выполните следующую команду в терминале:

    Sudo apt-get install postgresql

    Сразу после установки вы можете настроить сервер PostgreSQL по вашим потребностям, хотя стандартная настройка вполне жизнеспособна.

    Настройка

    По умолчанию соединения через TCP/IP заблокированы. PostgreSQL поддерживает множество методов аутентификации. Метод аутентификации IDENT используется для postgres и локальных пользователей пока не настроено что-то еще. Обратитесь к , если вы собираетесь использовать какую-либо альтернативу типа Kerberos.

    Дальнейшее обсуждение предполагает, что вы собираетесь разрешить соединения по TCP/IP и используете аутентификацию клиентов на основе метода MD5. Файлы настроек PostgreSQL хранятся в каталоге /etc/postgresql/ /main . Например, если вы установили PostgreSQL 8.4, файлы настроек сохранятся в каталоге /etc/postgresql/8.4/main.

    Для настройки аутентификации ident добавьте записи в файл /etc/postgresql/8.4/main/pg_ident.conf. В файле содержатся подробные комментарии чтобы направлять вас.

    Чтобы разрешить соединения по TCP/IP, отредактируйте файл /etc/postgresql/8.4/main/postgresql.conf. Найдите строку

    #listen_addresses = "localhost"

    и замените ее на:

    Listen_addresses = "localhost"

    Чтобы разрешить другим компьютерам соединяться с вашим PostgreSQL сервером, замените "localhost" на IP адрес вашего сервера или в качестве альтернативы на 0.0.0.0, чтобы подключить все интерфейсы.

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

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

    Sudo -u postgres psql template1

    Эта команда подключится к PostgreSQL базе данных template1 как пользователь postgres. После подключения к серверу PostgreSQL вы окажетесь в SQL консоли. Вы можете выполнить следующую SQL команду в консоли psql для настройки пароля пользователя postgres:

    ALTER USER postgres with encrypted password "your_password";

    После настройки пароля, измените файл /etc/postgresql/8.4/main/pg_hba.conf на использование MD5 аутентификации для пользователя postgres:

    Local all postgres md5

    Под конец вам потребуется перезапустить сервис PostgreSQL для применения новых настроек. Из терминала выполните следующее для перезапуска PostgreSQL:

    Sudo /etc/init.d/postgresql-8.4 restart

    Настройка выше в любом случае неполная. Пожалуйста обратитесь к руководству PostgreSQL Administrator"s Guide для настройки других параметров.

    Ссылки

    1. Как упоминалось выше, Administrator"s Guide - великолепный ресурс. Руководство также доступно из пакета postgresql-doc-8.4 . Выполните следующую команду в терминале для установки пакета.

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

    Я же опишу ниже как установить и быстро настроить PostgreSQL 10 на Debian 9

    Исходные данные: Debian 9 Stretch (amd64)
    Задача: Установить PostgreSQL 10.x

    1. Предварительная настройка сервера:

    Добавляем на сервер русскую локаль, для начала проверяем её отсутствие/присутствие командой

    Locale -a | grep ru

    если в ответ ничего нет, то запускаем

    Dpkg-reconfigure locales

    выбираем в списке локаль ru_RU.UTF-8
    и жмем Yes
    выбираем локаль по умолчанию en_US.UTF-8

    2. Начинаем установку PostgreSQL 10:

    Echo "deb http://apt.postgresql.org/pub/repos/apt/ $(lsb_release -sc)-pgdg main" > /etc/apt/sources.list.d/pgdg.list wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add - apt-get update apt-get install postgresql-10 -y

    Краткая справка по местоположению основных файлов PostgreSQL 10:
    Местоположение баз данных:
    /var/lib/postgresql/10
    Местоположение логов:
    /var/log/postgresql/postgresql-10-main.log
    Настройка ротации логов:
    /etc/logrotate.d/postgresql-common
    Основные файлы конфигурации:
    /etc/postgresql/10/main/postgresql.conf
    /etc/postgresql/10/main/pg_hba.conf

    Первым делом меняем пароль пользователя postgres:

    Su - postgres psql postgres=# \password postgres postgres=# \q

    3. Тюнинг настроек PostgreSQL:

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

    Для PostgreSQL 10 открываем основной файл настроек

    Vi /etc/postgresql/10/main/postgresql.conf

    и раскомментируем строку

    Listen_addresses = "localhost"

    исправим её на

    Listen_addresses = "localhost,192.168.100.1"

    таким образом мы укажем PostgreSQL слушать сетевые соединения на интерфейсе localhost и на нашем внутреннем интерфейсе локальной сети с IP адресом 192.168.100.1

    Далее смотрим на параметр max_connections , который определяет максимальное количество одновременных соединений, которые будет обслуживать сервер PostgreSQL. В принципе, это число должно определяться исходя из требований к системе. Этот параметр в большей степени влияет на использование ресурсов. Если Вы только запустили БД, устанавливайте это значение небольшим (16…32), по умолчанию он установлен 100. Постепенно можно увеличивать max_connections (по мере необходимости — такой мерой будет получение ошибок от postgresql «too many clients»).
    Учтите! На поддержку каждого активного клиента, PostgreSQL тратит немалое количество ресурсов, и если Вам необходимо добиться производительности в несколько тысяч активных соединений, то стоит использовать менеджеры соединений, например: или .
    Важно! Значение параметра max_wal_senders должно быть меньше max_connections, поэтому если Вы установили max_connections = 10, то max_wal_senders нужно поменять к примеру на 5

    Смотрим на параметр shared_buffers
    Этот параметр определяет, сколько памяти будет выделяться PostgreSQL для кеширования данных.
    В стандартной поставке значение этого параметра 128 МБ, то есть по сути мизерное — для обеспечения совместимости. В практических условиях это значение следует установить в 15..25% от всей доступной оперативной памяти сервера. Учтите, слово всей доступной, то есть учитывайте память которую занимают текущие процессы и могут занять в случае роста потребления, к примеру у нас 8 ГБ ОЗУ и стоит MySQL, который в текущем состоянии занять 1 ГБ ОЗУ, а при росте количества соединений исходя из настроек может занять все 6 ГБ ОЗУ, тогда для PostgreSQL остается не так много памяти и shared_buffers никак нельзя поставить 2 ГБ. Если у Вас большие активные порции базы данных, сложные запросы, большое число одновременных соединений, длительные транзакции, Вам доступен большой объем ОЗУ или большее количество процессоров, то можно увеличивать значение shared_buffers и смотреть результат, чтобы не привести к «деградации» (падению) производительности. Выделив слишком много памяти для shared_buffers, мы можем получить ухудшение производительности, поскольку PostgreSQL также использует кэш операционной системы (увеличение данного параметра более 40% оперативной памяти может давать «нулевой» прирост производительности).

    Параметр effective_cache_size
    Этот параметр помогает планировщику postgresql определить количество доступной памяти для дискового кеширования. На основе того, доступна память или нет, планировщик будет делать выбор между использованием индексов и использованием сканирования таблицы. Это значение следует устанавливать в 50%…75% всей доступной оперативной памяти, в зависимости от того, сколько памяти доступно для системного кеша. Еще раз — этот параметр не влияет на выделяемые ресурсы — это оценочная информация для планировщика.

    Параметры min_wal_size, max_wal_size, checkpoint_timeout, checkpoint_completion_target, wal_buffers
    Существует несколько параметров конфигурации, связанных с WAL, которые влияют на производительность базы данных. На эти и некоторые другие настройки стоит обратить внимание, если у Вас происходит немалое количество записей в БД (для высоконагруженных систем это нормальная ситуация).
    Более подробно следует прочитать или .

    Параметр work_mem
    Важный параметр для запросов, использующих всевозможные сложные выборки и сортировки. Увеличение его
    позволяет выполнять эти операции в оперативной памяти, что гораздо более эффективно, чем на диске (еще бы).
    Если объём памяти недостаточен для сортировки некоторого результата, то серверный процесс будет использовать временные файлы. Если же объём памяти слишком велик, то это может привести к своппингу.
    Будьте внимательны! Это не разделяемая память, work_mem выделяется отдельно на каждую операцию (от одного до нескольких раз за один запрос). Следовательно, если у Вас 10 активных клиентов и каждый выполняет 1 сложный запрос, то значение в 10 МБ для этого параметра скушает 100 МБ оперативной памяти.
    Этот параметр стоит увеличивать, если у Вас большое количество памяти в распоряжении. Чем больше max_connections тем меньше должен быть work_mem. В качестве начального значения для параметра можете взять 2–4% доступной памяти. Для веб-приложений обычно устанавливают низкие значения work_mem, так как запросов обычно много, но они простые, обычно хватает от 512 до 2048 КБ. С другой стороны, приложения для поддержки принятия решений с сотнями строк в каждом запросе и десятками миллионов столбцов в таблицах фактов часто требуют work_mem порядка 500 Мб. Для баз данных, которые используются и так, и так, этот параметр можно устанавливать для каждого запроса индивидуально, используя настройки сессии. Например, при памяти 1–4 ГБ рекомендуется устанавливать 32–128 МБ.

    Параметр synchronous_commit
    Обратите особое внимание на этот параметр! Он включает/выключает синхронную запись в лог файлы после каждой транзакции. Это защищает от возможной потери данных. Но это накладывает ограничение на пропускную способность сервера.
    Допустим, в Вашей системе не критична потенциально низкая возможность потери небольшого количества изменений при крахе системы. Но жизненно важно обеспечить в несколько раз большую производительность по количеству транзакций в секунду. В этом случае устанавливайте этот параметр в off (отключение синхронной записи).

    Параметр maintenance_work_mem
    Задаёт максимальный объём памяти для операций обслуживания БД, в частности VACUUM, CREATE INDEX и ALTER TABLE ADD FOREIGN KEY. По умолчанию его значение - 64 мегабайта (64MB). Так как в один момент времени в сеансе может выполняться только одна такая операция, и обычно они не запускаются параллельно, это значение вполне может быть гораздо больше work_mem. Увеличение этого значения может привести к ускорению операций очистки и восстановления БД из копии, но слишком большие значения приведут к использованию свопа.
    Учтите, что когда выполняется автоочистка, этот объём может быть выделен autovacuum_max_workers раз, поэтому не стоит устанавливать значение по умолчанию слишком большим. Возможно, будет лучше управлять объёмом памяти для автоочистки отдельно, изменяя autovacuum_work_mem.
    Чтобы операции выполнялись максимально быстро, нужно устанавливать этот параметр тем выше, чем больше размер таблиц в вашей БД. Неплохо бы устанавливать его значение от 50 до 75% размера вашей самой большой таблицы или индекса или, если точно определить невозможно, от 32 до 256 МБ. Например, при памяти 1–4 ГБ рекомендуется устанавливать 128–512 МБ.
    Временное увеличение maintenance_work_mem рекомендуют для ускорения загрузки больших объёмов данных в БД. Это приведёт к увеличению быстродействия CREATE INDEX и ALTER TABLE ADD FOREIGN KEY. На скорость самой команды COPY это не повлияет, так что этот совет будет полезен, только если вы применяете какой-либо из двух вышеописанных приёмов.

    Более детально о всех параметрах или .

    Давайте настроим эти параметры исходя из
    — объема свободного ОЗУ в 1 ГБ;
    максимального количества одновременных соединений 10;
    — количество CPU — 1;
    — сервер будет выполнять задачи БД для Web-приложений;
    — база будет располагаться на массиве RAID 1 из 2 дисков SATA HDD;

    Max_connections = 10 shared_buffers = 256MB effective_cache_size = 768MB maintenance_work_mem = 64MB checkpoint_completion_target = 0.7 wal_buffers = 7864kB default_statistics_target = 100 random_page_cost = 4 effective_io_concurrency = 2 work_mem = 26214kB min_wal_size = 1GB max_wal_size = 2GB

    Хочу заметить, что многие настройки PostgreSQL зависят не только от аппаратной конфигурации, но и от размера базы данных, числа клиентов и сложности запросов, так что оптимально настроить базу данных возможно только учитывая все параметры системы и приложения (например учитывать, SSD диски и влезает ли база в память). Для облегчения первоначальной настройки Pg существует от Алексея Васильева.

    Теперь разрешим подключение из локальной сети с любых хостов и к любым БД, для этого в конец файла /etc/postgresql/10/main/pg_hba.conf добавим:

    # localnet host all all 192.168.100.0/24 md5

    Service postgresql restart

    Проверяем открытые порты

    Netstat -ltupn |grep postgre tcp 0 0 192.168.100.4:5432 0.0.0.0:* LISTEN 32658/postgres tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 32658/postgres

    Отлично! Теперь мы можем подключиться к PostgreSQL c локального сервера и из нашей локальной сети.

    На этом все, до скорых встреч.

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