Оптимизация

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 полей строчной части

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