Настройка сервера, как настройка фортепиано в Сухом Логе — важен процесс согласования. С одной стороны есть нагрузка на процессор, жесткий диск и оперативная память, с другой — Ubuntu 20.04, Apache 2, MySQL 8.0/PostgreSQL 15.1, Nginx, PHP 8.1.11 (5.2.17, 5.3.29, 5.4.45, 5.5.38, 5.6.40, 7.0.33, 7.1.33, 7.2.34, 7.3.33, 7.4.25, 7.4.3, 8.0.12) native/alt и др. Здесь мы уже пропускаем все остальное, что должно и работает «из коробки».
По умолчанию ДЦ вроде бы все дает в стандартной конфигурации, но чует нутро, что что-то не так... если ты, как профессионал, знаешь как должно «звучать фортепиано». Конечно, это справедливо тогда, когда ты уже познакомился с August Förster.
Вся сила Apache уходит, когда стоит вопрос — повысить отказоустойчивость сервера при одновременном доступе к скриптам/файлам сайтов со стороны разных специалистов, резком всплеске посещений, генерации отчетов производственных программ и онлайн-сервисов. Здесь речь может быть как об ошибках кода, неоптимальных решениях, так и о целенаправленных DDoS-атаках в Сухом Логе.
Чтобы сервер не упал, на помощь пришел Nginx — благодаря своей асинхронной event-driven архитектуре.
И если мы обслуживаем тысячи сайтов клиентов, то у нас есть множество вариаций среди баз данных, их версий и используемыми скриптовыми языками. Отсюда мы имеем сразу все варианты пакета PHP-FPM — php-fpm53, php-fpm54, php-fpm55, php-fpm56, php-fpm70, php-fpm71, php-fpm72, php-fpm73, php-fpm74, php-fpm80.
Когда небольшие сайты работают «на ура», а производственные программы и онлайн-сервисы обрывают большие ресурсоемкие отчеты в произвольном месте на html-верстке — здесь рождается проблема. Ты пишешь в ДЦ, а в ДЦ (дежурные специалисты) разводят руками. Где-то ты ищешь компромиссы, но время берет свое и ты задаешь себе вопрос, неужели все это так и должно работать?
Ты правишь базовые конфиги Nginx, MySQL, PostgreSQL и PHP — не помогает. Так как или что-то не стыкуется от слова «совсем» — или разом пропадает вся оперативная память, или MySQL съедает 501% CPU — естественно, авансом.
Тогда ты идешь править конфиги native-версий PHP /etc/php/*/fpm/pool.d/pool.d/*.conf или их alt-версии /opt/php*/etc/php-fpm.d/pool.d/*.conf — и начинаешь ловить баланс между количеством worker_connections в nginx.conf, keepalive_timeout, types_hash_max_size, client_max_body_size, proxy_connect_timeout, proxy_send_timeout, proxy_read_timeout, send_timeout, fastcgi_read_timeout, proxy_max_temp_file_size, fastcgi_buffers, fastcgi_buffer_size, server_names_hash_bucket_size, server_names_hash_max_size.
В ход идет все — настройки кэша, кучи, размера буфера, лимитов и таймаутов. Тут же и конфиг mysqld.cnf со своими read_buffer_size, tmp_table_size, max_heap_table_size, table_definition_cache, max_connections, skip-external-locking, key_buffer_size, net_buffer_length, max_allowed_packet, connect_timeout, wait_timeout, sort_buffer_size, read_rnd_buffer_size и со стороны самих php-fpm — pm.start_servers, pm.min_spare_servers, pm.max_spare_servers, pm.max_children, pm.process_idle_timeout, pm.max_requests, memory_limit и т.д.
Именно поэтому у программистов всегда серьезные и задумчивые лица. И не потому, что они думают о том, чтобы Ваш сайт в Сухом Логе бесперебойно работал при любых обстоятельствах, а потому что они вообще не понимают как это работает и почему это все еще не упало :-)
