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
