LEMP-стек остаётся базовым решением для проектов с высокой нагрузкой, где важны скорость, стабильность и контроль над ресурсами. Белорусский VPS даёт предсказуемую сеть и хорошую альтернативу зарубежным локациям при работе с русскоязычной аудиторией. В этой статье разберём практическую настройку Nginx, PHP-FPM и базы данных под реальные нагрузки.
Вступление
LEMP-стек давно стал стандартом для проектов, где на первом месте стоят производительность, управляемость и предсказуемое поведение под нагрузкой. Связка Nginx, PHP-FPM и базы данных хорошо масштабируется, даёт гибкость в настройках и позволяет точно контролировать потребление ресурсов. Именно поэтому LEMP чаще всего выбирают для коммерческих сайтов, сервисов и контентных проектов с постоянным трафиком.
При размещении таких проектов на белорусском VPS особое значение приобретает корректная начальная конфигурация. Ошибки на этапе установки и базовых настроек почти всегда приводят к узким местам: росту времени ответа, перегрузке CPU, утечкам памяти или нестабильной работе PHP-процессов. Исправлять это «на живом» проекте сложнее и дороже, чем сразу заложить правильную архитектуру.
Высоконагруженный сайт — это не только про количество посетителей. Нагрузка формируется из множества факторов: динамический контент, работа с базой данных, фоновые задачи, API-запросы, кеширование и логирование. Даже при умеренном трафике неправильно настроенный сервер может упираться в лимиты по памяти или дисковым операциям.
Белорусский VPS часто выбирают как компромисс между доступностью, стабильностью сети и независимостью от зарубежных площадок. При этом он ничем не ограничивает в плане технической реализации: можно использовать актуальные версии ПО, контейнеризацию, внешние хранилища и любые схемы резервного копирования. Всё упирается в грамотную настройку и понимание особенностей нагрузки.
В этой статье мы пошагово разберём, как настроить LEMP-стек на белорусском VPS для работы под высокой нагрузкой: от базовой установки и оптимизации Nginx до тонкой настройки PHP-FPM и базы данных. Материал ориентирован на практику и реальные сценарии, без теории ради теории и лишних абстракций.
Подготовка белорусского VPS
Перед установкой LEMP-стека важно привести сервер в предсказуемое и чистое состояние. Для высоконагруженных сайтов это критично: любые дефолтные настройки, оставленные «как есть», со временем превращаются в источник нестабильности. Начинать имеет смысл с минимальной, понятной конфигурации, где каждый компонент выполняет свою задачу и не конфликтует с остальными.
Оптимальный выбор для большинства проектов — актуальная LTS-версия Ubuntu или Debian. Эти системы стабильны, хорошо документированы и поддерживаются большинством серверных пакетов без костылей. На старте стоит ориентироваться не только на объём памяти и количество ядер, но и на тип диска: для высоконагруженных сайтов NVMe даёт заметный выигрыш при работе с логами, кешем и базой данных.
После первого входа на сервер систему необходимо обновить и привести в порядок базовое окружение. Обновление пакетов, установка необходимых утилит и отключение лишних сервисов позволяют избежать конфликтов и неожиданных зависимостей. Важно сразу проверить корректную работу времени и часового пояса: рассинхрон влияет на логи, кеширование, SSL и отладку проблем под нагрузкой.
Отдельного внимания заслуживают системные лимиты. Значения по умолчанию часто не рассчитаны на большое количество одновременных соединений и активных процессов. Ограничения на количество открытых файлов, сетевые параметры и лимиты для пользователей лучше задать заранее, чтобы сервер не упирался в них при росте трафика.
На этом этапе не стоит устанавливать веб-сервер, PHP или базу данных. Задача подготовки — получить чистый, обновлённый VPS с корректными системными настройками, готовый к дальнейшей установке LEMP-стека. Такой подход упрощает диагностику проблем и даёт стабильную основу для работы под высокой нагрузкой.
Установка и базовая настройка Nginx
Nginx — ключевой компонент LEMP-стека и первая точка, где формируется поведение сайта под нагрузкой. Его основное преимущество — событийная модель обработки запросов, которая позволяет обслуживать большое количество соединений без линейного роста потребления ресурсов. Но это преимущество раскрывается только при корректной базовой настройке.
Устанавливать имеет смысл версию из официальных репозиториев дистрибутива или из репозитория Nginx, если требуется более свежий релиз. После установки важно сразу проверить, что сервис стартует корректно, слушает нужные порты и не конфликтует с другими службами. На этом этапе достаточно дефолтной конфигурации без виртуальных хостов и дополнительной логики.
Первое, на что стоит обратить внимание, — параметры работы воркеров. Значения worker_processes и worker_connections напрямую влияют на количество одновременных соединений, которые сервер способен обработать. Для VPS с несколькими ядрами логично привязывать количество воркеров к числу CPU, а лимит соединений подбирать с запасом, но без экстремальных значений, которые приведут к росту потребления памяти.
Далее следует настроить keepalive и таймауты. Слишком агрессивные таймауты увеличивают нагрузку за счёт частого открытия соединений, слишком мягкие — удерживают лишние подключения. Баланс зависит от типа проекта, но базовые значения лучше задать сразу, чтобы избежать хаотичного поведения под пиками трафика.
Отдельный момент — логи. Для высоконагруженных сайтов логирование по умолчанию может стать узким местом, особенно при интенсивной динамике. Уже на старте стоит продумать формат логов, их ротацию и объём, чтобы диск и файловая система не начали влиять на скорость обработки запросов.
На этом этапе задача — получить стабильный, предсказуемый Nginx без сложных оптимизаций и кеширования. Глубокая настройка под нагрузку, работа со статикой и FastCGI-кешем имеет смысл только после того, как базовая конфигурация отработана и понятна.
Оптимизация Nginx под нагрузку
После базовой настройки Nginx можно переходить к оптимизациям, которые напрямую влияют на скорость отклика и устойчивость сайта при пиковых нагрузках. На этом этапе важно не гнаться за максимальным количеством директив, а внедрять только те механизмы, которые реально снижают нагрузку на сервер и backend.
В первую очередь имеет смысл включить сжатие ответов. Gzip остаётся универсальным вариантом и даёт заметное сокращение объёма передаваемых данных для HTML, CSS, JavaScript и JSON. Сжатие особенно эффективно для проектов с большим количеством динамических страниц и API-запросов. Важно ограничить его только нужными типами контента и не применять к уже сжатым форматам, чтобы не тратить CPU впустую.
Следующий шаг — работа со статикой. Nginx отлично справляется с отдачей статических файлов, поэтому изображения, шрифты, стили и скрипты должны обслуживаться напрямую, без участия PHP. Правильно настроенные заголовки кеширования позволяют браузерам и промежуточным прокси хранить статику локально, снижая количество повторных запросов к серверу.
Для проектов с высокой долей динамики стоит рассмотреть FastCGI-кеш. Он позволяет кешировать результат работы PHP и отдавать его напрямую из памяти или с диска, минуя выполнение скриптов при каждом запросе. Такой подход особенно полезен для CMS и контентных сайтов, где большая часть страниц одинаково выглядит для всех пользователей. При этом важно заранее определить правила очистки кеша и исключения для персонализированных страниц.
Отдельное внимание стоит уделить защите от перегрузок. Ограничение количества запросов с одного IP, контроль одновременных соединений и разумные таймауты помогают переживать всплески трафика и защищают сервер от простых атак на доступность. Эти меры не заменяют полноценную защиту, но значительно повышают устойчивость системы.
На этом этапе Nginx превращается из просто веб-сервера в полноценный слой управления нагрузкой. Дальнейшая оптимизация уже будет зависеть от связки с PHP-FPM и базой данных, поэтому важно зафиксировать текущие настройки и понимать, какой эффект они дают на реальном трафике.
Установка и настройка PHP-FPM
PHP-FPM отвечает за обработку динамического контента и во многом определяет, как сайт ведёт себя под нагрузкой. Даже при идеально настроенном Nginx неправильно сконфигурированный PHP-FPM быстро становится узким местом. Поэтому его настройке стоит уделить не меньше внимания, чем веб-серверу.
Начинать следует с выбора версии PHP. Для высоконагруженных проектов важно использовать поддерживаемую и оптимизированную версию, совместимую с кодовой базой сайта. Более новые версии PHP, как правило, дают выигрыш по производительности и потреблению памяти, но их использование должно быть оправдано тестированием и требованиями проекта.
Ключевой элемент настройки PHP-FPM — режим управления процессами. На практике чаще всего используется dynamic или ondemand. Первый подходит для проектов с постоянной нагрузкой, второй — для сайтов с неравномерным трафиком. Выбор режима напрямую влияет на потребление памяти и скорость отклика, поэтому универсального решения здесь нет.
Особое внимание стоит уделить параметрам pm.max_children, pm.start_servers, pm.min_spare_servers и pm.max_spare_servers. Эти значения определяют, сколько PHP-процессов может работать одновременно и как они создаются. Ошибки в расчётах приводят либо к переполнению памяти, либо к очередям запросов и росту времени ответа. Настройки должны соответствовать реальным ресурсам VPS и среднему потреблению памяти одним PHP-процессом.
Для проектов с несколькими сайтами или разными типами нагрузки рекомендуется использовать отдельные пулы PHP-FPM. Это позволяет изолировать сайты друг от друга, задавать индивидуальные лимиты и предотвращать ситуацию, когда один проект «съедает» все ресурсы сервера. Такой подход упрощает масштабирование и диагностику проблем.
После настройки PHP-FPM важно проверить его связку с Nginx и корректную обработку ошибок. На этом этапе цель — добиться стабильной работы без перегрузок, прежде чем переходить к тонкой оптимизации PHP и работе с кешем и базой данных.
Оптимизация PHP под производительность
После базовой настройки PHP-FPM имеет смысл переходить к параметрам, которые напрямую влияют на скорость выполнения кода и устойчивость под нагрузкой. На этом этапе задача — сократить лишние операции, уменьшить потребление памяти и стабилизировать время ответа при росте числа запросов.
В первую очередь следует включить и корректно настроить OPcache. Для высоконагруженных сайтов это обязательный компонент, который избавляет PHP от постоянной перекомпиляции скриптов. Размер кеша, количество сохраняемых файлов и политика очистки должны соответствовать объёму кода проекта. Недостаточный OPcache приводит к деградации производительности, избыточный — к неэффективному расходу памяти.
Далее стоит обратить внимание на базовые параметры PHP. memory_limit, max_execution_time и max_input_vars должны быть заданы осознанно, а не оставлены по умолчанию. Завышенные лимиты маскируют проблемы в коде и создают ненужную нагрузку на сервер, заниженные — вызывают ошибки и обрывы запросов. Для высоконагруженных проектов важен баланс между стабильностью и контролем ресурсов.
Отдельный момент — кеширование путей файловой системы. Настройки realpath_cache_size и realpath_cache_ttl снижают количество обращений к диску и ускоряют работу фреймворков и CMS с большим количеством файлов. На SSD и NVMe эффект может быть менее заметен, но под нагрузкой он всё равно играет роль.
Имеет смысл отключить неиспользуемые расширения PHP. Каждый загруженный модуль увеличивает потребление памяти и время инициализации процессов. Для продакшена оставляют только те расширения, которые реально используются проектом, а отладочные и вспомогательные модули убирают.
На этом этапе PHP должен работать предсказуемо и без скачков потребления ресурсов. Если даже после оптимизации сервер упирается в лимиты, это сигнал не к дальнейшему «подкручиванию» конфигов, а к анализу кода, работе с кешем на уровне приложения и оптимизации базы данных.
Настройка базы данных для высокой нагрузки
База данных часто становится главным источником проблем на высоконагруженных сайтах, особенно если её настройке уделяют внимание в последнюю очередь. Даже при умеренном трафике неэффективные запросы и дефолтные параметры сервера БД способны создать постоянную нагрузку на CPU и диск. Поэтому оптимизацию базы данных стоит рассматривать как обязательную часть настройки LEMP-стека.
Для большинства проектов подойдут MySQL или MariaDB, выбор между ними чаще всего определяется требованиями CMS и личными предпочтениями. Независимо от варианта, начинать стоит с базовой оптимизации InnoDB, так как именно этот движок используется в большинстве современных проектов. Размер буфера InnoDB должен соответствовать объёму доступной памяти и не конкурировать с PHP-FPM и системой за ресурсы.
Важно ограничить количество одновременных соединений с базой данных. Завышенные значения приводят к резким пикам нагрузки и деградации производительности, особенно при всплесках трафика. Лимиты должны быть согласованы с настройками PHP-FPM, чтобы количество активных PHP-процессов не превышало разумные возможности сервера БД.
Отдельное внимание стоит уделить логированию медленных запросов. Slow log позволяет выявить проблемные места в коде и понять, какие запросы создают основную нагрузку. Это один из самых эффективных инструментов диагностики, который даёт практическую пользу даже без глубокого анализа планов выполнения.
Не стоит использовать устаревшие механизмы кеширования на уровне базы данных, если они не рекомендованы для вашей версии сервера. Основной упор лучше делать на оптимизацию запросов, индексы и кеш на уровне приложения или веб-сервера. Такой подход даёт более предсказуемый результат под реальной нагрузкой.
После базовой настройки базы данных важно протестировать её поведение под нагрузкой и зафиксировать исходные показатели. Это позволит понять, где проходит реальный предел текущей конфигурации и какие изменения действительно влияют на производительность.
Кеширование и снижение нагрузки на сервер
Даже хорошо настроенный LEMP-стек быстро упрётся в пределы ресурсов, если каждый запрос будет проходить полный цикл обработки. Кеширование позволяет резко снизить нагрузку на PHP и базу данных, сократив время ответа и повысив устойчивость сайта при пиковом трафике. Для высоконагруженных проектов это не опция, а обязательный слой архитектуры.
На уровне веб-сервера в первую очередь используется HTTP-кеширование. Корректные заголовки Cache-Control и Expires позволяют браузерам и промежуточным узлам хранить ответы локально и не обращаться к серверу повторно. Особенно эффективно это работает для статики и страниц с редко меняющимся контентом.
Для динамических сайтов серьёзный прирост даёт FastCGI-кеш в Nginx. Он сохраняет результат выполнения PHP-скриптов и отдаёт его напрямую, минуя PHP-FPM при повторных запросах. Такой подход снижает нагрузку на процессор и память и позволяет обслуживать больше запросов теми же ресурсами. Важно заранее продумать правила инвалидирования кеша, чтобы пользователи не видели устаревший контент.
Дополнительный уровень — object cache на базе Redis или Memcached. Он используется для хранения данных, к которым часто обращается приложение: результатов запросов, сессий, конфигураций. Object cache особенно полезен для CMS и фреймворков, где одни и те же данные используются во многих запросах.
При внедрении кеширования важно соблюдать меру. Избыточный кеш усложняет архитектуру и может создавать проблемы с актуальностью данных. Эффективная стратегия строится на понимании того, какие части сайта действительно нагружают сервер и где кеш даёт максимальный эффект.
После внедрения кеширования стоит обязательно проверить реальные метрики: время ответа, загрузку CPU и количество запросов к базе данных. Это позволяет убедиться, что кеш работает именно там, где нужен, и действительно снижает нагрузку, а не просто добавляет ещё один слой сложности.
Безопасность без потери производительности
Для высоконагруженного сайта безопасность должна быть встроена в конфигурацию, а не добавлена поверх неё «на всякий случай». Избыточные проверки и тяжёлые фильтры могут съедать ресурсы не хуже атаки, поэтому задача — закрыть базовые риски простыми и быстрыми мерами, которые почти не влияют на скорость.
Начать стоит с ограничения поверхности атаки на уровне Nginx. Обычно это запрет доступа к скрытым файлам и служебным каталогам, закрытие прямого выполнения скриптов в директориях загрузок, запрет листинга каталогов, корректная обработка неизвестных расширений. Параллельно полезно уменьшить «шум» в ответах сервера: скрыть версии сервисов, аккуратно настроить страницы ошибок и не отдавать лишнюю информацию в заголовках.
На уровне PHP важно отключить функции, которые не используются и потенциально опасны, а также жёстко контролировать доступ к файловой системе. В продакшене не должно быть включённого отображения ошибок, а логирование ошибок стоит отделять от логов веб-сервера, чтобы проще отслеживать проблемы и не увеличивать нагрузку на диск при всплесках.
SSH-доступ к VPS лучше сразу привести к минимально безопасной схеме: вход по ключам, запрет входа под root, ограничение доступа по IP там, где это возможно. Для защиты от перебора логинов хорошо работает fail2ban: он добавляет устойчивость к массовым попыткам авторизации и практически не влияет на производительность при нормальном трафике.
Сертификаты TLS сейчас воспринимаются как базовая норма, но важно помнить, что «включить HTTPS» мало. Имеет значение корректный набор протоколов и шифров, включение HTTP/2, настройка сессий и заголовков безопасности. Всё это улучшает и безопасность, и реальную скорость загрузки страниц для пользователей.
После внедрения базовых мер безопасности полезно зафиксировать конфигурацию и не менять её хаотично. Для высоконагруженных проектов главная ценность — стабильность: безопасность должна быть достаточной, но не превращать сервер в хрупкую систему, где любое изменение ломает производительность.
Мониторинг и контроль нагрузки
Даже идеально настроенный LEMP-стек со временем начинает вести себя по-другому: растёт трафик, меняется характер запросов, появляются новые функции. Без мониторинга такие изменения замечают уже по факту проблем — когда сайт начинает «тормозить» или падать под нагрузкой. Поэтому контроль состояния сервера должен быть постоянным, а не разовой проверкой после настройки.
В первую очередь важно отслеживать базовые системные метрики: загрузку CPU, использование оперативной памяти, I/O диска и сетевую активность. Эти показатели позволяют быстро понять, где возникает узкое место — в процессоре, памяти или подсистеме хранения. Особенно критично следить за swap: его активное использование почти всегда говорит о проблемах с настройками или нехватке ресурсов.
Отдельного внимания заслуживает мониторинг Nginx. Количество активных соединений, скорость обработки запросов, рост очередей и ошибки уровня 5xx дают прямое представление о том, как веб-сервер справляется с нагрузкой. Резкие изменения этих метрик часто указывают либо на всплеск трафика, либо на проблемы в связке с PHP-FPM.
Для PHP-FPM важно контролировать состояние пулов: сколько процессов активно, сколько запросов ожидают обработки, не достигаются ли лимиты pm.max_children. Если пул регулярно упирается в ограничения, сайт будет отвечать медленно даже при свободных ресурсах сервера. Это один из самых частых сценариев деградации производительности.
Мониторинг базы данных не менее важен. Рост времени выполнения запросов, увеличение количества подключений и активная работа с диском позволяют заранее увидеть проблемы, которые позже проявятся в виде таймаутов и ошибок. Slow log в сочетании с метриками нагрузки даёт понимание, что именно начинает тормозить систему.
Грамотно настроенный мониторинг позволяет не только реагировать на проблемы, но и планировать масштабирование. Когда есть исторические данные, становится понятно, где проходит реальный предел текущей конфигурации и какие изменения дадут максимальный эффект без лишних затрат.
Типичные ошибки при настройке LEMP под нагрузку
Одна из самых распространённых ошибок — попытка «выжать максимум» из конфигураций без понимания реальной нагрузки. Завышенные значения лимитов для PHP-FPM, базы данных и Nginx создают иллюзию запаса, но на практике приводят к перерасходу памяти и нестабильной работе. Сервер начинает бороться сам с собой, а не с трафиком.
Вторая частая проблема — отсутствие кеширования или его формальное наличие. Кеш включён, но не используется из-за неправильных правил, слишком короткого времени жизни или постоянной очистки. В результате каждый запрос снова идёт в PHP и базу данных, и сервер не получает ожидаемой разгрузки.
Многие игнорируют логи и мониторинг до первых серьёзных сбоев. Без slow log, без контроля пулов PHP-FPM и без наблюдения за нагрузкой невозможно понять, что именно тормозит сайт. В таких условиях оптимизация превращается в угадывание.
Ещё одна ошибка — смешивание ролей на одном VPS без учёта ресурсов. Web, база данных, фоновые задачи и cron работают вместе, конкурируя за CPU и память. Пока нагрузка небольшая, это незаметно, но при росте трафика система быстро выходит на предел.
Наконец, часто недооценивают влияние обновлений и изменений в коде. Новый плагин, дополнительный API или переработанный шаблон могут радикально изменить профиль нагрузки. Без пересмотра настроек сервер начинает вести себя иначе, хотя формально конфигурация не менялась.
Когда текущей конфигурации становится недостаточно
Даже при грамотной настройке наступает момент, когда возможности текущего VPS заканчиваются. Основные признаки — стабильный рост времени ответа, регулярное упирание в лимиты PHP-FPM или базы данных, а также высокая загрузка CPU без явных пиков трафика. В такой ситуации «подкрутить ещё немного» уже не работает.
Первый шаг — вертикальное масштабирование. Увеличение объёма памяти или количества ядер часто даёт быстрый эффект, если архитектура изначально выстроена правильно. При этом важно пересмотреть все ключевые настройки, чтобы новые ресурсы действительно использовались, а не простаивали.
Если рост продолжается, следующим этапом становится разделение ролей. Вынос базы данных или кеша на отдельный сервер снижает конкуренцию за ресурсы и делает систему более устойчивой. Такой подход особенно оправдан для проектов с активной динамикой и большим количеством запросов к данным.
Важно понимать, что масштабирование — это не аварийная мера, а часть жизненного цикла проекта. Чем раньше появляются метрики и понимание реальной нагрузки, тем проще принять решение без спешки и потери стабильности.
Пример настроек сервера
Этот пример конфигурации показывает базовую рабочую схему LEMP-стека для сайта с высокой нагрузкой на белорусском VPS. Настройки не претендуют на универсальность, но отражают логику, описанную в статье: сначала системные лимиты и сеть, затем Nginx как слой управления нагрузкой, PHP-FPM с контролем процессов, кеширование и оптимизация базы данных.
Конфигурация рассчитана на предсказуемое поведение под трафиком, без экстремальных значений и агрессивных «твиков». Все параметры нужно адаптировать под конкретные ресурсы VPS, тип проекта и реальный профиль нагрузки, но в таком виде они дают стабильную основу, от которой удобно отталкиваться при дальнейшей оптимизации и масштабировании.
Базовые лимиты и сеть
/etc/security/limits.d/90-lemp.conf - soft nofile 1048576 - hard nofile 1048576 www-data soft nofile 1048576 www-data hard nofile 1048576 /etc/sysctl.d/99-lemp.conf fs.file-max = 2097152 net.core.somaxconn = 65535 net.core.netdev_max_backlog = 16384 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.ip_local_port_range = 10240 65535 net.ipv4.tcp_fin_timeout = 15 net.ipv4.tcp_keepalive_time = 300 net.ipv4.tcp_keepalive_intvl = 30 net.ipv4.tcp_keepalive_probes = 5 net.ipv4.tcp_tw_reuse = 1
Nginx — базовая конфигурация
/etc/nginx/nginx.conf user www-data; worker_processes auto; pid /run/nginx.pid; events { worker_connections 4096; multi_accept on; use epoll; } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 30; keepalive_requests 1000; server_tokens off; client_max_body_size 32m; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log warn; gzip on; gzip_comp_level 5; gzip_min_length 1024; gzip_types text/plain text/css text/xml application/xml application/xml+rss application/json application/javascript image/svg+xml; include /etc/nginx/mime.types; default_type application/octet-stream; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/; }
Nginx — виртуальный хост
/etc/nginx/sites-available/site.conf server { listen 80; server_name example.com www.example.com; root /var/www/example.com/public; index index.php index.html; access_log /var/log/nginx/example_access.log; error_log /var/log/nginx/example_error.log warn; location ~* .(jpg|jpeg|png|gif|webp|svg|ico|css|js|woff2?|ttf|eot)$ { expires 30d; add_header Cache-Control "public, max-age=2592000, immutable"; try_files $uri =404; access_log off; } location ~ .php$ { try_files $uri =404; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/run/php/php8.2-fpm-example.sock; fastcgi_read_timeout 60; fastcgi_cache PHPFASTCGI; fastcgi_cache_valid 200 10m; fastcgi_cache_bypass $skip_cache_method $skip_cache_cookie; fastcgi_no_cache $skip_cache_method $skip_cache_cookie; add_header X-Cache $upstream_cache_status; } location ~ /. { deny all; } }
FastCGI-кеш Nginx
/etc/nginx/conf.d/fastcgi_cache.conf fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=PHPFASTCGI:200m inactive=60m max_size=10g; map $request_method $skip_cache_method { default 1; GET 0; HEAD 0; } map $http_cookie $skip_cache_cookie { default 0; ~*(wordpress_logged_in|wp-postpass|comment_author) 1; }
PHP-FPM — пул сайта
/etc/php/8.2/fpm/pool.d/example.conf
[example]
user = www-data
group = www-data
listen = /run/php/php8.2-fpm-example.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = dynamic
pm.max_children = 40
pm.start_servers = 8
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 800
request_terminate_timeout = 60s
php_admin_value[memory_limit] = 256M
php_admin_flag[log_errors] = on
php_admin_value[error_log] = /var/log/php8.2-fpm-example-error.log
OPcache и файловый кеш
/etc/php/8.2/fpm/conf.d/10-opcache.ini
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=100000
opcache.validate_timestamps=1
opcache.revalidate_freq=30
realpath_cache_size=4096K
realpath_cache_ttl=600
MariaDB / MySQL
/etc/mysql/conf.d/99-tuning.cnf
[mysqld]
max_connections = 200
innodb_buffer_pool_size = 2G
innodb_buffer_pool_instances = 2
innodb_log_file_size = 512M
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 2
tmp_table_size = 128M
max_heap_table_size = 128M
table_open_cache = 4000
thread_cache_size = 100
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5
Fail2ban
/etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h
Ротация логов Nginx
/etc/logrotate.d/nginx /var/log/nginx/*.log { daily rotate 14 compress delaycompress missingok notifempty sharedscripts postrotate [ -s /run/nginx.pid ] && kill -USR1 $(cat /run/nginx.pid) endscript }
Заключение
LEMP-стек остаётся одним из самых надёжных и гибких решений для высоконагруженных сайтов, если подходить к его настройке осознанно. Белорусский VPS даёт все технические возможности для такой конфигурации, но результат напрямую зависит от качества базовых настроек.
Ключевую роль играет баланс между Nginx, PHP-FPM, базой данных и кешированием. Грамотная архитектура, мониторинг и регулярный пересмотр конфигурации позволяют системе стабильно работать под нагрузкой и масштабироваться без резких сбоев.
Настройка LEMP — это не разовое действие, а процесс. И чем раньше он будет выстроен правильно, тем дольше сервер остаётся предсказуемым и управляемым даже при росте проекта.
VPS на год? Мы добавим сверху
Сэкономьте месяц — просто введите