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 или ядро, куда двигаться дальше?
nut, usbhid-ups, Powercom WOW
Привет. Что-то я туплю, и не могу нагуглить решение. Доку от начала до конца еще не читал. Итак. wheezy, amd64, nut-server 2.6.4-2.3 Если написать в /etc/nut/ups.conf [powercom] driver = usbhid-ups port = auto и позвать /lib/nut/usbhid-ups - -a powercom то драйвер пишет failed to claim USB device: could not claim interface 0: Operation not permitted failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted и отваливается. Если добавить перед секцией user=root то прав ему хватает, но не хватает прав upsd, чтобы связаться с драйвером: upsd[3302]: Can't connect to UPS [powercom] (usbhid-ups-powercom): Permission denied Если добавить еще UPSD_OPTIONS=-u root в /etc/nut/nut.conf, то вроде как все поднимается нормально, но, блин, не зря же он по умолчанию запускается под юзером nut, а не под рутом. Где бы чего подкрутить, чтобы ему рута было не надо? Вряд ли же пакет делают так, чтобы он не работал из коробки с большинством упсов... Еще, надо сказать, я нагуглил в процессе дополнительную опцию pollonly в секцию упса. Надо сказать, что если поставить pollonly, то драйвер дебаггинг выводит гораздо более тихий, но вроде, демон работает и без нее... -- 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/8738mr3oyo@wizzle.ran.pp.ru
ICU
Может быть кто-нибудь пользовался libicu для перекодировки? Наверняка тут есть такие. :-) Подскажите пожалуйста. Мне нужно перекодировать строго в/из ASCII-7. Если в источнике или в результате есть символы с кодом больше 127, я хочу получить ошибку. Использую ucnv_convertEx(), например передавая в качестве from энкодера, энкодер с кодировкой US-ASCII. Но чтобы там ни было в старшем бите, он мне успешно перекодирует (без возврата ошибки) в непечатные символы. Как сделать так, чтобы при передаче некорректного символа ASCII (с установленным старшим битом), устанавливался флаг ошибки, а не SUCCESS? -- 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/528d0311.3010...@yandex.ru
Re: nut, usbhid-ups, Powercom WOW (solved)
... и через 20 минут нашел решение, тупое до безобразия. Надо было просто дать отработать правилам udev, которые приносит с собой nut-server. Единственное - я так и не знаю, как это сделать без перезагрузки... Artem Chuprina - debian-russian@lists.debian.org @ Wed, 20 Nov 2013 22:30:55 +0400: AC Привет. AC Что-то я туплю, и не могу нагуглить решение. Доку от начала до конца AC еще не читал. AC Итак. AC wheezy, amd64, nut-server 2.6.4-2.3 AC Если написать в /etc/nut/ups.conf AC [powercom] AC driver = usbhid-ups AC port = auto AC и позвать AC /lib/nut/usbhid-ups - -a powercom AC то драйвер пишет AC failed to claim USB device: could not claim interface 0: Operation not permitted AC failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted AC и отваливается. Если добавить перед секцией AC user=root AC то прав ему хватает, но не хватает прав upsd, чтобы связаться с драйвером: AC upsd[3302]: Can't connect to UPS [powercom] (usbhid-ups-powercom): Permission denied AC Если добавить еще AC UPSD_OPTIONS=-u root AC в /etc/nut/nut.conf, то вроде как все поднимается нормально, но, блин, AC не зря же он по умолчанию запускается под юзером nut, а не под рутом. AC Где бы чего подкрутить, чтобы ему рута было не надо? Вряд ли же пакет AC делают так, чтобы он не работал из коробки с большинством упсов... AC Еще, надо сказать, я нагуглил в процессе дополнительную опцию pollonly в AC секцию упса. Надо сказать, что если поставить pollonly, то драйвер AC дебаггинг выводит гораздо более тихий, но вроде, демон работает и без AC нее... AC -- AC To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org AC with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org AC Archive: http://lists.debian.org/8738mr3oyo@wizzle.ran.pp.ru -- 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/87vbzm3nun@wizzle.ran.pp.ru
Re: nut, usbhid-ups, Powercom WOW (solved)
В Wed, 20 Nov 2013 22:54:56 +0400 Artem Chuprina r...@ran.pp.ru пишет: ... и через 20 минут нашел решение, тупое до безобразия. Надо было просто дать отработать правилам udev, которые приносит с собой nut-server. Единственное - я так и не знаю, как это сделать без перезагрузки... $ sudo udevadm control --reload-rules $ sudo udevadm trigger --subsystem-match=usb Хотя проще вместо последней команды отключить и подключить UPS. -- 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/20131121002032.44895b81@dragoncore.local
