Сервер:Советы по оптимизации
Содержание |
Советы по оптимизации
При большом количестве приборов (600-700 и более) и больших объёмах БД (десятки гигабайт) возникает необходимость в более тонкой настройке Постгреса и самого Локарус-сервера.
Что касается БД:
В настройках Постгреса (postgresql.conf в каталоге с БД) следует установить:
- max_connections = 100-500 в зависимости от производительности железа. Это количество одновременных коннектов к БД. Чем их больше, тем теоретически быстрее должна происходить обработка данных, но тем больше требуется ресурсов. Так что тут нужно искать компромисс.
- max_prepared_transactions = 100-500 параметр определяет максимальное к-во заранее подготовленных транзакций. До 80% запросов используемых сервером являются подготовленными, поэтому если увеличивается количество коннектов (параметром max_connections) то этот параметр нужно установить как минимум равным количеству коннектов.
- shared_buffers = 64MB-4GB зависит от количества ОЗУ в сервере. shared_buffers — это кэш, доступный для всех процессов Постгреса. Чем он больше — тем лучше. Рекомендуется 1/8 RAM или больше (но не более ¼). По умолчанию в линуксах на GENERIC ядре стоит небольшое значение параметра sysctl kernel.shmmax. Для его увеличения нужно добавить в файл /etc/sysctl.conf две строки:
kernel.shmall = 2097152 kernel.shmmax = 4294967296
И перечитать изменения командой : sysctl -p Для проверки внесенных изменений выполните команду : ipcs -l
Если все это не спасает, переходим к радикальным мерам:
- synchronous_commit = off отключает синхронную запись транзакции. Иными словами сервер будет думать что данные сохранены в базе, но на самом деле их запись будет отложена до более "комфортного" для системы момента. Использование этого параметра достаточно безопасно, т.к. даже в случае аппаратного сбоя целостность базы не пострадает, просто не будет завершена текущая рранзакция
- fsync = off отключает синхронный сброс результатов транзакции на физическом уровне. Этот параметр может радикально ускорить систему, но при этом никакой защиты от сбоев. В случае аварии можно запросто получить убитую базу данных. Если вы всетаки решились установить fsync в off, обязательно установите full_page_writes = off. Но лучше все таки ограничиться synchronous_commit.
Можно на этом ограничится настройкой БД, но можно и попробовать изменить эти параметры:
- work_mem в 1/20 RAM;
- maintenance_work_mem в 1/4;
- max_fsm_relations в планируемое кол-во таблиц в базах * 1.5;
- max_fsm_pages в max_fsm_relations * 2000;
- 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
еще интересный параметр
- effective_io_concurrency - число операций чтения/записи на диск, которые по мнению постгрес могут выполняться одновременно. Если вы используете, например, RAID10 c четырьмя блинами, можно попробовать установить этот параметр в 4.
Обслуживание базы:
VACUUM выполняется автоматически, в соответствии с настройками в файле конфигурации. VACUUM FULL выполнять не обязательно при правильно настроенном автовакууме.
Вообще автовакуум выполняется когда postgres считает что пришло время, на текущую нагрузку особо внимания не обращает. Возможно есть смысл отключить его с помошью autovacuum = off, а вакуум запускать, например, ночью по cron.
Диски и файловые системы
Если в вашем сервере есть несколько физических дисков, то вы можете разнести файлы базы данных и журнал транзакций по разным дискам: Остановите сервер. Перенесите каталоги pg_clog и pg_xlog, находящийся в каталоге с базами данных, на другой диск. Создайте на старом месте символическую ссылку. Запустите сервер.
Также желательно делать бэкап БД на случай её разрушения из-за краха винта или другим причинам.
Что касается сервера Locarus:
При больших нагрузках можно попробовать изменить следующие параметры:
Режим работы с БД:
DBCN_RING_ENABLE=true DBCN_RING_LIMIT=70
Если DBCN_RING включен - сервер будет формировать из коннектов кольцевой список указанного размера, и для каждого нового требуемого коннекта выделять следующий по порядку. Т.о. нагрузка сравнительно равномерно распределяется по соединениям.
Если DBCN_RING выключен коннекты к базе можно распределить по функциональным модулям: контроль кол-ва коннектов к базе:
DYNAMIC_DBCN_DEVICE=false - отдельный коннект для каждого устройства DYNAMIC_DBCN_RECEIVER=false - для каждого драйвера приемника DYNAMIC_DBCN_SENDER=false - для каждого раб. места LI
если все false сервер работает на 10 коннектах к базе максимум
Режим рождения тредов:
FAST_MODE_TCP=false FAST_MODE_UDP=false
FAST_MODE - это режим удаления треда обработки данных после того как он закончил работу. Если стоит false - тред переходит в спящий режим и ждет когда понадобится, если true - прибивается. В первом случае экономится процессорное время на создание треда, во втором память.
Опции, отвечающие за кэширование записи в БД на уровне locarus server:
WRITE_CACHE_DIRTY=false WRITE_CACHE_ENABLED=flase
В нормальной ситуации включать не нужно. Кэширование имеет смысл включать в том случае, если в часы пик БД не успевает принимать данные с приборов и отдавать большому количеству Информеров. Данные будут кэшироваться и, при ослаблении нагрузки на БД, заливаться в неё.
Также можно попробовать увеличить объем хипа для Java-машины.
В файле conf/wrapper-server.conf
последние несколько строк конфига:
wrapper.java.command = java wrapper.java.additional.1 = -Xms512m wrapper.java.additional.2 = -Xss1024k
менять нужно параметр -Xms512m не забывая про общий объем ОЗУ в системе и количество ОЗУ, которое мы отдали под Постгрес (shared_buffers). Чтобы всем всё хватало.
