PHP-FPM на рабочем сервере под Debian 6?

Question

[Андрей Прокопюк]

Существует сервер под Debian 6, который не должен надолго упасть. На нем есть nginx и php-cgi, запущенный через start-stop-daemon, таким образом создан FastCGI.



Но когда появился большой трафик (примерно 2-3 000 одновременных соединений), появилась проблема ошибки 502, которая возникает даже не смотря на небольшую нагрузку на процессор и память.



Изученный материал подсказал, что PHP-FPM гораздо лучше справляется с задачей, но как его поставить, чтобы не нарушить существующую экосистему?



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



Можно ли как-то по-другому установить php5-fpm на Debian 6?



UPD, 2012-05-06. Было много сделано для решения этой проблемы. Сейчас php5-fpm установлен, процент ошибки 502 близок к нулю, в комментариях можно посмотреть пути решения проблемы.



Дополнительно можно сказать, что можно установить php5-fpm и новую версию nginx из репозиториев unstable и testing:

#UNSTABLE
deb http://ftp.ru.debian.org/debian/ unstable main non-free contrib
deb-src http://ftp.ru.debian.org/debian/ unstable main non-free contrib

#TESTING
deb http://ftp.ru.debian.org/debian/ testing main non-free contrib
deb-src http://ftp.ru.debian.org/debian/ testing main non-free contrib

Чтобы исключить ошибку 502, нужно подобрать оптимальные параметры php5-fpm и оптимизировать приложение. К примеру, в моем и еще одном случае помогло исключение сессий или переопределение стандартного механизма с исключением записи их в файлы.



Также PHP 5.4 работает заметно быстрее, и php5-fpm справляется с помощью меньшего количества процессов.

Answer 1

[ajaxtelamonid]

Правильно делаете, что не доверяете dotdeb.org. Я лично ничего больше от них ставить не буду, был негативный опыт, причем два раза.

Поставить php-fpm можно вот таким способом: www.zagirov.name/debian-testing-install-php5-fpm
Т.е. по сути этот пакет одинаков для любого php 5.3. Достаточно просто убить внутри пакета зависимость от версии и можно ставить. Я это проделал у себя, все работает.

Comments

[Андрей Прокопюк]

Спасибо, это хорошее решение, я использовал его. Жалко, что разработчики Дебиана убрали пакет из репозиториев без любой возможности получить его.

[Андрей Прокопюк]

Могу дополнительно сказать, что можно установить все из репозиториев unstable и testing:

#UNSTABLE
deb http://ftp.ru.debian.org/debian/ unstable main non-free contrib
deb-src http://ftp.ru.debian.org/debian/ unstable main non-free contrib

#TESTING
deb http://ftp.ru.debian.org/debian/ testing main non-free contrib
deb-src http://ftp.ru.debian.org/debian/ testing main non-free contrib

Answer 2

[Андрей Прокопюк]

И уже минус в карму. Неужели такой плохой вопрос? Ведь это действительно может помочь и мне и другим людям с подобной проблемой.

Answer 3

[Алексей Сундуков]

>Но когда появился большой трафик (примерно 2-3 000 одновременных соединений),
>появилась проблема ошибки 502
php-fpm это не серебряная пуля которая решить данную проблему. Очевидно же, что суть проблем в том, что бэкэнд не успевает переварить такой всплеск нагрузки. Как я понял, при это есть свободные ресурсы, значит нужно крутить настройки сервера.

Увеличте backlog бэкэнда, запросы которые он не сможет принять буду ставиться в очередь. Но увлекаться этим не стоит, пользователь не будет у вас ждать, пока его запрос из backlog будет бэкэндом взят и обработан. Значит смотрите в сторону ускорения приложения. Сколько времени генериться страница? Если ли страницы которые одинаковы для всех? Выносите их в memcached и забирайте самим nginx-ом, не дергайте лишних раз бэкэнд. Включены ли акселераторы в духе XCache? Все ли скрипты при этом в кэше? Как обстоят дела с соединения к базе, сколько по времени они занимаются? Используется ли кэширование на этом уровне? К примеру, у меня в случае забора ответа от СУБД страница в среднем на одном проекте генерится ~15-20 мс, если данные забираются из кэша в роли которого работает Redis, то величина падает до ~2-10 мс, т.е. до 10 раз. И бэкэнд готов обрабатывать следующий запрос.

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

Comments

[Андрей Прокопюк]

Да, так и произошло — ситуация сглажена, но не исправлена. Будем исследовать приложение, оптимизировать.

Можно ли поподробнее про backlog?

[Андрей Прокопюк]

В смысле, backlog — известная вещь, но я знаю, что есть в php-fpm некоторые тонкости работы с ним. Например, по умолчанию он равен -1, но это на самом деле не обозначает unlimited. Есть ли материалы по таким настройкам?

[Алексей Сундуков]

Это означает «по дефолту как в ОС». На сколько я помню в линухе это 128. Но тут есть даже не фишка, а хм… я думаю бага. Это задуманно было, что -1 это по дефолту, реально же оно 0. По крайне мере когда я по быстрому проверял, оказалось, что 0. Возможно, стоило бы еще с таймаутами поиграться. Но это уже детали, по умолчанию backlog для php-fpm работает совсем не так, как от него ожидается.

[Алексей Сундуков]

>Можно ли поподробнее про backlog?
В первом приближении это очень, в которую php-fpm должен ставить запрос полученный от nginx в случае, если у него нет свободных рабочих процессов. Как только появится свободный воркер он тут же получит запрос с ходу из этой очереди. Клиент в этом случае получать 502 не будет (по крайне мере до наступления таймаутов).

Увеличивая backlog нужно понимать, что 1) очередь требует ресурсов, копеечных, но ресурсов, поэтому на нагруженных серверах она обычно небольшая, проще 502 отдать; 2) клиент по полминуты ждать не будет (я думаю и самому приходилось закрывать вкладки на которых ни чего не происходило, ни контента нет, ни 502, но браузер показывает, что грузит данные) поэтому делать очень большой нет смысла, но части клиентов при пиках она может помочь (ну подождут загрузки страницы не 1 сек, а 5, тоже не очень хорошо, но все лучше 502-ой).

Если ОЗУ есть, то в php-fpm можно поиграться настройками количества рабочих процессов. В наше время это динамическая величина (в бытность fpm патча был только статический режим). Сильно увлекаться тоже не стоит, на линух сервере обязательно должна быть «свободная» ОЗУ ибо линух всю свободную память использует под дисковый кеш. При малом объеме такой памяти можно быстро просесть по диску.

[Андрей Прокопюк]

Да, я уже отыскал информацию по этому поводу. Поставил net.core.somaxconn = 5000, listen.backlog = 5000; но ошибка 502 все равно осталась.

Что интересно, процессор загружен где-то на 15% максимум, свободной оперативной памяти несколько Гб, HDD не сильно проверялся, но вроде бы нет усиленной нагрузки. Как же использовать эти ресурсы?

[Андрей Прокопюк]

Тут еще есть такая особенность, что можно немного пожертвовать временем ожидания клиента. Это сервер не для сайта, а для обслуживания запросов от игры. Конечно, плохо, если в клиенте между переходами идет загрузка на несколько десятков секунд, но еще хуже, если игра упадет из-за 502 ошибки.

[Алексей Сундуков]

Если лимиты на уровне ОС подняты, то их так же стоит подкручивать в nginx и php-fpm. Как я уже писал выше в php-fpm при дефелтном значении в -1 работает не так ожидается. Так что нужно явно задавать настройки.

Еще раз повторю, если если есть свободная ОЗУ, то увеличивайте количество рабочих процессов. Хотя для начала стоило бы убедиться, что дело действительно в этом. Включайте в php-fpm статистику на странице /status и смотрите что происходит. Самые любопытные поля: active processes — количество текущих работающих воркеров, max children reached — сколько раз мастер процесс пытался запустить дочерние процессы, но не смог из-за pm.max_children (если больше 0, то проблема имеет место быть).

Кстати, лучше изменить дефолтный pm.status_path=/status на что-то в духе pm.status_path=/status-phpfpm, т.к. лично у меня не удалось заставить связку nginx+php-fpm показывать статистику. Как я понимаю из-за того, что у nginx есть точно такая же страница со статистикой. У меня он передавал запрос на php (видно по заголовку power-by), но страницы была пустая.

Из любопытства на одном проекте запустил нагрузку с 2 машин. Конфиг сервера:

pm                      = dynamic
pm.min_spare_servers    = 2
pm.max_spare_servers    = 4
pm.start_servers        = 4
pm.max_children         = 10

Опции запуска нагрузки на каждом из клиентов:

httperf --hog --server ... --uri="..." --num-conns=1000 --num-calls=1 --rate 500

т.е. генерировать поток запросов в количестве 1000 со скоростью 2 мс (500 запросов в секунду), все запрос не в keep-alive режиме. Соответственно нагрузка на сервер 1000 запросов/сек. Ни одной 5хх ошибки. На клиентах:
одновременых коннектов: 1 — 280; 2 — 774
медиана времени ответа: 1 — 0,28 сек (ибо этот клиент в той же стране, что и сервер) 2 — 2,9 сек.
Нагрузка на проц и ОЗУ ничтожна, ЦП активен только в момент старта дополнительных воркеров. Так что крутите конфиги, делайте нагрузочные тесты.

[Андрей Прокопюк]

Да, лимиты были подняты на уровне ОС и явно выставлены в конфиге php-fpm. Но это не дало результата. Есть ли в nginx'е параметры, которыми можно регулировать эти вещи? Я нашел только параметры для буферизации ответа от бэкенда, неужели нет какой-нибудь очереди запросов?

За статусом слежу, но строки «max children reached» в моем случае нет. Выглядит она так:

accepted conn:   221341
pool:             www
process manager:  dynamic
idle processes:   234
active processes: 630
total processes:  864

Сейчас процент 502 ошибки удалось снизить за счет очень большого лимита процессов (1024). Так же я отключил в приложении сессии (переписал код, чтобы исключить их важность). Но хотелось бы, конечно, еще увеличить надежность.

Приложение достаточно тяжелое — с использованием БД, с генерацией разных битв и других игровых ситуаций, но и сервер мощный, хотелось бы задействовать все его ресурсы.

[Алексей Сундуков]

>«max children reached» в моем случае нет
У меня есть. Но у меня 5.3.8 самосборный через checkinstall.

>Есть ли в nginx'е параметры, которыми можно регулировать эти вещи?
Нет, такого нет. И это правильно. Кроме того даже если и был, то бэкэнд все равно отвечал бы «свободных рабочих процессов нет», что автоматически означает разрыв коннекта. У самого nginx так же есть backlog, но он действует для него и внешних клиентов.

Кстати, если ресурсов не жалко, то можно поставить static режим. ОЗУ будет отжираться стабильно под завязку, но не будет оверхеда на запуск воркеров. Это сэкономит ЦП и время, но заберет ОЗУ. Ибо по мне dynamic механизм по сравнению с apache топорный.

[Андрей Прокопюк]

Сейчас ситуация стабилизировалась. Я думаю, помогло обновление до PHP 5.4.2 — совершенно другая картина. Например, можно сравнить состояние в 5.3.3:

pool:                 www
process manager:      dynamic
start time:           06/May/2012:20:57:24 +0400
start since:          6411
accepted conn:        361043
listen queue:         0
max listen queue:     256
listen queue len:     5000
idle processes:       109
active processes:     1
total processes:      110
max active processes: 281
max children reached: 0

Ошибок 502 больше не было.

[Андрей Прокопюк]

В смысле, сравнить состояние, которое я приводил для 5.3.3 вот с этим, которое наблюдается в 5.4.2

[Андрей Прокопюк]

А вот еще такой вопрос. Как влияет на производительность Keep-alive? Я не до конца понимаю, в каких случаях он дает плюсы — иногда советуют его отключить.

[Алексей Сундуков]

В первом приближении он дает плюсы всегда. Но это не сказывается на скорости генерации ответа бэкэндом. Как оно генерилось, условно 2мс, так и будет генериться. Выгода от keep-alive получается если с бэкэндом связаны какие-то другие данные (картинки там) или идет поток запросов на коротком промежутке времени (в течении полуминуты). Смысл в следующем. Вот берем данную страницу. С ней связанно 19 ресурсов вещих на сервер хабра (1 запрос — сама страница, 18 — разная JS/CSS статика). Если keep-alive отлючен, то браузер открывает 19 разных TCP коннектов. Сама операция открытия пары сокетов достаточно «долгий» процесс, т.к. TCP гарантирует доставку и много времени тратится на согласование данных. Причем на сервере с каждым TCP конектом связаны разные данные, которые под себя так же требуют ресурсы. А это ведь только от одного клиента. Когда клиентов тысячи, то потребление ресурсов это уже не копеечный процесс, опять же повторюсь, установление соединения это очень долгий процесс. Но он открывается на каждый связанный ресурс. Поэтому и появился keep-alive при котором создается одно (возможно и больше, но всегда сильно меньше количества связанных ресурсов) TCP соединение и уже по нему передаются все ресурсы. Т.е. к примеру открытие страницы порождает TCP коннект, по нему сервер отдает страницу и по этому же коннекту передается JS и CSS и картинки. И для них не нужно тратить время на установление связи в виде трехэтапного рукопожатия. Данные можно передавать с ходу ведь надежный канал передачи данных уже установлен.

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

[Андрей Прокопюк]

Ясно, значит, его лучше оставить.

Спасибо большое за помощь!

Может быть, напоследок спрошу еще. Какие материалы можно почитать относительно оптимизации приложений под высокой нагрузкой? Мне много дало прочтение книги «MySQL: оптимизация производительности» от O'Reilly, но этого, конечно, недостаточно.

[Алексей Сундуков]

По мне, нет такого понятия как высокие нагрузки. Соответственно и книги такой нет. Просто нужно понимать механизм работы системы с целом и исходя из этого искать узкие места.

К прочтению могу рекомендовать:
«UNIX. Разработка сетевых приложений.» У. Р. Стивенс, Б. Феннер, Э.М. Рудофф
«UNIX. Профессиональное программирование» Стивенс У. Р., Раго С. А. (2-ое издание, посмертное)
«UNIX. Взаимодействие процессов» Стивенс У. Р.
«Ядро Linux» Д. Бовет, М. Чезати

Вообще Стивенс крайне крут, имхо, к прочтению обязательно любому сетевому программисту. Так же могу рекомендовать «выжимку» в том числе и из этих книг от наших авторов: «Операционная система UNIX»
Андрей Робачевский, Сергей Немнюгин, Ольга Стесик.

[Андрей Прокопюк]

Спасибо!

Answer 4

[NiGHt_LEshiY]

Если вы контроллируете обстановку, можно собрать и поставить php-fpm самому. Желательно адекватным способом, а не make install. (то есть собрать deb-пакет и дать менеджеру пакетов самому поставить его)

Comments

[Андрей Прокопюк]

Можно использовать checkinstall, это известное дело. А есть ли какой-нибудь материал, как собрать и поставить php5-fpm в дополнение к php5-cgi и php5-cli? Чтобы не конфликтовать, использовать те же расширения и так далее.

Answer 5

[odmin4eg]

а чем плох dotdeb? у меня и в убунте и в дебианах разных работает хорошо.
впритом на реальном боевом проекте с 5000-6000 в сутки пользователями, в онлайне правда не как у ТС но всёж.
сервачок купил на ебее за 100 баксов 3 года назад.

тоже валился от нагрузки, настроил кэширование на nginx (это уже после всяких мемкэшедов, еАццелераторов, и прочих штук кэширующих мускул запросы)

Comments

[Андрей Прокопюк]

Были проблемы с ним, поэтому было решено не рисковать.

Answer 6

[rakot]

Может, это не ваш случай, но после 700 конкурентных запросов, у меня на сервере тоже происходил затык.
Дело было в в создании файлов сессий на диск, после переноса сессий в редис от этого избавился.

Comments

[Андрей Прокопюк]

Вполне возможно. Изначально сессии создавались в memcached, но при этом была неразрешимая проблема с запуском сессий в 30 секунд. Можно узнать про редис?

[Алексей Сундуков]

>700 конкурентных запросов, у меня на сервере тоже происходил затык.
Не удивительно ) для php который по дефолту пишет сесии на диск.

>Можно узнать про редис?
А не важно, memcached это или redis, оба in memory хранилища со стремлением к О(1) сложно на выборке. Просто пишем свой обработчик сессий который сериализует данные и закидывает их в это хранилище. Для сериализации рекомендую использовать igbinary.

Хотя при в «Registered save handlers»=memcache или redis, свой обработчик не нужен, extension сам знает куда данные закидывать. redis кстати сериализует в igbinary автоматом, если этот extension подключен. В общем крайне рекомендую к использованию: "Сериализация данных в PHP".

Профит redis перед memcached — условная персистентность. После рестарта он запихает данные в кэш с диска. Теоретически там может не быть заданных на время Х. Время Х регулируется через конфиг. На практике нормальный сервер просто так не грохнется на пустом месте, а на случай штатного ребута redis данные на диск скинет.

[Андрей Прокопюк]

Ясно, спасибо. Буду иметь в виду, если понадобятся сессии. В этом приложении удалось от них избавиться вообще.