В первом описываемом случае был поставлен как раз тот самый Nginx из бэкпортов, на неделе поставлю оригинальную сборку последней версии предоставленную производителем. Вообще, мне кажется, дело там всё-таки в ядре либо в PHP - попытки установить соединения nginx делает, соединения в состоянии SYN_SENT и SYN_RECV в проблемные периоды существуют в количестве до двух тысяч штук каждого типа, но вот PHP что-то не получает их не смотря на валидные accept() и poll(). В пятницу уменьшил бэклог (в php-fpm, а не в sysctl) с 512 до 0 и возможно проблема перешла в новую фазу - nginx теперь периодически не может установить соединение с бэкендом, есть проблемные периоды когда соединения к php-fpm отваливаются по 20-50 штук в секунду, что плохо, но на фоне 1000-1500rps не так уж смертельно. Ну и для сравнения устанавливаю сервер на CentOS 6, поставлю там свежий PHP и Nginx, включу бэклог и посмотрю, что получится из этого.
По вопросу сокета - я когда-то давно пробовал это сделать - захлёбывалось оно на каких-то совершенно незначительных величинах, причём отдебажить процесс весьма сложно - netstat информации по подключению к сокету практически не даёт, CLI-утилиты которая бы посылала FastCGI-запрос в сокет (вытащить внутренний статус из php-fpm) тоже не нашлось, короче сокеты локальные - тёмное дело. Ну и помимо прочего интересует единообразие конфигураций - у меня далеко не везде по одному сервере, обычно как минимум их два, на каждом nginx и php и запросы обрабатываются обоим "перекрёстно" - т.е. локальный PHP прописан первым апстримом, а php на втором-третьем-четвёртом-etc сервере - следующими, возможно с меньшим весом. 2013/11/23 Andrey Melnikoff <temnota+n...@kmv.ru> > Bogdan <bog...@gmail.com> wrote: > > [-- text/plain, encoding base64, charset: KOI8-R, 77 lines --] > > > 2013/11/20 Eugene Berdnikov <b...@protva.ru> > > > > On Wed, Nov 20, 2013 at 12:03:50PM +0300, Bogdan wrote: > > > > > On Tue, Nov 19, 2013 at 11:58:33PM +0300, Bogdan wrote: > > > > > > Т.е. непонятно по какой причине poll() зависает на 5 секунд > блокируя > > > > > работу > > > > > > интерпретатора.^M > > > > > > > > > > Скорее всего, по той причине, что никаких данных по сети не > приходит. > > > > > > > > Не совсем тут понятно, что значит "никаких данных по сети не > приходит" - > > > > т.е. удалённая сторона, в данном случае nginx, установила > tcp-соединение, > > > > но данных в него не послала? > > > > > > Может быть и так, но возможно данные посылались и потерялись где-то > > > по пути... Нужно не фантазировать а опираться на факт, что poll() > вышел > > > на таймаут, значит, скорее всего на хосте-приёмнике данных не было. > > > И самый быстрый способ проверить это -- посмотреть дамп трафика. > > > После чего уже понятно, ядро виновато или локальная сеть. > > > > > > > > Сегодня проблема воспроизвела на другом сервере, где nginx > > (1.2.1-2.2wheezy1) и php 5.4 на Debian 7, расположены вместе и коннект > > проходит сугубо через локалхост. > Если через localhost - то зачем оно в tcp ходит, а не через сокет ? > > > Выглядело это следующим образом: > > > И кого тут подозревать? PHP или ядро, куда двигаться дальше? > Для начала поставить nginx 1.4.1-3~bpo70+1 из бакпортов. > > > -- > To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/l0h6ma-spi....@woofie.cef.spbstu.ru > > -- WBR, Bogdan B. Rudas
