Максим, здравствуйте! Можем ли мы еще что-то сделать для решения этой проблемы?
С уважением, Иван. В письме от 16 февраля 2016 23:04:57 пользователь Maxim Dounin написал: > Hello! > > On Tue, Feb 16, 2016 at 02:00:33PM -0500, iprok wrote: > > Здравствуйте! > > > > На видеостриминговой системе используем два уровня проксей (эджи и > > ориджины). Эджи проксируют клиентов на ориджины, ориджины проксируют эджи > > на сервера-источники видео. Видео отдается в формате HLS: это плейлисты > > (текстовые файлы) и чанки видео (видео-файлы в формате ts). > > > > В локейшенах, проксирующих чанки, на ориджинах и эджах регулярно, хоть и > > относительно не часто (пара десятков за сутки), проскакивают ошибки "zero > > > > size buf in output". Мне кажется причиной является одна из директив: > > proxy_cache_use_stale updating; > > proxy_cache_lock on; > > > > так как до их появления таких ошибок не было. > > > > nginx в основном 1.8.1, но проявиляется так же и на 1.9.11, логи ниже > > делал > > на последней. Используем пакеты для debian8 из репозитория на nginx.org. > > > > Если смотреть access.log, то чанк в помент проявления этой ошибки отдается > > частично, но с кодом 200 (размер в логе меньше реального размера), при > > следующем запросе отдается нормально, и ошибка не проявляется. > > > > Лог кратко (debug.log внизу, здесь и далее в логах вырезана приватная > > информация, так как ошибка вопроизводится только в продакшене): > > > > 2016/02/14 11:09:20 [alert] 30161#30161: *1388932 zero size buf in output > > t:0 r:0 f:0 0000000002387520 0000000002387520-0000000002389356 > > 0000000000000000 0-0 while sending to client, client: HIDDENIPV4, server: > > e6.mysite.com, request: "GET /place1/stream/cam13_low-5743015560.ts > > HTTP/1.1", upstream: > > "https://[HIDDENIPV6]:443/place1/video/cam13_low-5743015560.ts";, host: > > "e6.mysite.com", referrer: "https://mysite.com/"; > > 2016/02/14 11:09:23 [alert] 30160#30160: *1389653 zero size buf in output > > t:0 r:0 f:0 00000000022BBC50 00000000022BBC50-00000000022BF185 > > 0000000000000000 0-0 while sending to client, client: HIDDENIPV4, server: > > e6.mysite.com, request: "GET /place1/stream/cam13_hi-5297110020.ts > > HTTP/1.1", upstream: > > "https://HIDDENIPV4:443/place1/video/cam13_hi-5297110020.ts";, host: > > "e6.mysite.com", referrer: "https://mysite.com/"; > > [...] > > > Сразу выкладываю debug.log (18 мегабайт в распакованном виде): > > https://kinetiksoft.com/thecloud/index.php/s/5ldvsZFiC2NjpXJ > > Я обрезал только 10 секунд, за которые произошли две ошибки из краткого > > лога в начале сообщения. > > Судя по логам, проблема возникает тогда, когда клиент закрывает > соединение до получения ответа целиком. В обоих случаях перед > alert'ом про "zero size buf" в логах видно такое: > > 2016/02/14 11:09:20 [info] 30161#30161: *1388932 epoll_wait() reported that > client prematurely closed connection (32: Broken pipe) while reading > upstream, client: HIDDENIPV4, server: e6.mysite.com, request: "GET > /place1/stream/cam13_low-5743015560.ts HTTP/1.1", upstream: > "https://[HIDDENIPV6]:443/place1/video/cam13_low-5743015560.ts";, host: > "e6.mysite.com", referrer: "https://mysite.com/"; 2016/02/14 11:09:23 [info] > 30160#30160: *1389653 epoll_wait() reported that client prematurely closed > connection while reading upstream, client: HIDDENIPV4, server: > e6.mysite.com, request: "GET /place1/stream/cam13_hi-5297110020.ts > HTTP/1.1", upstream: > "https://HIDDENIPV4:443/place1/video/cam13_hi-5297110020.ts";, host: > "e6.mysite.com", referrer: "https://mysite.com/"; > > В этом случае nginx продолжает загружать файл с бекенда в кеш, а > после окончания загрузки - пытается отправить последний буфер. И, > видимо, где-то вместе с этим буфером проталкивает в цепочке > фильтров что-то, что ранее счёл свободным (из-за ошибки записи > клиенту), но по факту оно застряло где-то в цепочке фильтров. > > Что именно там происходит и как это поправить - надо смотреть > подробнее. Для начала было бы неплохо убедиться, что сторонних > модулей не используется, а если используются - то проверить, > воспроизводится ли проблема без них. Кроме того, хотелось бы > увидеть вывод "nginx -V". > > (Отмечу также, что в целом ошибка выглядит безвредно - собственно, > логгируемая ошибка и есть основной его эффект. В остальном всё > работает штатно.)
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
