Re: poll() timeout в PHP-FPM при получении запросов от Nginx
Bogdan bog...@gmail.com wrote: [-- text/plain, кодировка quoted-printable, кодировка: KOI8-R, 196 строк --] Добрый день. Синкуки - сервер доступен в интернете напрямую, syn flood на tcp/80 периодически случался. Судя по dmesg синкуки активируются только на 80 порт. Поптался под нагрузкой отключить синкуки - не помогло. Они активируется там, куда ядро сичтает что пошел флуд. # netstat -s По показометрам вроде нормально. Но лучше делать несколько diff'ов - за 5 минут, за час и за сутки - динамику будет видно. -- 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/rvkhna-dpn@woofie.cef.spbstu.ru
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
Bogdan bog...@gmail.com wrote: [-- text/plain, кодировка base64, кодировка: KOI8-R, 34 строк --] Добрый вечер. Бэклог в php-fpm я отключил в силу того, что не был полностью уверен, идёт ли речь о tcp-бэклоге, либо просто о некой внутренней очереди. Параметры sysctl (сверх стандартных) следующие: net.core.rmem_default=16777216 net.core.netdev_max_backlog=262144 net.core.somaxconn=262144 net.ipv4.tcp_syncookies=1 ^^^ Это то зачем ??? net.ipv4.tcp_max_orphans=262144 net.ipv4.tcp_max_syn_backlog=262144^M net.ipv4.ip_local_port_range=1024 65535 net.ipv4.tcp_tw_reuse=1 netstat -s покажи -- 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/6e5ema-48h@woofie.cef.spbstu.ru
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
Добрый день. Синкуки - сервер доступен в интернете напрямую, syn flood на tcp/80 периодически случался. Судя по dmesg синкуки активируются только на 80 порт. Поптался под нагрузкой отключить синкуки - не помогло. # netstat -s Ip: 680437848 total packets received 0 forwarded 5 with unknown protocol 0 incoming packets discarded 680434468 incoming packets delivered 1777159635 requests sent out 363 fragments dropped after timeout 5485 reassemblies required 2406 packets reassembled ok 365 packet reassembles failed 4 fragments failed Icmp: 592365 ICMP messages received 1623 input ICMP message failed. ICMP input histogram: destination unreachable: 439442 timeout in transit: 29851 wrong parameters: 1 source quenches: 173 redirects: 3594 echo requests: 117976 144005 ICMP messages sent 0 ICMP messages failed ICMP output histogram: destination unreachable: 25816 time exceeded: 213 echo replies: 117976 IcmpMsg: InType3: 439442 InType4: 173 InType5: 3594 InType8: 117976 InType11: 29851 InType12: 1 OutType0: 117976 OutType3: 25816 OutType11: 213 Tcp: 335720334 active connections openings 475986193 passive connection openings 611418 failed connection attempts 2948223 connection resets received 12328 connections established 680146150 segments received 1976798623 segments send out 80770653 segments retransmited 2023767 bad segments received. 9920587 resets sent Udp: 14213 packets received 26382 packets to unknown port received. 0 packet receive errors 14259 packets sent UdpLite: TcpExt: 27465459 SYN cookies sent 33796620 SYN cookies received 7975762 invalid SYN cookies received 389136 resets received for embryonic SYN_RECV sockets 811 ICMP packets dropped because they were out-of-window 247 ICMP packets dropped because socket was locked 228252760 TCP sockets finished time wait in fast timer 4728737 time wait sockets recycled by time stamp 1520033 packets rejects in established connections because of timestamp 651613807 delayed acks sent 153290 delayed acks further delayed because of locked socket Quick ack mode was activated 15636235 times 15720991 times the listen queue of a socket overflowed 15720991 SYNs to LISTEN sockets dropped 3361873905 packets directly queued to recvmsg prequeue. 2698661925 bytes directly in process context from backlog 2362850595 bytes directly received in process context from prequeue 1310810975 packet headers predicted 2376025214 packets header predicted and directly queued to user 2168271888 acknowledgments not containing data payload received 3603412648 predicted acknowledgments 4468 times recovered from packet loss due to fast retransmit 751825 times recovered from packet loss by selective acknowledgements 1614 bad SACK blocks received Detected reordering 18406 times using FACK Detected reordering 11064 times using SACK Detected reordering 150 times using reno fast retransmit Detected reordering 9035 times using time stamp 18658 congestion windows fully recovered without slow start 27425 congestion windows partially recovered using Hoe heuristic 10709583 congestion windows recovered without slow start by DSACK 15517441 congestion windows recovered without slow start after partial ack 1346870 TCP data loss events TCPLostRetransmit: 171181 6511 timeouts after reno fast retransmit 1538949 timeouts after SACK recovery 246600 timeouts in loss state 2233810 fast retransmits 322817 forward retransmits 2790644 retransmits in slow start 54282107 other TCP timeouts 1051 classic Reno fast retransmits failed 106611 SACK retransmits failed 15829915 DSACKs sent for old packets 1240 DSACKs sent for out of order packets 17886120 DSACKs received 8409 DSACKs for out of order packets received 951323 connections reset due to unexpected data 32014 connections reset due to early user close 921618 connections aborted due to timeout TCPSACKDiscard: 4123 TCPDSACKIgnoredOld: 265129 TCPDSACKIgnoredNoUndo: 1883713 TCPSpuriousRTOs: 8944 TCPSackShifted: 1957011 TCPSackMerged: 2434447 TCPSackShiftFallback: 9448212 TCPBacklogDrop: 155 TCPReqQFullDoCookies: 35379950 TCPReqQFullDrop: 643501 TCPChallengeACK: 1778474 TCPSYNChallenge: 2068557 IpExt: InBcastPkts: 24 InOctets: -648479550 OutOctets: -338174407 InBcastOctets: 10352 # ss -s Total: 17098 (kernel 17789) TCP: 123227 (estab 12438, closed 105609, orphaned 601, synrecv 0, timewait 105609/0), ports 10570 Transport Total IPIPv6 * 17789 - - RAW 0 0 0 UDP 9 5 4 TCP 17618
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
Bogdan bog...@gmail.com wrote: [-- text/plain, кодировка base64, кодировка: KOI8-R, 63 строк --] [skipp] В пятницу уменьшил бэклог (в php-fpm, а не в sysctl) с 512 до 0 и возможно проблема перешла в новую фазу - nginx теперь периодически не может установить соединение с бэкендом, есть проблемные периоды когда соединения к php-fpm отваливаются по 20-50 штук в секунду, что плохо, но на фоне 1000-1500rps не так уж смертельно. а смысл на такой нагрузке отключать баклог ? somaxconn крутилось? что пишет php в еррор-лог в эти моменты? ему хватает дескрипторов чтоб принять соединение? фаирвол есть ? -- 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/aficma-17q@woofie.cef.spbstu.ru
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
Добрый вечер. Бэклог в php-fpm я отключил в силу того, что не был полностью уверен, идёт ли речь о tcp-бэклоге, либо просто о некой внутренней очереди. Параметры sysctl (сверх стандартных) следующие: net.core.rmem_default=16777216 net.core.netdev_max_backlog=262144 net.core.somaxconn=262144 net.ipv4.tcp_syncookies=1 net.ipv4.tcp_max_orphans=262144 net.ipv4.tcp_max_syn_backlog=262144 net.ipv4.ip_local_port_range=1024 65535 net.ipv4.tcp_tw_reuse=1 Фаервол выключен, всё что имело отношение к contrack вообще выгружено из ядра, т.к. contrack без напильника на таких нагрузках не живёт, да и с напильником живёт не очень хорошо. PHP выглядит как живой, регулярно перезапускает воркеры отработавшие свой лимит запросов, rlimit_nofile увеличен до 128000 как для основного процесса, так и для воркеров, эффективность лимита проверялась по /proc/pid/limit - всё действует. 2013/11/25 Andrey Melnikoff temnota+n...@kmv.ru Bogdan bog...@gmail.com wrote: [-- text/plain, кодировка base64, кодировка: KOI8-R, 63 строк --] [skipp] В пятницу уменьшил бэклог (в php-fpm, а не в sysctl) с 512 до 0 и возможно проблема перешла в новую фазу - nginx теперь периодически не может установить соединение с бэкендом, есть проблемные периоды когда соединения к php-fpm отваливаются по 20-50 штук в секунду, что плохо, но на фоне 1000-1500rps не так уж смертельно. а смысл на такой нагрузке отключать баклог ? somaxconn крутилось? что пишет php в еррор-лог в эти моменты? ему хватает дескрипторов чтоб принять соединение? фаирвол есть ? -- 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/aficma-17q@woofie.cef.spbstu.ru -- WBR, Bogdan B. Rudas
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
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
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
В первом описываемом случае был поставлен как раз тот самый 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
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
Добрый день, спасибо за ответ. 2013/11/20 Eugene Berdnikov b...@protva.ru On Tue, Nov 19, 2013 at 11:58:33PM +0300, Bogdan wrote: Т.е. непонятно по какой причине poll() зависает на 5 секунд блокируя работу интерпретатора. Скорее всего, по той причине, что никаких данных по сети не приходит. Не совсем тут понятно, что значит никаких данных по сети не приходит - т.е. удалённая сторона, в данном случае nginx, установила tcp-соединение, но данных в него не послала? Сравнивал с нормальным режимом функционирования системы - там таких пауз и близко не наблюдается. Вероятность отсуствия запроса в течении 5 секунд при интенсивности порядка 1000-1500 запросов в секунуд мне кажется очень маленькой. Рабочих процессов 64, ну максимум 128. Я тоже рассматриваю проблему межсерверной сетью, но варианты какая-то проблема в ядре с одной из сторон и nginx перестал посылать запросы пока не могу исключить. Вероятность проблемы может быть весьма высокой, например 1/60, что при условии получения 1000-1500 запросов в секунду очень болезненно. Подскажите, куда дальше копать? Убедиться, что данных действительно нет, если в этом сомневаетесь. Т.е. tcpdump в руки и искать эту коннекцию. Ну поискать-то в этом потоке будет весьма сложно, потому я и интересовался про ретрансмиты - этот параметр можно посмотреть на сервере где запущен nginx. Но и в самом деле - снифер вполне подойдёт, там тоже будет видно. Коммутатор мне недоступен (внутреннюю сеть предоставляет дата-центр), а потерь на интерфейсах судя по ifconfig нет. Может быть где-то в /proc или /sys есть общесистемный счётчик tcp retransmit для каждого интерфейса либо IP, чтобы проверить версию с потерями пакетов во внутренней сети? Есть общий счётчик: netstat -s (ака /proc/net/netstat). При чём тут счётчик ретрасмиссий -- непонятно: речь же о входящих пакетах, а не исходящих. Все счётчики интерфейса показывает ip -s link dev... Я планировал посмотреть ретрансмиты на сервере который выполняет nginx и шлёт запросы к PHP-FPM, но т.к. tcp-счётчиков для интерфейсов видимо нет, буду использовать снифер. Для проверки версии о потерях пакетов достаточно сравнить счётчики интерфейсов клиента и сервера. Вообще, нормальные свитчи тоже умеют вести статистику по интерфейсам, а также считать дропнутые пакетики. На сервере со счётчиками уровня ethernet всё хорошо, а коммутатор мне к сожалению недоступен. -- Eugene Berdnikov -- 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/20131120065121.gr4...@protva.ru -- WBR, Bogdan B. Rudas
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
В Wed, 20 Nov 2013 12:03:50 +0300 Bogdan bog...@gmail.com пишет: Не совсем тут понятно, что значит никаких данных по сети не приходит - т.е. удалённая сторона, в данном случае nginx, установила tcp-соединение, но данных в него не послала? Сравнивал с нормальным режимом функционирования системы - там таких пауз и близко не наблюдается. Вероятность отсуствия запроса в течении 5 секунд при интенсивности порядка 1000-1500 запросов в секунуд мне кажется очень маленькой. Рабочих процессов 64, ну максимум 128. Я тоже рассматриваю проблему межсерверной сетью, но варианты какая-то проблема в ядре с одной из сторон и nginx перестал посылать запросы пока не могу исключить. Даунгрейд ядра до 2.6.32 (из squeeze) решает проблему? Т.е. я предлагаю выяснить где находится проблема (если она появилась после обновления) - в ядре или в юзерспейсе. -- WBR, Andrey Tataranovich -- 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/20131120122838.5428f4fa@dragoncore.local
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
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 секунд блокируя работу интерпретатора. Скорее всего, по той причине, что никаких данных по сети не приходит. Не совсем тут понятно, что значит никаких данных по сети не приходит - т.е. удалённая сторона, в данном случае nginx, установила tcp-соединение, но данных в него не послала? Может быть и так, но возможно данные посылались и потерялись где-то по пути... Нужно не фантазировать а опираться на факт, что poll() вышел на таймаут, значит, скорее всего на хосте-приёмнике данных не было. И самый быстрый способ проверить это -- посмотреть дамп трафика. После чего уже понятно, ядро виновато или локальная сеть. Вероятность проблемы может быть весьма высокой, например 1/60, что при условии получения 1000-1500 запросов в секунду очень болезненно. Подскажите, куда дальше копать? Убедиться, что данных действительно нет, если в этом сомневаетесь. Т.е. tcpdump в руки и искать эту коннекцию. Ну поискать-то в этом потоке будет весьма сложно, потому я и интересовался Что сложного в том, чтобы найти в дампе коннекции с нужными номерами портов? Просто указываете tcpdump'у номер порта. Там ещё отметки времени есть. Я планировал посмотреть ретрансмиты на сервере который выполняет nginx и шлёт запросы к PHP-FPM, но т.к. tcp-счётчиков для интерфейсов видимо нет, буду использовать снифер. Наличие потерь и ретрансмиссий в сети легко детектируется по опции SACK. Хотя конкретно этот случай (потеря на старте коннекции) так не поймаешь. -- Eugene Berdnikov -- 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/20131120095002.gt4...@protva.ru
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
Andrey Tataranovich tataranov...@gmail.com writes: В Wed, 20 Nov 2013 12:03:50 +0300 Bogdan bog...@gmail.com пишет: Я тоже рассматриваю проблему межсерверной сетью, но варианты какая-то проблема в ядре с одной из сторон и nginx перестал посылать запросы пока не могу исключить. Даунгрейд ядра до 2.6.32 (из squeeze) решает проблему? Т.е. я предлагаю выяснить где находится проблема (если она появилась после обновления) - в ядре или в юзерспейсе. Я предчувствую, что этот человек скорее всего не может выключить сервер, ибо после перезагрузки он просто не поднимется: 1500 запросов в секунду на сервер с пустым кэшем - тот ещё DDoS. Но кстати хороший вопрос всё же - а когда эта проблема появилась, заметили? pgpc8lcdMS937.pgp Description: PGP signature
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
В Wed, 20 Nov 2013 14:52:05 +0400 Dmitrii Kashin free...@freehck.ru пишет: Но кстати хороший вопрос всё же - а когда эта проблема появилась, заметили? В первом письме сказано, что заметили после обновления со squeeze до wheezy. -- WBR, Andrey Tataranovich -- 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/20131120140424.29d942ea@dragoncore.local
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
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 секунд блокируя
работу
интерпретатора.
Скорее всего, по той причине, что никаких данных по сети не приходит.
Не совсем тут понятно, что значит никаких данных по сети не приходит -
т.е. удалённая сторона, в данном случае nginx, установила tcp-соединение,
но данных в него не послала?
Может быть и так, но возможно данные посылались и потерялись где-то
по пути... Нужно не фантазировать а опираться на факт, что poll() вышел
на таймаут, значит, скорее всего на хосте-приёмнике данных не было.
И самый быстрый способ проверить это -- посмотреть дамп трафика.
После чего уже понятно, ядро виновато или локальная сеть.
Сегодня проблема воспроизвела на другом сервере, где nginx
(1.2.1-2.2wheezy1) и php 5.4 на Debian 7, расположены вместе и коннект
проходит сугубо через локалхост.
Выглядело это следующим образом:
20:43:09.699398 write(19, \1\6\0\1\3\324\4\0X-Powered-By:
PHP/5.4.4-14+deb7u5\r\nLast-Modified: Wed, 20 Nov 2013 16:43:09 +
GMT\r\nPragma: no-cache\r\nCon
tent-type: text/javascript\r\nExpires: Wed, 20 Nov 2013 16:43:09
+\r\nCache-Control: must-revalidate\r\nP3P: policyref=\/w3c/p3p.xml\,
CP=\UN..., 1008)
= 1008
20:43:09.699470 shutdown(19, 1 /* send */) = -1 ENOTCONN (Transport
endpoint is not connected)
20:43:09.699504 recvfrom(19, \1\5\0\1\0\0\0\0, 8, 0, NULL, NULL) = 8
20:43:09.699536 recvfrom(19, , 8, 0, NULL, NULL) = 0
20:43:09.699561 close(19) = 0
20:43:09.699682 setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0,
0}}, NULL) = 0
20:43:09.699714 accept(0, {sa_family=AF_INET, sin_port=htons(7837),
sin_addr=inet_addr(192.168.1.2)}, [16]) = 19
20:43:09.699750 time(NULL) = 1384965789
20:43:09.699775 times({tms_utime=1902, tms_stime=373, tms_cutime=0,
tms_cstime=0}) = 2323052248
20:43:09.699802 poll([{fd=19, events=POLLIN}], 1, 5000) = 0 (Timeout)
20:43:14.705014 close(19) = 0
20:43:14.705281 accept(0, {sa_family=AF_INET, sin_port=htons(3676),
sin_addr=inet_addr(192.168.1.2)}, [16]) = 19
20:43:14.705435 time(NULL) = 1384965794
20:43:14.705583 times({tms_utime=1902, tms_stime=373, tms_cutime=0,
tms_cstime=0}) = 2323052748
20:43:14.705706 poll([{fd=19, events=POLLIN}], 1, 5000) = 0 (Timeout)
20:43:19.707391 close(19) = 0
20:43:19.707519 accept(0, {sa_family=AF_INET, sin_port=htons(56862),
sin_addr=inet_addr(192.168.1.2)}, [16]) = 19
20:43:19.707558 time(NULL) = 1384965799
20:43:19.707582 times({tms_utime=1902, tms_stime=373, tms_cutime=0,
tms_cstime=0}) = 2323053249
20:43:19.707607 poll([{fd=19, events=POLLIN}], 1, 5000) = 0 (Timeout)
20:43:24.711363 close(19) = 0
20:43:24.711482 accept(0, {sa_family=AF_INET, sin_port=htons(40505),
sin_addr=inet_addr(192.168.1.2)}, [16]) = 19
20:43:24.711524 time(NULL) = 1384965804
20:43:24.711548 times({tms_utime=1902, tms_stime=373, tms_cutime=0,
tms_cstime=0}) = 2323053749
20:43:24.711575 poll([{fd=19, events=POLLIN}], 1, 5000) = 1 ([{fd=19,
revents=POLLIN}])
20:43:24.711608 read(19, \1\1\0\1\0\10\0\0, 8) = 8
20:43:24.711638 read(19, \0\1\0\0\0\0\0\0, 8) = 8
20:43:24.711670 read(19, \1\4\0\1\5\36\2\0, 8) = 8
20:43:24.711698 read(19, \f\200\0\0\352QUERY_STRING..
Т.е. после успешного запроса - несколько подряд попыток почитать
что-нибудь из соединения, последняя оказывается успешной.
Из не нормального: количество соединений в состоянии SYN_SENT на порт
PHP-FPM было более 1000 постоянно, SYN_RECV - чуть меньше.
После растарта php-fpm на этот раз всё самой собой прошло, в netstat
соединений на порт PHP нет. К сожалению ребут от этой беды спасает далеко
не всегда.
Но по крайней мере, раз всё воспроизводится в пределах одного сервера -
проблему интерконнекта наверное пока можно перестать рассматривать.
Дамп трафика в этот момент у меня получился без таймингов,
tcp.analysis.retransmission показал два десятка пакетов - повторная
передача [PSH, ACK] от nginx к PHP, всего в дампе ~50k пакетов.
И кого тут подозревать? PHP или ядро, куда двигаться дальше?
poll() timeout в PHP-FPM при получении запросов от Nginx
Добрый день.
Debian 7 amd64, PHP-FPM 5.4.4 изх комплекта дистрибутива.
Регулярно (несколько раз в неделю, иногда - несколько раз в день)
сталкиваюсь с ситуацией непонятного торможения php-fpm, выглядит этот как
резкое уменьшение количества коннектов к БД и полностью забитом бэклоге
FPM. Варианты типа подключение ко внешним сайтам и т.п. исключили из кода.
Потыкал strace в воркеры (их у меня 64 обычно на один веб-сервер).
В проблемные периоды есть анамалия выглядящая следющим образом:
00:16:17.507658 accept(0, {sa_family=AF_INET, sin_port=htons(19554),
sin_addr=inet_addr(1.2.3.4)}, [16]) = 67
00:16:17.508000 time(NULL) = 1384892177
00:16:17.508190 times({tms_utime=84, tms_stime=22, tms_cutime=0,
tms_cstime=0}) = 1780948166
00:16:17.508505 poll([{fd=67, events=POLLIN}], 1, 5000) = 0 (Timeout)
00:16:22.513709 close(67) = 0
00:16:22.513922 accept(0, {sa_family=AF_INET, sin_port=htons(29537),
sin_addr=inet_addr(1.2.3.4)}, [16]) = 67
00:16:22.514073 time(NULL) = 1384892182
00:16:22.514190 times({tms_utime=84, tms_stime=22, tms_cutime=0,
tms_cstime=0}) = 1780948667
Ну и далее следует успешный poll() и чтение запроса от веб-сервера.
fd=67 - это подключение от nginx на соседнем сервере.
Т.е. непонятно по какой причине poll() зависает на 5 секунд блокируя работу
интерпретатора. Вероятность проблемы может быть весьма высокой, например
1/60, что при условии получения 1000-1500 запросов в секунду очень
болезненно.
Подскажите, куда дальше копать?
Может быть где-то в /proc или /sys есть общесистемный счётчик tcp
retransmit для каждого интерфейса либо IP, чтобы проверить версию с
потерями пакетов во внутренней сети?
Отдельно беспокоит тот факт, что проблемы начались после переезда с 6 на 7
версию ОС.
Заранее благодарен за советы.
--
WBR, Bogdan B. Rudas
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
On Tue, Nov 19, 2013 at 11:58:33PM +0300, Bogdan wrote: Т.е. непонятно по какой причине poll() зависает на 5 секунд блокируя работу интерпретатора. Скорее всего, по той причине, что никаких данных по сети не приходит. Вероятность проблемы может быть весьма высокой, например 1/60, что при условии получения 1000-1500 запросов в секунду очень болезненно. Подскажите, куда дальше копать? Убедиться, что данных действительно нет, если в этом сомневаетесь. Т.е. tcpdump в руки и искать эту коннекцию. Может быть где-то в /proc или /sys есть общесистемный счётчик tcp retransmit для каждого интерфейса либо IP, чтобы проверить версию с потерями пакетов во внутренней сети? Есть общий счётчик: netstat -s (ака /proc/net/netstat). При чём тут счётчик ретрасмиссий -- непонятно: речь же о входящих пакетах, а не исходящих. Все счётчики интерфейса показывает ip -s link dev... Для проверки версии о потерях пакетов достаточно сравнить счётчики интерфейсов клиента и сервера. Вообще, нормальные свитчи тоже умеют вести статистику по интерфейсам, а также считать дропнутые пакетики. -- Eugene Berdnikov -- 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/20131120065121.gr4...@protva.ru
