⟵ сюдатуда ⟶
  • Quick start
  • Установка MIT
  • Установка PRO
  • Обновления
  • Оптимизация
  • PHP-FPM
  • Postgresql
  • max_connections
  • shared_buffers
  • effective_cache_size
  • random_page_cost
  • effective_io_concurrency
  • autovacuum
  • max_parallel_workers_per_gather
  • Завершение настройки
  • Общая нагрузка на CPU и RAM
  • Индексы
  • Обновление v4-v5
  • Бэкапы
  • Консольная утилита bin/totum
  • Основы для пользователей
  • Интерфейс и компоновка
  • Таблицы и их параметры
  • Префильтр
  • Поля и их параметры
  • Синтаксис
  • Код, действия, форматирование
  • Реляционные взаимосвязи
  • Порядок расчета и единицы пересчета
  • Автозаполнение расчетных и временных
  • Дублирование строк и циклов
  • Сравнения
  • Функции
  • Отладка
  • Печать и CSV
  • API
  • Роли и пользователи
  • Нотификации
  • Действия по расписанию
  • Системные таблицы
  • [PRO] Деревья
  • [PRO] Анонимные таблицы
  • [PRO] Внешние формы
  • [PRO] Экспорт и импорт таблиц
  • [PRO] MeiliSearch
  • [PRO] Базы данных
  • [PRO] Настройка CSS
  • [PRO] Custom docs
  • [PRO] LDAP AD
  • [PRO] Версии файлов
  • [PRO] List-unsubscribe
  • [PRO] Динамические поля
  • [PRO] Only Office
  • [PRO] Auth Tokens
  • [PRO] 2FA
  • [PRO] Superlang
  • [PRO] Profiler
  • [PRO] Подключение функций
  • [SRV] Установка и подключение
  • [SRV] Экспорт, pdf, загрузка и предпросмотр
  • [SRV] XLSX/DOCX генераторы
  • Оптимизация

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

    Когда ваше решение будет переходить в эксплуатацию — мы рекомендуем оптимизировать некоторые настройки.

    PHP-FPM

    Ключевая настройка FPM — количество доступных воркеров. Когда от активного пользователя происходит запрос к серверу, Nginx перенаправляет его к копии PHP, загруженной в оперативной памяти.

    Количеством этих копий, ожидающих соединения — управляет конфиг FPM. Пока копия не активна, она потребляет только RAM (приблизительно 50Mb на один экземпляр). В момент, когда она получает задачу, включается потребление процессора.

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

    Для MIT версии, по 2 копии на каждого активного пользователя тк одна всегда полностью занята проверкой системных нотификаций таблиц (в PRO-версии это выполняет модуль на GO, что освобождает по 50Mb RAM на каждого активного пользователя).

    Настраивается в:

    nano /etc/php/8.3/fpm/pool.d/totum.conf
    
    pm.max_children = 20
    pm.start_servers = 10
    pm.min_spare_servers = 10
    pm.max_spare_servers = 20
    
    • pm.max_children — максимальное количество ожидающих процессов FPM. Устанавливайте х1.5-x2 от количества активно работающих на пике пользователей, плюс по одному на каждое одновременное подключение по remotes. RAM рассчитывается от этого количества: pm.max_children * 50Mb = должно занимать не более 25-30% от RAM всей системы.

    • pm.start_servers — устанавливается / 2 от pm.max_children

    • pm.min_spare_servers = pm.start_servers

    • pm.max_spare_servers = pm.max_children

    Когда процесс выполняется, отвечая на запрос пользователя, он записывает свои данные в оперативную память.

    • php_admin_value[memory_limit] — устанавливает лимит потребляемой оперативной памяти одним процессом при выполнении запроса. Мы не рекомендуем ставить больше 1024Mb (не каждый запрос расходует столько — это верхний лимит). Если у вас процесс падает по недостатку такого объема памяти — следует перепрограммировать решение.

    После установки значений — надо сохранить конфигурационный файл и перезапустить FPM:

    service php8.3-fpm restart
    

    Postgresql

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

    Путь к конфигурационному файлу можно посмотреть выполнив команду:

    su - postgres -c "psql -c 'SHOW config_file;'"
    

    Открываем конфигурационный файл по указанному пути, например:

    nano /etc/postgresql/16/main/postgresql.conf
    

    max_connections

    Это количество одновременный подключений к базе данных. Рекоментуется устанавливать двукратно количеству воркеров PHP-FPM.

    Каждое подключение потребляет приблизительно 5Mb, соответственно max_connections * 5 = RAM, задействованная в обслуживании подключений. Не должна превышать 25% от общей RAM системы.

    shared_buffers

    Это RAM, в которую записываются постоянно используемые данные. По умолчанию стоит минимальная настройка в 128Mb. необходимо поставить как можно больше.

    Максимальное количество, после которого увеличение не приводит к ускорению запросов — это величина всех данных в базе.

    Понять объем БД можно выполнив команду (замените VERSION на версию установленного postgresql, посмотрев ее в пути конфигурационного файла выше):

    du -sh /var/lib/postgresql/VERSION/main
    

    Также ограничивающим размером этого параметра является: общий размера RAM минус

    • 1GB на буферы linux

    • RAM на обслуживание коннектов

    • RAM на PHP-FPM

    • RAM на PHP в момент выполнения запросов, желательно двукратно лимиту memory_limit или 10Mb на каждого одновременно работающего пользователя (что больше)

    Те если у вас 16Gb RAM и 80 одновременно работающих пользователей из которых 30 что-то делают активно и есть пара ремоутов на которые паралельно идет по 3-4 одновременных подключения:

    • 50 FPM на пользователей минимум * 50 = 2.5Gb RAM

    • 10 FPM на remotes = 0.5Gb RAM

    • Резерв на max_connections = 60 * 2 = 120 коннектов = 1.2Gb

    • Резерв linux = 1Gb RAM

    • Обеспечение работы процессов PHP = (80 * 10 = 0.8Gb) или (1Gb * 2 = 2Gb) = 2Gb RAM

    • RAM на работу meilisearch и прочих дополнительных скриптов = 1Gb

    Итого резервы = 8.2 Gb и на shared_buffers можно выделить 16Gb - 8Gb = 8Gb. Если при этой же нагрузке у вас 14Gb RAM, то 14Gb - 8Gb = 6Gb на shared_buffers.

    Это актуально только если у вас есть такие объемы данных в базе.

    effective_cache_size

    Если у вас остается свободная RAM, те вы посчитали, что вам можно установить shared_buffers в 8Gb, но у вас вся база 4Gb, то устанавливаете shared_buffers = 4Gb и effective_cache_size x2 от shared_buffers = 8Gb (но не более 80% от общей ОЗУ).

    random_page_cost

    По умолчанию равно 4. Это значение для HDD-дисков. Если у вас NVMe устанавливаете равным 0.1. Есть SSD без NVMe, то равным 1.0

    effective_io_concurrency

    Задает максимально допустимое число параллельных операций IO.

    100 – для SSD с NVMe.

    50 – для SSD без NVMe.

    autovacuum

    Если у вас 2-4 ядра процессора не трогайте параметры autovacuum этот и дальше. Но если у вас база с миллионами строк, то необходимо выделить 2 ядра процессора на работу autovacuum.

    Дело в том, что postgresql при удалении строк не удаляет строки, а помечает как устаревшие. А при изменеии создает новую строку копированием со старой, помечая старую как устаревшую.

    Со временем схема БД замусоривается и начинает работать менее эффективно. autovacuum позволяет БД переиспользовать старые копии строк.

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

    autovacuum = on — разкоментируем эту строку.

    track_counts = on — эту тоже так-как без нее autovacuum бесполезен.

    autovacuum_naptime = '30s' — можно не менять или поставить 30s

    autovacuum_max_workers — 1-2 ядра, но не более 25% от ядер в системе

    autovacuum_vacuum_cost_limit — ставьте 1000

    autovacuum_vacuum_cost_delay — по умолчанию 2ms, так можно оставить

    autovacuum_vacuum_scale_factor — уменьшайте до 0.01 (это 1% необработанных строк, по умолчанию 20%)

    autovacuum_vacuum_threshold — это минимальное количество мертвых строк в штуках, можно оставить 50.

    autovacuum_analyze_scale_factor — устанавливаем в 0.01

    autovacuum_work_mem — задает объем памяти для указателей на мертвые строки. По умолчанию берется из параметра maintenance_work_mem. Память выделяется сразу в полном объеме для каждого из рабочих процессов отдельно. То есть, если вы задали 128 MB, и у вас 8 рабочих процессов, то система сразу полностью выделит 1 GB памяти (если все процессы будут активны), даже если для них будет достаточным меньший объем памяти. Выделяемый объем зависит от количества рабочих процессов. RAM total size / (64 * autovacuum_max_workers).

    max_parallel_workers_per_gather

    Если у вас очень много свободных ядер процессора, например система с 16-32 ядрами и при этом большинство запросов к БД маленькие, но есть несколько крупных — например cron, который создает агрегаты, то можно увеличить количество ядер процессора доступных для одного запроса к БД.

    Параметр max_parallel_workers_per_gather. По умолчанию 2 дополнительных ядра.

    Они менее эффективны чем основное, выполняющее запрос. Эффективность подключаемого ядра около 70%.

    Максимальное количество подключаемых ядер на всю систему по умолчанию 8. Это параметр max_parallel_workers.

    Если у вас очень много данных, то с какого-то момента эффективнее использовать кластеризацию серверов БД, чем добавлять ядра на паралельное сканирование, так-как есть ограничение скорости диска и шины процессора.

    Кластеризировать можно и на 1000 серверов, если есть такая необходимость.

    Завершение настройки

    Сохраните файл и необходимо рестартовать БД. Если у вас PRO-версия, то сначала надо остановить totum-gom:

    service totum-gom stop
    
    service postgresql restart
    
    service totum-gom start
    

    Общая нагрузка на CPU и RAM

    Если вы не являетесь профессиональным системным администратором, то мы рекомендуем брать тот тариф сервера при котором усредненная нагрузка на CPU не превышает 30% в нагруженный период суток, а среднее потребление RAM не более 60%.

    Если вы видите, что усредненные показатели больше — увеличте тариф сервера.

    Высокоскоростные процессоры являются преимуществом, перед стандартными.

    Также есть большая разница между dedicated cpu и shared cpu в вашем тарифе VPS. Shared означает, что хостер несколько раз продал один процессор. И если у вас в решении много больших запросов на выборку данных (те вы запустив htop можете визуально наблюдать запросы select, которые выполняются по несколько секунд) то dedicated cpu будет давать большую производительность тк у вас в распоряжении все ядро, а не 30%.

    Размещение на HDD-дисках в современных условиях даже не рассматривается.

    Индексы

    При выборке из больших таблиц — устанавливайте индексы на поля, по которым идет выборка (where).

    Это делается через настройки таблицы.

    Разумное количество индексов:

    • Не более одного на каждые 10 полей строчной части

    • Не больше трех дополнительных индексов на таблицу.