БД — большой кэш. Диски и файловые системы

30.04.2019

Я обещал написать о том, что в проектах с более менее серьезной нагрузкой БД либо помещается в память, либо не работает. Ситуация в современном мире меняется в связи с появлением SSD дисков, но пока что они стоят достаточно дорого, по сравнению со старыми добрыми вращающимися дисками. Чтобы «потрогать» это руками, проделаем несложный тест.

Я завел новую машину с Ubuntu 12.04, на облачном хостинге Amazon размера t1.micro. После этого необходимо поставить 2 пакета: postgresql-contrib-9.1 и ruby.

PostgreSQL contrib содержит, помимо всего прочего, программу pgbench, специально предназначенную для нагрузочного тестирования PostgreSQL.

В postgresql.conf параметр shared_buffers был выставлен в 64MB.

File . open ("res.txt" , "w" ) do | f | (1 .. 50 ). each do | s | # -i означает, что мы создаем чистую БД # -s - это scale factor, определяет размер БД `/usr/lib/postgresql/9.1/bin/pgbench -i -s #{ s } ` # -S - тесты для запросов только на чтение # -T 20 - тест длится 20 секунд # -c 40 - 40 клиентов # -j 4 - 4 потока res = `/usr/lib/postgresql/9.1/bin/pgbench -c 40 -j 4 -S -T 20` puts res f . write res end end

На машинках t1.micro free -m выдает следующее: total used free shared buffers cached Mem: 590 583 6 0 1 428

Именно этим обусловлен такой выбор границ scale factor. Про scale factor = 50 размер БД приблизительно 750Мб, то есть больше количества доступной памяти, а граница shared_buffers пересекается при значениях scale factor 4-5.

Давайте же посмотрим на график.

Данные получились не очень красивыми, но в целом - понятными. Виден провал в районе scale factor 5, а следующий провал в районе scale factor 45. Собственно, две явные ступеньки - выпадание из shared buffers и из дискового кэша.

16 фев 2015

Оптимизация работы PostgreSQL

by Admin

Настройка конфигурации

Настройка ресурсов

shared_buffers

Размер разделяемой между процессами PostgreSQL памяти, которая нужна для выполнения активных операций. Не следует указывать слишком большой объём, так как PostgreSQL использует также дисковый кэш.
Значения:
- Средний объём данных и 256-512 МБ доступной памяти: 16-32 МБ
- Большой объём данных и 1-4 ГБ доступной памяти: 64-256 МБ

temp_buffers
Буфер под временные объекты, в основном для временных таблиц.
Можно установить порядка 16 МБ

max_prepared_transactions
Количество одновременно подготавливаемых транзакций.
Для работы 1С этот параметр значения не имеет, PREPARE TRANSACTION там не используются.
Можно оставить по дефолту - 5

work_mem
Специальная память, используется для сортировки и кэширования таблиц, для одного запроса.
При задании этого параметра следует учитывать количество конкурентных запросов, выполняемых в один момент времени.
При памяти 1-4Gb рекомендуется устанавливать 32-128MB

maintenance_work_mem
Память использующаяся для операций VACUUM, CREATE INDEX, ALTER TABLE и FOREGIN KEY.
Следует устанавливать большее значение, чем для work_mem. Слишком большие значения приведут к использованию свопа.
При памяти 1-4Gb рекомендуется устанавливать 128-512MB

max_stack_depth
Специальный стек для сервера, в идеале он должен совпадать с размером стека, выставленном в ядре ОС. Установка большего значения, чем в ядре, может привести к ошибкам.
Рекомендуется устанавливать 2-4MB

max_fsm_relations
Максимальное количество таблиц, для которых будет отслеживаться свободное место в общей карте свободного пространства. Эти данные собираются VACUUM.
Выставьте параметр в соответствии с количеством таблиц в вашей базе с запасом. (Применимо для версий до 8.4)

max_fsm_pages
Количество блоков, для которых будет хранится информация о свободном месте. Информация хранится в разделяемой памяти, для каждой записи требуется по 6 байт.
Использование этого параметра позволяет избежать использования VACUUM FULL для базы, достаточно будет VACUUM. (Применимо для версий до 8.4)
Этот параметр должен быть не меньше чем 16*max_fsm_relations
Данный параметр задается автоматически при создании базы утилитой initdb
Можно задать его и вручную: в качестве начального приближения можно взять половину от среднего количества записей, изменяемых (UPDATE или DELETE) между запусками команды VACUUM.
Оценить это значение (база должна проработать уже какое-то время) можно выполнив:

vacuum full analyze;
NOTICE: number of page slots needed (196272) exceeds max_fsm_pages (153600)
HINT: Consider increasing the configuration parameter "max_fsm_pages" to a value over 196272.

max_files_per_process
Максимальное количество файлов, открываемых процессом и его подпроцессами в один момент времени.
Уменьшите данный параметр, если в процессе работы наблюдается сообщение "Too many open files ".

Запись транзакционных логов на диск

commit_delay и commit_siblings
Значение commit_delay выражается в микросекундах (0 по умолчанию). Значение commit_siblings выражается в штуках (5 по умолчанию).
commit_delay определяют задержку между попаданием записи в буфер журнала транзакций и сбросом её на диск. Если при успешном завершении транзакции активно не менее commit_siblings транзакций, то запись будет задержана на время commit_delay. Если за это время завершится другая транзакция, то их изменения будут сброшены на диск вместе, при помощи одного системного вызова. Эти параметры позволят ускорить работу, если параллельно выполняется много «мелких» транзакций.

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

fsync=off

то данные не будут записываться на дисковые накопители сразу после завершения операций. Это может существенно повысить скорость операций insert и update, но есть риск повредить базу, если произойдет сбой (неожиданное отключение питания, сбой ОС, сбой дисковой подсистемы).
Используйте эту возможность только если у вас имеются надежные ИБП и программное обеспечение, завершающее работу системы при низком заряде батарей.
Не следует отключать fsync при работе PostgreSQL на Windows платформе, из-за нестабильности системы.

wal_sync_method
Метод, который используется для принудительной записи данных на диск.
Если fsync=off, то этот параметр не используется.

Возможные значения:
open_datasync - запись данных методом open() с параметром O_DSYNC
fdatasync - вызов метода fdatasync() после каждого commit
fsync_writethrough - вызывать fsync() после каждого commit игнорирую паралельные процессы
fsync - вызов fsync() после каждого commit
open_sync - запись данных методом open() с параметром O_SYNC

Не все методы доступны на определенных платформах. По умолчанию устанавливается первый, который доступен в системе.

full_page_writes
Установите данный параметр в off, если fsync=off.
Иначе
Когда этот параметр on, PostgreSQL записывает содержимое каждой страницы в журнал транзакций во время первой модификации таблицы после контрольной точки. Это необходимо потому что страницы могут записаться лишь частично если в ходе процесса ОС "упала". Это приволит к тому, что на диске оказаываются новые данные смешанные со старыми. Строкового уровня записи в журнал транзакций может быть не достаточно, что бы полность восстановить данные после "падения". full_page_writes гарантирует корректное восстановление, ценой увелечения записываемых данных в журнал транзакций.(Потому что журнал транзакций все время начинается с контрольной точки. Единственный способ снижения объема записи заключается в увеличении checkpoint interval).

wal_buffers
Количество памяти используемое в SHARED MEMORY для ведения транзакционных логов.
При доступной памяти 1-4GB рекомендуется устанавливать 256-1024kb

Оптимизация запросов

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

random_page_cost
Устанавливает у планировщика оценку "стоимоти" не последовательного перебора данных. По умолчанию 4.0. Уменьшение этого значения по отношению к seq_page_cost вызовет у планировщика предпочтение сканирования индекса, увеличение -- наобород сделает сканирование индекса "дороже". Вы можете изменить оба значения чтобы изменить отношение "стоимости" дисковых операций ввода/выдода, по отношениб с "стоимости" использования процессора, которая бадет описана следующими параметрами.

На серверах с быстрыми дисковыми массивами имеет смысл уменьшать изначальную настройку до 3.0, 2.5 или даже до 2.0. Если же активная часть вашей базы данных много больше размеров оперативной памяти, попробуйте поднять значение параметра. Можно подойти к выбору оптимального значения и со стороны производительности запросов. Если планировщик запросов чаще, чем необходимо, предпочитает последовательные просмотры (sequential scans) просмотрам с использованием индекса (index scans), понижайте значение. И наоборот, если планировщик выбирает просмотр по медленному индексу, когда не должен этого делать, настройку имеет смысл увеличить. После изменения тщательно тестируйте результаты на максимально широком наборе запросов. Никогда не опускайте значение random_page_cost ниже 2.0; если вам кажется, что random_page_cost нужно еще понижать, разумнее в этом случае менять настройки статистики планировщика.

cpu_tuple_cost
Устанавливает у планировщика оценку "стоимоти" затрат на обработку каждой строки во время выполнения запроса. По умолчанию 0,01.

cpu_index_tuple_cost
Устанавливает у планировщика оценку "стоимоти" затрат на обработку каждого индекса во время операции сканирования индекса. По умолчанию 0,005

cpu_operator_cost
Устанавливает у планировщика оценку "стоимоти" затрат на выполнение каждого оператора или функции во время выполнения запроса. По умолчанию 0.0025.

effective_cache_size
Передает данные планировщику запросов об объёме памяти, которая используется ОС для кэширования файлов, для одного запроса.
Этот параметр в ОС можно посмотреть в настройках:
Для Windows: в Диспетчере задач, Закладка Быстродействие, Физическая память-Системный кэш.
Для Linux: наберите команду free, необходимое значение в столбце cached (в kB)

Данное значение необходимо разделить на количество конкурентных запросов в один момент времени (среднее количество подключений к базе + запас).

default_statistics_target
Устанавливает глубину статистики по таблицам. БОльшие значения могут повысить время выполнения команды ANALYZE, но улучшат построение плана запроса.
Рекомендуется устанавливать порядка 100.

constraint_exclusion
Включает или отключает использование планером ограничений CONSTRAINT в таблицах при построении запросов.
Рекомендуется установить значение on, при этом, если Вы изменяете CONSTRAINT у таблиц, необходимо обновить их статистику выполнив ANALYZE, в противном случае будут построены неверные планы запросов.

Сбор статистики

stats_command_string
Передавать ли сборщику статистики информацию о текущей выполняемой команде и времени начала её выполнения.
Устанавливать on

stats_start_collector
Включать ли сбор статистики.
Устанавливать on

stats_row_level, stats_block_level
Собирать ли информацию об активности на уровне записей и блоков соответственно.
Устанавливать
stats_row_level=on
stats_block_level=off

stats_reset_on_server_start
Обнулять ли статистику при перезапуске сервера
Устанавливать off

Автовакуум

VACUUM - сборка "мусора". VACUUM восстанавливает место занятые "мертвыми" данными. При выполнении обычных операций с данными, PostgreSQL не удаляет данные физически из таблиц, это происходит с операцией VACUUM.

autovacuum
Включать ли автовакуум (автоматического запуска VACUUM),
устанавливать on

autovacuum_naptime
Пауза между запусками Автовакуума.
Зависит от того, как часто обновляются данные в ваших таблицах. Может соствлять порядка 5min, по умолчанию 1min

autovacuum_analyze_threshold
Определяет минимальное количество вставок, обновлений или удалений необходимых для посылки сигнала на запуск ANALYZE в любой таблице. Этот параметр может быть изменен для отдельных таблиц путем изменения параметров хранения.

autovacuum_vacuum_threshold
Определяет минимальное количество вставок, обновлений или удалений необходимых для посылки сигнала на запуск VACUUM в любой таблице. Этот параметр может быть изменен для отдельных таблиц путем изменения параметров хранения.

Блокировки

max_locks_per_transaction
Количество блокировок за одну транзакцию:
установить порядка 250

deadlock_timeout
Время жизни взаимных блокировок.
Установить порядка 2 секунд.

Возможная ошибка
После исправления файла конфигурации PostgreSQL может не запуститься, выдав ошибку:

FATAL: could not create shared memory segment:...
Failed system call was shmget(key=5432001, size=140075008, 03600).
This error usually means that PostgreSQL"s request for a shared memory segment exceeded your kernel"s SHMMAX parameter. You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 140075008 bytes), reduce PostgreSQL"s shared_buffers parameter (currently 16384) and/or its max_connections parameter (currently 10).
If the request size is already small, it"s possible that it is less than your kernel"s SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.
The PostgreSQL documentation contains more information about shared memory configuration.

Для исправления необходимо увеличить параметр SHMMAX в системе. Сделать это можно следующим образом (для ОС Linux):

Выполните команду:

echo 150829120 > /proc/sys/kernel/shmmax

указав свое новое значение для параметра (какое именно - можно посмотреть в логе ошибки PostgreSQL). Данная операция устанавливает параметр на лету, но после перезагрузки системы изменения будут потеряны. Чтобы этого не происходило, внесите в файл /etc/sysctl.conf следующую строку:

kernel.shmmax = 150829120

указав своё значение.

Пример конфигурации для сервера с 2G оперативной памяти

Средняя настройка

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

RAM -- размер памяти

* shared_buffers = 1/8 RAM или больше (но не более 1/4);
* work_mem в 1/20 RAM;
* maintenance_work_mem в 1/4;
* max_fsm_relations в планируемое кол-во таблиц в базах * 1.5;
* max_fsm_pages в max_fsm_relations * 2000;
* fsync = true;
* wal_sync_method = fdatasync;
* commit_delay = от 10 до 100 ;
* commit_siblings = от 5 до 10;
* effective_cache_size = 0.9 от значения cached, которое показывает free;
* random_page_cost = 2 для быстрых cpu, 4 для медленных;
* cpu_tuple_cost = 0.001 для быстрых cpu, 0.01 для медленных;
* cpu_index_tuple_cost = 0.0005 для быстрых cpu, 0.005 для медленных;
* autovacuum = on
* autovacuum_vacuum_threshold = 1800
* autovacuum_analyze_threshold = 900

Обслуживание базы

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

VACUUM выполняется автоматически, в соответствии с настройками в файле конфигурации.

VACUUM FULL выполнять не обязательно при правильно настроенном автовакууме.

Диски и файловые системы

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

Остановите сервер.
Перенесите каталоги pg_clog и pg_xlog, находящийся в каталоге с базами данных, на другой диск.
Создайте на старом месте символическую ссылку.
Запустите сервер.

Вопросу, какая же СУБД - 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 в связке с сервером 1С:Предприятия в сравнении с тем же MS SQL оставляет желать лучшего. Эта статья продолжение попыток добиться достойной производительности на PostgreSQL. Хотя на данный момент у меня не получилось добиться производительности сопоставимой MS SQL, но думаю в недалеком будущем эта проблема будет решена.

Основные параметры PostgreSQL.

shared_buffers

Объём совместно используемой памяти, выделяемой PostgreSQL для кэширования данных, определяется числом страниц shared_buffers по 8 килобайт каждая. Следует учитывать, что операционная система сама кэширует данные, поэтому нет необходимости отводить под кэш всю наличную оперативную память. Размер shared_buffers зависит от многих факторов, для начала можно принять следующие значения:

8–16 Мб – Обычный настольный компьютер с 512 Мб и небольшой базой данных,
80–160 Мб – Небольшой сервер, предназначенный для обслуживания базы данных с объёмом оперативной памяти 1 Гб и базой данных около 10 Гб,
400 Мб – Сервер с несколькими процессорами, с объёмом памяти в 8 Гб и базой данных занимающей свыше 100 Гб обслуживающий несколько сотен активных соединений одновременно.

work_mem

Под каждый запрос выделяется ограниченный объём памяти. Этот объём используется для сортировки, объединения и других подобных операций. При превышении этого объёма сервер начинает использовать временные файлы на диске, что может существенно снизить производительность. Оценить необходимое значение для work_mem можно разделив объём доступной памяти (физическая память минус объём занятый под другие программы и под совместно используемые страницы shared_buffers) на максимальное число одновременно используемых активных соединений.

maintenance_work_mem

Эта память используется для выполнения операций по сбору статистики ANALYZE , сборке мусора VACUUM , создания индексов CREATE INDEX и добавления внешних ключей. Размер памяти выделяемой под эти операции должен быть сравним с физическим размером самого большого индекса на диске.

effective_cache_size

PostgreSQL в своих планах опирается на кэширование файлов, осуществляемое операционной системой. Этот параметр соответствует максимальному размеру объекта, который может поместиться в системный кэш. Это значение используется только для оценки. effective_cache_size можно установить в ½ - 2/3 от объёма имеющейся в наличии оперативной памяти, если вся она отдана в распоряжение PostgreSQL.

ВНИМАНИЕ! Следующие параметры могут существенно увеличить производительность работы PostgreSQL. Однако их рекомендуется использовать только если имеются надежные ИБП и программное обеспечение, завершающее работу системы при низком заряде батарей.

fsync

Данный параметр отвечает за сброс данных из кэша на диск при завершении транзакций. Если установить в этом параметре значение off , то данные не будут записываться на дисковые накопители сразу после завершения операций. Это может существенно повысить скорость операций insert и update , но есть риск повредить базу, если произойдет сбой (неожиданное отключение питания, сбой ОС, сбой дисковой подсистемы).

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

Возможные значения:

open_datasync – запись данных методом open() с параметром O_DSYNC ,
fdatasync – вызов метода fdatasync() после каждого commit ,
fsync_writethrough – вызывать fsync() после каждого commit игнорирую параллельные процессы,
fsync – вызов fsync() после каждого commit ,
open_sync – запись данных методом open() с параметром O_SYNC .

ПРИМЕЧАНИЕ! Не все методы доступны на определенных платформах. Выбор метода зависит от операционной системы под управлением, которой работает PostgreSQL.

В состав PostgreSQL входит утилита pg_test_fsync , с помощью которой можно определить оптимальное значение параметра wal_sync_method .

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

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

CPU: Intel Core i3-3220 @ 3.30GHz x 2
RAM: 4GB
HDD: Seagate ST3320418AS 320GB

Тест на Windows:

ОС: Windows 7 Максимальная x64
ФС: NTFS
СУБД: PostgreSQL 9.4.2-1.1C x64

C:\PROGRA~1\POSTGR~1\9.4.2-1.1C\bin>pg_test_fsync 5 seconds per test is Linux"s default) open_datasync 48817.440 ops/sec 20 usecs/op fdatasync n/a fsync 79.688 ops/sec 12549 usecs/op fsync_writethrough 80.072 ops/sec 12489 usecs/op open_sync n/a (in wal_sync_method preference order, except fdatasync is Linux"s default) open_datasync 24713.634 ops/sec 40 usecs/op fdatasync n/a fsync 78.690 ops/sec 12708 usecs/op fsync_writethrough 79.073 ops/sec 12646 usecs/op open_sync n/a 1 * 16kB open_sync write n/a 2 * 8kB open_sync writes n/a 4 * 4kB open_sync writes n/a 8 * 2kB open_sync writes n/a 16 * 1kB open_sync writes n/a on a different descriptor.) write, fsync, close 76.493 ops/sec 13073 usecs/op write, close, fsync 77.676 ops/sec 12874 usecs/op Non-Sync"ed 8kB writes: write 1800.319 ops/sec 555 usecs/op

По результатам теста мы видим, что для Windows оптимальным решением будет использование open_datasync .

Тест на Linux:

ОС: Debian 8.6 Jessie
Ядро: x86_64 Linux 3.16.0-4-amd64
ФС: ext4
СУБД: PostgreSQL 9.4.2-1.1C amd64

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

/usr/lib/postgresql/9.4/bin# ./pg_test_fsync 5 seconds per test O_DIRECT supported on this platform for open_datasync and open_sync. Compare file sync methods using one 8kB write: (in wal_sync_method preference order, except fdatasync is Linux"s default) open_datasync 80.215 ops/sec 12467 usecs/op fdatasync 80.349 ops/sec 12446 usecs/op fsync 39.384 ops/sec 25391 usecs/op fsync_writethrough n/a open_sync 40.013 ops/sec 24992 usecs/op Compare file sync methods using two 8kB writes: (in wal_sync_method preference order, except fdatasync is Linux"s default) open_datasync 40.033 ops/sec 24980 usecs/op fdatasync 77.264 ops/sec 12943 usecs/op fsync 36.325 ops/sec 27529 usecs/op fsync_writethrough n/a open_sync 19.659 ops/sec 50866 usecs/op Compare open_sync with different write sizes: (This is designed to compare the cost of writing 16kB in different write open_sync sizes.) 1 * 16kB open_sync write 38.697 ops/sec 25842 usecs/op 2 * 8kB open_sync writes 17.356 ops/sec 57616 usecs/op 4 * 4kB open_sync writes 8.996 ops/sec 111156 usecs/op 8 * 2kB open_sync writes 4.552 ops/sec 219686 usecs/op 16 * 1kB open_sync writes 2.218 ops/sec 450930 usecs/op Test if fsync on non-write file descriptor is honored: (If the times are similar, fsync() can sync data written on a different descriptor.) write, fsync, close 34.341 ops/sec 29120 usecs/op write, close, fsync 35.753 ops/sec 27970 usecs/op Non-Sync"ed 8kB writes: write 484193.516 ops/sec 2 usecs/op

По результатам теста мы видим, что наилучшую скорость выдают методы fdatasync и open_datasync . Так же можно заметить, что на же оборудовании Linux выдал скорость записи почти в половину больше, чем на Windows.

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

wal_buffers

Количество памяти используемое в SHARED MEMORY для ведения транзакционных логов. При доступной памяти 1-4 Гб рекомендуется устанавливать 256-1024 Кб. Этот параметр стоит увеличивать в системах с большим количеством модификаций таблиц базы данных.

checkpoint_segments

Oпределяет количество сегментов (каждый по 16 МБ) лога транзакций между контрольными точками. Для баз данных с множеством модифицирующих данные транзакций рекомендуется увеличение этого параметра. Критерием достаточности количества сегментов является отсутствие в логе предупреждений (warning) о том, что контрольные точки происходят слишком часто.

full_page_writes

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

synchronous_commit

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

Еще одним способом увеличения производительности работы PostgreSQL является перенос журнала транзакций (pg_xlog) на другой диск. Выделение для журнала транзакций отдельного дискового ресурса позволяет получить получить при этом существенный выигрыш в производительности 10%-12% для нагруженных OLTP систем.

В Linux это делается с помощью создания символьной ссылки на новое положение каталога с журналом транзакций.

В Windows можно использовать для этих целей утилиту Junction . Для этого надо:

Остановить PostgreSQL.
Сделать бэкап C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog .
Скопировать C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog в D:\pg_xlog и удалить C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog .
Распаковать программу Junction в C:\Program Files\PostgreSQL\X.X.X\data .
Открыть окно CMD , перейти в C:\Program Files\PostgreSQL\X.X.X\data и выполнить junction -s pg_xlog D:\pg_xlog .
Установить права на папку D:\pg_xlog пользователю postgres.
Запустить PostgreSQL.
Где X.X.X - версия используемой PostgreSQL.

Особенности и ограничения в 1С:Предприятие при работе с PostgreSQL.

Использование конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ.

В СУБД PostgreSQL реализована только частичная поддержка FULL OUTER JOIN (ERROR: “FULL JOIN is only supported with mergejoinable join conditions”). Для реализации полной поддержки FULL OUTER JOIN при работе 1С:Предприятия 8 с PostgreSQL подобный запрос трансформируется в другую форму с эквивалентным результатом, однако эффективность использования конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ снижается.

Оптимизация использования виртуальной таблицы СрезПоследних при работе с PostgreSQL.

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

Решение: Если в запросе используется соединение с виртуальной таблицей языка запросов 1С:Предприятия СрезПоследних и запрос работает с неудовлетворительной производительностью, то рекомендуется вынести обращение к виртуальной таблице в отдельный запрос с сохранением результатов во временной таблице.

Решение проблемы с зависанием PostgreSQL.

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

Варианты решения проблемы:

Увеличить количество записей, просматриваемых при сборе статистики по таблицам. Большие значения могут повысить время выполнения команды ANALYZE , но улучшат построение плана запроса:
- Файл postgresql.conf - default_statistics_target = 1000 -10000 .
Отключение оптимизатору возможности использования NESTED LOOP при выборе плана выполнения запроса в конфигурации PostgreSQL:
- Файл postgresql.conf - enable_nestloop = off .
- Отрицательным эффектом этого способа является возможное замедление некоторых запросов, поскольку при их выполении будут использоваться другие, более затратные, методы соединения (HASH JOIN).
Отключение оптимизатору возможности изменения порядка соединений таблиц в запросе:
- Файл postgresql.conf - join_collapse_limit=1 .
- Следует использовать этот метод, если вы уверены в правильности порядка соединений таблиц в проблемном запросе.
Изменение параметров настройки оптимизатора:
- Файл postgresql.conf:
  - seq_page_cost = 0.1
  - random_page_cost = 0.4
  - cpu_operator_cost = 0.00025
Использование версии PostgreSQL 9.1.2-1.1.C и выше, в которой реализован независимый от AUTOVACUUM сбор статистики, на основе информации об изменении данных в таблице. По умолчанию включен сбор статистики только для временных таблиц и во многих ситуациях этого достаточно. При возникновении проблем с производительностью выполнения регламентных операций, можно включить сбор статистики для всех или отдельных проблемных таблиц изменив значение параметра конфигурации PostgreSQL (файл postgresql.conf ) online_analyze.table_type = "temporary" на online_analyze.table_type = "all" . мне товарищ Vasiliy P. Melnik. Несмотря на то, что интерфейс на английском, он простой и интуитивно понятный. Думаю каждый желающий сможет с ним разобраться.