БД — большой кэш. Комментариев нет
По умолчанию PostgreSQL настроен таким образом, чтобы расходовать минимальное количество ресурсов для работы с небольшими базами до 4 Gb на не очень производительных серверах. То есть, если дело касается систем посерьезней, то вы столкнетесь с большими потерями производительности базы данных лишь потому, что дефолтные настройки могут в корне не соответствовать производительности вашего северного оборудования. Настройки выделения ресурсов оперативной памяти RAM для работы PostgreSQL хранятся в файле postgresql.conf .
Доступен как из папки, куда установлен PostgreSQL / Data, так и из pgAdmin:
В общем на начальном этапе при возникновении трудностей и замедления работы БД, заметной для глаз пользователей достаточно увеличить три параметра:
shared_buffers
Это размер памяти, разделяемой между процессами PostgreSQL, отвечающими за выполнения активных операций. Максимально-допустимое значение этого параметра – 25% всего количества RAM
Например, при 1-2 Gb RAM на сервере, достаточно указать в этом параметре значение 64-128 Mb (8192-16384).
temp_buffers
Это размер буфера под временные объекты (временные таблицы). Среднее значение 2-4% всего количества RAM
Например, при 1-2 Gb RAM на сервере, достаточно указать в этом параметре значение 32-64 Mb.
work_mem
Это размер памяти, используемый для сортировки и кэширования таблиц.
Для вступления новых значений в силу, потребуется перезапуск службы, поэтому лучше делать во вне рабочее время.
Еще два важных параметра это maintenance_work_mem (для операций VACUUM, CREATE INDEX и других) и max_stack_depth
Примеры оптимальных настроек:
- CPU: E3-1240 v3 @ 3.40GHz
- RAM: 32Gb 1600Mhz
- Диски: Plextor M6Pro
postgresql.conf:
- shared_buffers = 8GB
- work_mem = 128MB
- maintenance_work_mem = 2GB
- fsync = on
- synchronous_commit = off
- wal_sync_method = fdatasync
- checkpoint_segments = 64
- seq_page_cost = 1.0
- random_page_cost = 6.0
- cpu_tuple_cost = 0.01
- cpu_index_tuple_cost = 0.0005
- cpu_operator_cost = 0.0025
- effective_cache_size = 24GB
Полезные запросы:
Блокировки БД по пользователям
Вывести все таблицы, размером больше 10 Мб
from pg_tables
where tableName not like ‘sql_%’ and pg_size_pretty(pg_total_relation_size(CAST(tablename as text))) like ‘%MB%’;
Определение размеров таблиц в базе данных PostgreSQL
Код SQL SELECT tableName, pg_size_pretty(pg_total_relation_size(CAST(tablename as text))) as size
from pg_tables
where tableName not like ‘sql_%’
order by size;
Пользователи блокирующие конкретную таблицу
Код SQL select a.usename, t.relname, a.current_query, mode from pg_locks l inner join pg_stat_activity a on a.procpid = l.pid inner join pg_stat_all_tables t on t.relid=l.relation where t.relname = ‘tablename’; Код SQL select relation::regclass, mode, a.usename, granted, pid from pg_locks l inner join pg_stat_activity a on a.procpid = l.pid where not mode = ‘AccessShareLock’ and relation is not null;
Запросы с эксклюзивными блокировками
Код SQL select a.usename, a.current_query, mode from pg_locks l inner join pg_stat_activity a on a.procpid = l.pid where mode ilike ‘%exclusive%’;
Количество блокировок по пользователям
Код SQL select a.usename, count(l.pid) from pg_locks l inner join pg_stat_activity a on a.procpid = l.pid where not(mode = ‘AccessShareLock’) group by a.usename;
Количество подключений по пользователям
Код SQL select count(usename), usename from pg_stat_activity group by usename order by count(usename) desc;
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), показало другие результаты .
Установка 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.bz24.Перед установкой дистрибутива СУБД PostgreSQL проверим наличие в системе необходимой локали (по умолчанию ru_RU.UTF-8):
5.Если система, с которой будет работать PostgreSQL, ставилась с языком отличным от русского, необходимо создать новые локали:
locale-gen ru_RU update-locale LANG=ru_RU.UTF8 dpkg-reconfigure locales6.Если необходимая локаль все же имеется, устанавливаем ее по умолчанию:
locale –a nano /etc/default/locale Заменяем содержимое на LANG=ru_RU.UTF-87.После перезагрузки, установим необходимые пакеты для нашей версии PostgreSQL:
apt-get install libxslt1.1 ssl-cert8.Версия 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.deb11.Готово. Дистрибутив СУБД 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.
Появилась у нас в конторе мегапрограмма по оперативному учету. Программеры ее уже год как ваяют, практически все работники конторы в ней заняты, без нее в облэнерго сейчас жизни нет. Не работает программа - контора в определенном смысле парализована.
Сейчас в системе около 700 пользователей, при этом активных бывает до 100 рыл.
Естественно вопрос производительности сейчас первостепенный (если считать с нуля, то задача номер 0 отказоустойчивость будет решена в ближайшее время). Моя задача как админа выжать все возможное из базы данных. Это PostgreSQL версии 8.2, с которого сейчас осуществляется тестовая миграция на 9.0.
Здесь будет приведен файл параметров postgresql.conf с расширенными комментариями по каждому пункту.
Установка каждого параметра выбиралась исходя из существующего опыта эксплуатации, исследования открытых источников, как минимум 3-х, официальной документации, а также тестов производительности приложения на сервере в максимально идентичными настройками БД 8.2. и 9.0.
# Файл параметров PostgreSQL postgresql.conf
# Попытка заставить базу EnergyNET летать соколом.
# Указаные настройки подразумевают, что на сервере, где
# крутится PostgreSQL никого кроме него нет, не считая
# операционной системы.
#########################################################
# shared_buffers
#
# Смысл параметра: PostgreSQL не читает данные напрямую
# с диска и не пишет их сразу на диск. Данные загружаются
# в общий буфер сервера, находящийся в разделяемой памяти,
# серверные процессы читают и пишут блоки в этом буфере,
# а затем уже изменения сбрасываются на диск.
# Если процессу нужен доступ к таблице, то он сначала
# ищет нужные блоки в общем буфере. Если блоки
# присутствуют, то он может продолжать работу, если
# нет — делается системный вызов для их загрузки.
# Загружаться блоки могут как из файлового кэша ОС, так и
# с диска, и эта операция может оказаться весьма «дорогой».
# Если объём буфера недостаточен для хранения часто
# используемых рабочих данных, то они будут постоянно
# писаться и читаться из кэша ОС или с диска, что крайне
# отрицательно скажется на производительности.
# Принцип таков, что значение параметра устанавливаем
# в размере 25-40% от оперативной памяти. От версии
# PostgreSQL не зависит.
#
shared_buffers = 500MB # 2GB ОЗУ
#shared_buffers = 3000MB # 12GB ОЗУ
# temp_buffers
#
# Смысл параметра: Максимальное количество памяти, выделяемой
# каждой сессии для работы с временными таблицами.
# Необходимо помнить, что как только сессия заняла размер,
# указанный в temp_buffers, эта память не освобождается,
# пока сессия не завершится. На системах с большим
# количеством одновременно работающих пользователей
# некорректное (завышенное) значение этого параметра
# запросто может привести к бешеному свопу, и как
# следствие, краху операционной системы. А если при
# этом еще и fsync = off, то готовьтесь восстанавливать
# базу из резервных копий.
# У нас временные таблицы не используются, так что
# можно оставить значение по умолчанию. То есть
# вообще удалить из postgresql.conf
#
temp_buffers = 8MB
# max_prepared_transactions
#
# Смысл параметра: устанавливает максимальное количество
# PREPARED TRANSACTION которые могут устанавливаться в
# состояние prepared единовременно.
# У нас 98% всех транзакций - PREPARED.
# Минимально необходимое значение параметра = max_connections
#
max_prepared_transactions = 600
# work_mem
#
# Смысл параметра: Задаёт объём памяти, который используют
# внутренние операции сортировки и хэш-таблицы перед тем
# как перейти на использование временных файлов на диске.
# Если объём памяти недостаточен для сортироки некоторого
# результата, то серверный процесс будет использовать
# временные файлы. Если же объём памяти слишком велик,
# то это может привести к своппингу.
# В сложном запросе параллельно может быть запущено несколько
# операций сортировки и хэширования, и каждая может занять
# столько памяти, сколько задано в этом параметре, прежде
# чем начнет использовать временные файлы. Кроме того, эти
# операции могут одновременно выполняться в нескольких сессиях.
# Таким образом, используемая память может оказаться в несколько
# раз больше, чем work_mem. Операции сортировки используются
# для ORDER BY, DISTINCT и операций соединения методом
# слияния (merge joins). Хэш-таблицы используются при
# операциях соединения методом хэширования (hash joins),
# операциях аггрегирования, основанных на хэшировании и
# обработке IN-подзапросов на основе хэширования.
# Своими словами: если некая операция из перечисленных выше требует
# для выполнения больше памяти, чем указано в параметре work_mem,
# для этой операции будет создан временный файл в каталоге pgsql_tmp
# соответствующей БД. Так что оценить, какой объем необходимо задать
# данному параметру можно просто влянув в этот каталог в пиковые
# часы нагрузки. Если суммарный объем созданных там файлов поместится
# в оперативную память и останется хотя-бы 30% резерва, с учетом
# остальных работающих на сервере задач, то можно задавать значение, равное
# размеру примерно одинаковых по объему файлов. Тут конечно тоже без
# фанатизма, ибо если временный файл больше 100 метров, то нужно
# трижды подумать...
#
work_mem = 32MB
# autovacuum
#
# Смысл простой - выполнение процессов VACUUM в автоматическом
# режиме во время работы сервера.
# У нас VACUUM и ANALYZE будут выполняться ночью
# через CRON, так что включать автовакуум не будем.
# Ну незачем нам еще и в рабочее время систему
# нагружать некритичными вещами.
#
autovacuum = off
# effective_io_concurrency
#
# Смысл параметра: Задаёт число операций чтения/записи на
# диск, которые по мнению PostgreSQL могут выполняться
# одновременно. Увеличение этого значения может повысить
# число операций ввода/вывода, которое любая сессия
# PostgreSQL может попытаться выполнить параллельно.
# Допустимые значения лежат в диапазоне от 1 до 1000,
# либо 0, если вы хотите запретить выполнение асинхронных
# операций ввода/вывода.
# Для оценки необходимого значения этого параметра можно
# начать с числа отдельных устройств, включая RAID 0
# или RAID 1, используемых базой данных. Для RAID 5
# чётность устройств не учитывается. Однако, если база
# данных часто занята множеством запросов, получаемых от
# различных одновременных сессий, даже низкие значения
# могут держать занятым дисковый массив. Значение выше
# необходимого для поддержания занятости дисков приведёт
# только к дополнительной загрузке процессора.
# По простому, ставим значение параметра в число,
# равное количеству шпинделей в дисках, на
# которых расположена база данных. Потом пробуем уменьшить
# или увеличить, и оцениваем результат при каждом изменении
# параметра. Вообще параметр новый, малоопробованый,
# рекомендаций мало. Так что будем тестировать.
#
effective_io_concurrency = 4 # 4 диска в RAID10
# fsync
#
# Смысл параметра: Данный параметр отвечает за сброс данных
# из кэша на диск при завершении транзакций. Если
# установить его значение fsync = off то данные не будут
# записываться на дисковые накопители сразу после завершения
# операций. Это может существенно повысить скорость
# операций insert и update, но есть риск повредить базу,
# если произойдет сбой (неожиданное отключение питания,
# сбой ОС, сбой дисковой подсистемы).
# Самый сука стремный параметр. Если есть возможность,
# ВСЕГДА используйте fsync = on. Если с производительностью
# жопа, то при значении off большую часть проблем можно
# порешать. Вот такая неоднозначная хрень. На винде
# желательно его не выключать в следствии глючности самой
# винды.
# Если fsync = off, то обязательно установить
# full_page_writes = off
# Если fsync = on, а с производительность проблемы, то
# лучше поиграться с synchronous_commit, но fsync не
# трогать.
#
fsync = on
# full_page_writes
#
# Смысл параметра: Если этот параметр включен, сервер
# PostgreSQL пишет весь контент каждой страницы диска в WAL
# во время первого изменения этой страницы после контрольной
# точки. Это необходимо, поскольку если в процессе записывания
# страницы произойдет системный сбой, на диске может оказаться
# страница, в которой смешаны старые и новые данные. Изменения
# на уровне строк данных, которые обычно хранятся в WAL, может
# быть не достаточно для восстановления страницы после
# системного сбоя. Хранение образа всей страницы гарантирует,
# что страница будет восстановлена правильно, но это будет
# стоить увеличения количества данных, которые нужно будет
# занести в WAL. (Так как чтение WAL всегда начинается с
# контрольной точки, удобно делать это при первом изменении
# каждой страницы после контрольной точки. Таким образом,
# одним из способов уменьшения стоимости записи страниц
# является увеличение интервала между контрольными точками.)
# Отключение этого параметра ускоряет работу, но может привести
# к повреждению базы данных в случае системного сбоя или
# отключения питания. Риски схожи с отключением fsync, хотя в
# данном случае они меньше.
#
full_page_writes=on
# synchronous_commit
#
# Смысл параметра: Определяет, должна ли транзакция ждать,
# пока записи WAL будут перенесены на диск, прежде чем команда
# вернёт клиенту сообщение об успешном выполнении. По
# умолчанию и с точки зрения безопасности этот параметр должен
# быть включен. Если параметр выключен, возможен промежуток
# времени между сообщением об успешном выполнении транзакции
# и моментом, когда транзакция на самом деле защищена от сбоя
# на сервере. В отличие от fsync, отключение этого параметра
# не может привести к риску противоречия в базе данных: сбой
# может привести к потере последних прошедших транзакций, но
# состояние базы данных при этом будет таким, как будто эти
# транзакции просто были прерваны. Таким образом, отключение
# synchronous_commit может оказаться полезным, если
# производительность важнее, чем точность в проведении
# транзакций.
#
synchronous_commit = off
effective_cache_size: указывает планировщику на размер самого большого объекта в базе данных, который теоретически может быть закеширован. На выделенном сервере имеет смысл выставлять effective_cache_size в 2/3 от всей оперативной памяти; на сервере с другими приложениями сначала нужно вычесть из всего объема RAM размер дискового кэша ОС и память, занятую остальными процессами.
Я обещал написать о том, что в проектах с более менее серьезной нагрузкой БД либо помещается в память, либо не работает. Ситуация в современном мире меняется в связи с появлением 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 и из дискового кэша.