Comments 56
Мне вот интересно, сейчас 2010 год, когда подобные статьи имели хоть как-то смысл?
Все-таки такая статья с настройкой связки php-fpm + nginx это просто перебор для 2021 года, учитывая что это азы которые администратор обязан знать если он хоть каким-то боком имеет отношение к настройке пхп.
Или статья создана просто чтобы был аккаунт с публикацией?
Бывают же ситуации когда админа нет и сервер настраивает и поддерживает сам разработчик.
Так как раз разработчик и обязан знать эти настройки. И не просто заучить значения, а понимать за что они отвечают и в каких случаях на какие менять.
В других комментах ниже уже писали, что надо смотреть конкретный профиль приложения под нагрузкой а потом уже что-то менять.
Но вот самый простой пример, когда данный конфиг просто не будет работать (даже при условии озвученной в статье конфигурации сервера): если в приложении есть обращения к сторонним веб ресурсам (например какое либо веб апи) или еще какие либо операции которые легко могут занять все воркеры. Даже при небольшом увеличении задержки от внешнего апи, есть шанс полностью приложить все приложение, а сервер будет вообще не загружен. Это не значит что надо ставить динамический пул, это о том что настройки надо менять осознанно исходя из конкретного приложения (иногда даже приходится несколько пхп пулов для одного приложения делать, только чтобы критичные операции работали независимо от некритичных)
Не могу согласиться - работа разработчика в основном заключается в написании кода. За поддержку серверов отвечают другие люди - админы, девопсы.
Нормальный разработчик должен знать принципы как работает сервис на котором выполняется код. почему-то ни у кого не возникает вопросов, что разработчик на ReactPHP обязан знать как запустить и настроить ReactPHP демона и обязан понимать что такое ивентлуп. А вот когда речь о классическом php-fpm — понимание его работы и настройки внезапно не требуется.
Это имеет такое же отношение и к базе данных — разработчик обязан знать хотя бы в базовых понятиях как она работает (что такое индексы, как они работают, когда бывают блокировки и т.д.)
Надеюсь не стоит объяснять что криво написанный код никакой админ не сможет заставить нормально работать.
Но это речь только о нормальном разработчике, джуну на галере конечно это не надо.
К тому же у меня был ответ на это заявление:
Бывают же ситуации когда админа нет и сервер настраивает и поддерживает сам разработчик.
В этом случае тем более разработчик обязан знать как настраивать и понимать что он делает. А не использовать такие "полезные" туториалы.
P.S. Здесь речь именно о связки php-fpm + nginx (другие языки, другой деплой, могут быть свои нюансы)
Фрилансерам это очень полезно. У них нет толпы девопсов и админов.. да и лучше быть грамотным, даже когда они есть
Примерно с этого момента начинаются отличия кодера от инженера программного обеспечения.
Не смотря на то что сейчас 2021 год, космические корабли уже вылетают за пределы нашей солнечной системы, интернет существует уже 52 года, 30 лет как существует World Wide Web, 20 лет как существует wikipedia и порождённая ей культура всяких wiki, не смотря на всё на это, в нашей многострадальной, богом хранимой стране (ну или по крайней мере на нашем великом и могучем языке) так и не смогли создать ресурс, на котором всё вот это собиралось бы и хранилось. Есть миллион бложеков, сотня-другая тысяч мануалов, подробно описывающих как подключить базовый репозитарий к убунте и установить php с настройками по умолчанию. Возможно среди них и затесалась та самая статья которая описывает все эти известные с древнейших времён прописные истины, очевидные каждому адепту *nix администрирования. Но она там утонула и чтобы её найти нужно провести полноценные археологические раскопки. А так базовые циферки прямо на хабре.
Ну а вообще, к сожалению, материала с простыми базовыми опорными формулами задания основных параметров всякого софта типа "сервер приложений", с которых можно хотя бы начать играться с цифрами не так чтобы много. А если много, ссылки в студию.
По мере аврального выкатывания все новых курсов, уже для основной массы студентов, пришлось пройти последовательные стадии перехода:
* bare metal (16 Core Xeon/ 16G);
* два облачных сервера (32 Core / 32G каждый, один под nginx + php-fpm, другой под mysql);
* уменьшение ресурсов до 24 Core / 16G и 8 Core / 24G по результатам трехмесячного мониторинга.
Типичная нагрузка в рабочее время ≈100 запросов в секунду, в пиках до 300 и более. 2300 студентов. Какой-никакой, но хайлоад.
Толкового и комплексного ликбеза рунете не нашел. Да и в буржуйнете тоже (правда, там не особо искал). По мере вылезания разнообразных ошибок и отказов находил разрозненные заметки и крутил настройки, сверяясь с мануалами. Дефолтные настройки под такую нагрузку не годятся категорически!
Настраивать пришлось буквально всё: nginx, php, memcached, mysql и параметры ядра linux. Возникала, было, мысль написать статейку на хабр в помощь таким же бедолагам, да так и ушла. И от банальной непроходящей усталости от работы (мне этот мудль сбоку припека, админить пришлось просто потому, что больше некому. И от атмосферы на нынешнем хабре — администрация такой контент безразличен, сообщество же активно хейтит.
Взять хотя бы этот пост: «разработчик должен знать! девопс должен знать! админ должен уметь это и намного больше!» — а откуда он должен все это познать, скромно умалчивается. Ну написал бы сам статью, раз такой крутой профессионал — но нет, одни пустые поучения: «обратитесь к специалисту», «работу должен делать профессионал». Спасибо, хоть, не «вон из профессии!»
Провинциальный бюджетный вуз, какие там крутые *nix-админы и девопсы… Сисадмин у нас классический мышевоз-виндузятник, ничем помочь не мог. Нанять кого-то со стороны вне штатного расписания — величайший геморрой с бюрократией. Да и найди еще такого, не говоря уж, чтобы заинтересовать. В общем, сам себе сисадмин, крутись, как хочешь.
А вот скажите, а чем бы данная статья помогла в вашем случае?
ничем
Согласен, статья слабенькая, но зачем же автора ругать? Он хотя бы старался помочь таким, как он.
Ни вы, ни я ничего такого не сделали.
Так это же медвежья услуга!
Вот еще раз повторюсь — это НИКАК не поможет новичкам, они просто скопируют все для своей вдски и угадайте что получится? Почему вдски — потому что именно с них начинают новички
Почему никак? Довольно подробно расписано что и почему сделано, с примером. Новичку как раз самое то. А не сухое "ну вот тут поставим 42, потому что так будет хорошо".
уже в комментах несколько расписали что не так со статьей:
- цифры взяты с потолка (почему именно на 2 или на 4 умножать)
- если это статья для новичка, то сразу надо ббыло написать что это настройка только для выделенного сервера с большим количеством памяти, а для обычной вдски не подойдет (по многим причинам). Новичек скорее всего будет работать именно с вдск-ой
И самая большая проблема, что эта статья будет забивать поисковую выдачу того же гугла, потому что во превых статья новая, а во вторых с трастового ресурса (с хабра). И в результате от статьи будет больше вреда чем пользы именно для новичков.
А и еще, если бы автор хотел он бы уже добавил уточнения в статью, но считает что и так все норм, значит цель была просто сделать акк со статьей на хабре и не важно каким именно материалом.
комплексного howto «как настроить вебсервер под внезапно подскочувшую нагрузку» в условиях цейтнота.
А не может быть одинакового howto ответа для разных приложений.
Провинциальный бюджетный вуз, какие там крутые *nix-админы и девопсы… Сисадмин у нас классический мышевоз-виндузятник, ничем помочь не мог.
Вам не кажется что именно в этом была проблема, а не в отсутствии howto?
А не может быть одинакового howto ответа для разных приложений.Может. Если, конечно, это не тупой набор копипасты из командной строки.
Вам не кажется что именно в этом была проблема, а не в отсутствии howto?Мне ничего не кажется, я просто знаю. Проблем в моем конкретном случае несколько, но ни к хабру, ни к теме howto по хайлоаду они не относятся.
Может. Если, конечно, это не тупой набор копипасты из командной строки.
Тогда это будет уже не howto, а целая книга по администрированию, мониторингу и отладке приложений :)
Общие рекомендации конечно можно кратко расписать, но всегда есть нюансы, описание которых будет в разы больше основы.
(off)
А что за шняга с временем на редактирование — в этом свеженаписанном каменте остаток времени меньше 15 минут? Было же 30 раньше.
Проверил в другой статье — там 30 минут дается.
Это результат последних обновлений на хабре :(
Спасибо jarvis394 за его проект «habra.», там читать намного комфортнее.
На старом хабре такие статьи уходили в глубокий минус. И причина довольно банальна — довольно низкий технический уровень.
Здесь объективно довольно убогая инструкция, без объяснения того зачем это надо и без описания нюансов. И написано в стиле — делай именно так. И рассчитана на дальнейший копипаст. А зачем, почему и вообще будет ли это работать — это уже не важно.
Но, например статья по типу — берем такой-то хостинг (например бесплатный оракл клауд), такой-то конфиг и настраиваем вдс-ку для какого-то типичного пхп приложения. Т.е. настраиваем все, включая базу, пхп и т.д. С комментариями где что подкрутить в зависимости от нагрузки (ну вдс-ка ведь имеет ограниченные ресурсы и везде компромиссы) Такой вариант мануала был бы полезен как раз для новичков. Но не данная статья.
А данная статья кроме того что имеет очень низкий технический уровень, еще и в девопс хабе… ну просто нет слов.
Не нужен уровень профессионального издания, но статья даже не пересказывающая правильно мануал для файла настроек php-fpm — это перебор. Зато куча картинок. Еще бы видосик — было бы вообще в тренде.
В последнее время пошел тренд — не важно какой херь творишь, но ни в коем случае нельзя критиковать. Ведь старается человек, это главное, а то что результат сомнительного качества — это уже не важно. Но это порочная практика в технических специальностях и плохо если вы этого не видите.
А сейчас тут холодно, неуютно и сплошные переводы новостей.
То что сейчас хабр это площадка коммерсов и журналистов копирайтеров — это следствие политики администрации хабра. И данная статья никак не может улучшить эту ситуацию, вернее она только ее подтверждает — формально это рерайт перевод c английского из внутренностей php-fpm.conf. То что было добавлено куча бесполезных скриншотов, не делает эту статью лучше. Т.е. от данной сттьи на хабре теплее не станет.
И еще судя по тому что автору не интересно участвовать в обсуждении, еще раз показывает что ему главное было сделать аккаунт со статьей и все, а что в статье и какого она качества — не важно.
Ну не знаю, мне как новичку в этом деле данная статья очень полезна, всё по существу, без воды и с реальным примером, а главное формулами, а не просто описанием параметров конфига. Просто автору надо было сделать статью с тегом tutorial и озаглавить что тутор для новичков, чтобы devops-отцы не канючили что это должен знать каждый ))
Какая-нибудь аналогичная статья, здесь или на другом сайте за 2009-2013 года ничем не хуже.
"Какая-нибудь"... Вы в курсе, что обычно в таких случаях дают ссылки, а не плескают свой токсичный яд?
поиск по хабру сразу находит это:
https://habr.com/ru/company/southbridge/blog/460511/
pm static м другие режимы раскрыты в разы полнее. Да перевод, но все равно лучше чем данная статья. Единственный минус — придется читать и думать, просто копипаст не получится сделать.
По оптимизации php-fpm просто куча материалов в инете, главное определиться для чего нужно оптимизировать, для высокой нагрузки, для ограниченных ресурсов и т.д.
Где Вы там формулы увидели, 4х и 2х от количества ядер - это не формула, это пальцем в небо. Нужно все тестить и все зависит от каждой конкретной ситуации, в большинстве случаев оно сработает, но там где нагрузка присутствует, хотя бы кратковременная - это уже время на настройку. Приведу пример из практики, впервые про эти настройки я узнал от гугла во время поиска причин проблем из логов (когда не хватает воркеров, то в лог пишется предупреждение), при чем проблема была на не самом посещаемом сайте из-за разогрева кеша - курл обходил 100+ страниц в несколько потоков при этом запускался на этом же сервере, то есть сетевых задержек не было. Сервер - обычная дешевая ВПСка с одним vCPU и 1Гб ОЗУ, сайт при этом не падал, но начинать тупить. Подняли лимиты на макс.количество воркеров, ещё раз и ещё несколько раз пока воркеров не стало хватать для обхода всех страниц и установили минимальное количество для обычной нагрузки. Поэтому, вместо установки 4х от чего-то и так далее нужно установить логи в 1 в php.ini и указать путь и периодически их просматривать, а потом уже делать вывода на основании того насколько сервер справляется.
К чему тут девопсы-отцы. Я не девопс, администрированием занимаюсь только потому что мне надо чтобы мои проекты работали именно так как мне надо. И базовые настройки настройки php-fpm в связке с nginx-ом это первое что приходится узнавать.
Пользы от этой статьи ровно ноль, я бы даже сказал что отрицательная польза, потому что какой-то новичок просто погуглив найдет эту "инструкцию" и решит "протюнить" например свой бложик на вордпресс на убитой вдс-ке. Надеюсь не стоит объяснять что у него после этого получится?
Если бы статья была по типу описание полезных настроек php-fpm и nginx, которые может понадобится изменить (типа расширенного мануала с примерами, но только учитывая особенно пхп приложений). Вопросов бы не возникало.
Мы на сервере на 16vcpu и 16RAM не стесняемся и ставим до 300 static воркеров. С ОЗУ никогда проблем не было, потому что первым умирает CPU. Понятное дело 300 одновремнных запросов сервер не потащит, но зато бОльшее количество воркеров поможет сгладить некоторый воркер-leak приложения, которые всегда бывают.
В конкретно описанном случае решением так же может стать переход на swoole или roadrunner, так как команда laravel подготовила фрэймворк к таким штукам.
А смысл вообще обращать внимание на оперативную память и минимизировать число воркеров?
Если нормальная виртуалка KVM (или свой реальный железный сервер) - там можно своп сделать на диске на 20-30 гиг (уже как правило NVMe) - при исчерпании оперативки (в пике запросов) всё будет работать, но немного медленнее. И то не сильно - так как часть страниц уже заранее собрана и сервер отдает кэш HTML.
Если OpenVZ - то при исчерпании памяти будет краш (точнее будут выкинуты часть процессов) - но и изначально нет смысла использовать OpenVZ для таких нагруженных приложений, которые хотят одновременно много пользователей.
И как выше правильно написали - "первым умирает CPU" :)
sleep != нагрузка
в реальности будет гораздо хуже
Но зачем же текст публиковать в виде картинки? Такой текст нельзя скопировать, нельзя увеличить, нельзя найти встроенным поиском.
Неужели действительно проще сделать скриншот, возможно как-то его обрезать, залить на хостинг и вставить ссылку, нежели чем скопировать и в ставить текст между тегами code?
<?php
echo "Example code";
Это где такой дефолтовый конфиг php-fpm?
Спасибо за статью. Лично мне она пригодится как то, отчего можно оттолкнуться для своих проектов.
Т.к. от автора нет ни одного комментария ни в данном обсуждении, ни вообще на хабре, все больше склоняюсь что это еще один из аккаунтов ботнетов для плюсования/минусования.
pm.max_children - максимальное количество процессов единовременно работающих. Часто это значение ставится в количестве 4 * на количество CPU. Для того чтобы узнать количество CPU можно воспользоваться командой lscpu.
@anton-tsevmenko Кажется, это рекомендации для параметра start_servers.
В других ресурсах max_children рекомендуют рассчитывать по следующей формуле:pm.max_children = Total RAM dedicated to the web server / Max child process size
А если приложение крутится в докере, какой подход правильнее: подкрутить php-fpm или просто поднять N дополнительных контейнеров для распределения нагрузки?
Как ускорить приложение за счёт PHP-FPM (няшим FPM conf)