Конфигурация высоконагруженных систем

В случаях, когда СПИ "Юпитер-КРОС" должна обрабатывать информацию, приходящую от большого количества приборов(порядка 10000) необходимо внести изменения в настройку ОС, СУБД PostgreSQL и изменить ряд параметров в конфигурации smpo-server.

Операционная система

Для ведомственных подразделений рекомендуется использовать ОС Astra Linux Smolensk 1.7
Указанные здесь настройки применимы для ОС семейства Linux:

• Для повышения стабильности обработки сетевых обращений рекомендуется внести следующие изменения в файл /etc/sysctl.conf

fs.file-max = 1000000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.udp_mem = 8388608 12582912 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
vm.swappiness=5
vm.vfs_cache_pressure = 1000

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

sudo sysctl -p

СУБД PostgreSQL

В связи с тем, что СУБД PostgreSQL 9.6 поддерживается только в ОС Astra Linux Smolensk 1.6, а версии 10 и 11 более не поддерживаются, в ОС Astra Linux Smolensk 1.7 рекомендуется подключить или скачать образ расширенного репозитория ОС и установить СУБД PostgreSQL 14. Так как комплекс работает с большим количеством данных, рекомендуется использовать отдельный диск для работы СУБД.
Данные рекомендации основываются на имперических исследованиях и проверены на типовых конфигурациях АРМ тип 2 и серверных решениях. В качестве платформ использовались компьютеры со следующей конфигурацией:
- процессор Intel® Core i5-11400 @ 2.6GHz
- ОЗУ 32 GB
- SSD 180 GB - Операционная система AstraLinux Smolensk 1.7 Update 5
- SSD 250 GB - кластер базы данных. Диск смонтирован в /mnt/postgresql
- SATA 1TB - резервные копии баз данных, логирование работы КРОС, пакеты для установки ПО. Диск смонтирован в /mnt/hdd
- Эмулятор работы приборов - 10000 приборов

Создание нового кластера PostgreSQL

Перед началом, необходимо остановить работу СУБД:

sudo systemctl stop postgresql

1. Для переноса кластера можно воспользоваться копированием/переносом данных из /var/lib/postgresql/14/main в /mnt/postgresql/14/main.

• Скорее всего при копировании/переносе данных изменится владелец, поэтому необходимо его сменить:

sudo chown -R postgres:postgres /mnt/postgresql

• Так же,возможно придётся изменить права:

sudo chmod -R 700 /mnt/postgresql

2. Можно создать новый кластер:

sudo -u postgres initdb --locale ru_RU.UTF-8 -E UTF8 -D '/mnt/postgresql/14/main'

Изменение конфигурации

Необходимо внести ряд изменений в файл /etc/postgresql/14/main/postgresql.conf

Общие настройки

1. Если кластер был перенесен, то необходимо изменить строку data_directory = '/var/lib/postgresql/14/main' на data_directory = '/mnt/postgresql/14/main' - в нашем случае.
2. Чтобы уменьшить риск взлома СУБД, рекомендуется использовать listen_addresses = 'localhost'
3. max_connections = 1800 - максимальное число разрешенных подключений.
4. password_encryption = md5 - шифрование, которое будет использоваться.
5. shared_buffers = 2GB - Задаёт объём памяти, который будет использовать сервер баз данных для буферов в разделяемой памяти. Рекомендуется использовать 25% от общего объема ОЗУ, но на практике необходимо подбирать в зависимости от общей нагрузки. При увеличении shared_buffers обычно требуется соответственно увеличить max_wal_size, чтобы растянуть процесс записи большого объёма новых или изменённых данных на более продолжительное время.
6. temp_buffers = 512MB - Задаёт максимальное число временных буферов для каждого сеанса. По умолчанию объём временных буферов составляет восемь мегабайт (1024 буфера).
7. work_mem = 256MB - Задаёт объём памяти, который будет использоваться для внутренних операций сортировки и хеш-таблиц, прежде чем будут задействованы временные файлы на диске.
8. maintenance_work_mem = 2GB - Задаёт максимальный объём памяти для операций обслуживания БД.
9. shared_memory_type = mmap - Выбирает механизм разделяемой памяти, используя который сервер будет работать с основной областью общей памяти, содержащей общие буферы PostgreSQL и другие общие данные. Параметр доступен с PostgreSQL 12.
10. dynamic_shared_memory_type = sysv - Выбирает механизм динамической разделяемой памяти, который будет использовать сервер.
11. min_dynamic_shared_memory = 1024MB - Когда для общей разделяемой памяти используются огромные страницы, новым параметром min_dynamic_shared_memory при запуске сервера можно выделить область динамической разделяемой памяти для параллельно выполняемых запросов. Параметр доступен с PostgreSQL 14.
12. max_files_per_process = 300 - Задаёт максимальное число файлов, которые могут быть одновременно открыты каждым серверным подпроцессом. Значение по умолчанию — 1000 файлов.
13. effective_io_concurrency = 100 - Задаёт допустимое число параллельных операций ввода/вывода, которое говорит postgresql о том, сколько операций ввода/вывода могут быть выполнены одновременно. На низкопроизводительных дисках рекомендуется указывать 5 и меньше.
14. max_worker_processes = 4 - Задаёт максимальное число фоновых процессов, которое можно запустить в текущей системе. Этот параметр можно задать только при запуске сервера. Значение по умолчанию — 8.
15. max_parallel_maintenance_workers = 4 - Задаёт максимальное число рабочих процессов, которые могут запускаться одной служебной командой.
16. wal_buffers = 16MB - Объём разделяемой памяти, который будет использоваться для буферизации данных WAL, ещё не записанных на диск. Значение по умолчанию, равное -1, задаёт размер, равный 1/32 (около 3%) от shared_buffers, но не меньше, чем 64 КБ и не больше, чем размер одного сегмента WAL (обычно 16 МБ).
17. checkpoint_completion_target = 0.9 - Задаёт целевое время для завершения процедуры контрольной точки, как коэффициент для общего времени между контрольными точками.
18. max_wal_size = 4GB - Максимальный размер, до которого может вырастать WAL между автоматическими контрольными точками в WAL.
19. min_wal_size = 1GB - Пока WAL занимает на диске меньше этого объёма, старые файлы WAL в контрольных точках всегда перерабатываются, а не удаляются.
20. effective_cache_size = 4GB - Определяет представление планировщика об эффективном размере дискового кеша, доступном для одного запроса. Это представление влияет на оценку стоимости использования индекса; чем выше это значение, тем больше вероятность, что будет применяться сканирование по индексу, чем ниже, тем более вероятно, что будет выбрано последовательное сканирование.

Настройка логирования

1. log_destination = 'stderr' - PostgreSQL поддерживает несколько методов протоколирования сообщений сервера: stderr, csvlog и syslog. На Windows также поддерживается eventlog. В качестве значения log_destination указывается один или несколько методов протоколирования, разделённых запятыми. По умолчанию используется stderr. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.
2. logging_collector = on - Параметр включает сборщик сообщений (logging collector). Это фоновый процесс, который собирает отправленные в stderr сообщения и перенаправляет их в журнальные файлы.
3. log_directory = '/mnt/postgresql/logs/14' - путь куда записывать лог-файлы. Для пользователя postgres должно быть разрешение на запись.
4. log_filename = 'postgresql-%a.log' - название файл-лога. %a - указывает, что файлы формируются по дням недели.
5. log_rotation_age = 1d - разрешить обновлять файлы каждый день.
6. log_rotation_size = 10MB - разрешить перезаписывать файлы при достижении размера в 10MB.

Управление транзакциями

1. statement_timeout = 120000 - Задаёт максимальное время выполнения оператора (в миллисекундах), начиная с момента получения сервером команды от клиента, по истечении которого оператор прерывается. Устанавливать значение statement_timeout в postgresql.conf без особой необходимости не рекомендуется, так как это повлияет на все сеансы.
2. lock_timeout = 120000 - Задаёт максимальную длительность ожидания (в миллисекундах) любым оператором получения блокировки таблицы, индекса, строки или другого объекта базы данных. Устанавливать значение lock_timeout в postgresql.conf без особой необходимости не рекомендуется, так как это повлияет на все сеансы.
3. idle_in_transaction_session_timeout = 120000 - Завершать любые сеансы, в которых открытая транзакция простаивает дольше заданного (в миллисекундах) времени. Это позволяет освободить все блокировки сеанса и вновь задействовать слот подключения; также это позволяет очистить кортежи, видимые только для этой транзакции.

СПИ "Юпитер-КРОС"

1. Конфигурация файла /usr/local/smpo-server/conf/wrapper.conf должна выглядеть примерно следующим образом:

# Java Additional Parameters
wrapper.java.additional.1 = -Xms2048m
wrapper.java.additional.2 = -Xmx7384m
wrapper.java.additional.3 = -Xss1024k
wrapper.java.additional.6 = -Dname=smpo-server
wrapper.java.additional.7 = -Dmyprocessname=kros

2. В файл конфигурации smpo-server /usr/local/smpo-server/conf/smpo.properties необходимо внести следующие изменения:

db.dataring.events.max=100
db.dataring.max=900
server.threads.max.tcp=1000
server.threads.max.udp=400
server.threads.max.udp.delay=100
server.threads.max.udp.sleep=0
server.udp.buffersize=4096