Re: start time is out mp4 stsc chunks
Hello! On Thu, Mar 27, 2014 at 08:18:55PM +0200, Андрей Василишин wrote: > > >>Чтобы заработало - нужно либо убрать дорожки из файла, либо > >>обновится до nginx 1.5.10+: > >> > > Спасибо за ответы, Максим! > Но есть еще вопросы: > Обновился до > # nginx -V > nginx version: nginx/1.5.12 > built by gcc 4.7.2 (Debian 4.7.2-5) [...] > Теперь 500-ой общибки при перемотке нет, но при перемотке просто идет > скачиваение файла и при этом не показывается в плеере ничего, кроме полосы > загрузки. > > Про какие дорожки речь? > # mediainfo file_720.mp4 > General > Complete name: file_720.mp4 > Format : MPEG-4 > Format profile : Base Media > Codec ID : isom > File size: 995 MiB > Duration : 1h 54mn > Overall bit rate mode: Variable > Overall bit rate : 1 211 Kbps > Writing application : Lavf55.19.104 [...] > Text > ID : 3 > Format : Apple text > Codec ID : text > Duration : 1h 54mn > Bit rate mode: Variable > Bit rate : 0 bps > Delay relative to video : -1s 24ms > Stream size : 135 Bytes (0%) > Language : English Видимо, проблема в этой дорожке. Она не выглядит короткой, так что скорее всего ошибка была из-за каких-то нюансов расположения данных. Но при этом она явно не перемешана с остальными дорожками (просто из-за очень малого размера), и попытка отдать диапазон файла "начиная с такой-то секунды", видимо, требует отдачи практически всего файла, т.к. для этой дорожки данные начинаются в начале файла. Наиболее простое решение - убрать из файла эту дорожку. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
"Замирает" передача статичного файла
Проблема заключается в периодическом "замирании" передачи статичного
файла, возникает в основном на высокоскоростных соединениях.
С включенным limit_rate 200k я ни разу не поймал проблему.
Включил debug_connection для одного тестового клиента, далее
отфильтрованные записи из лога (могу полный лог отправить если надо):
2014/03/28 16:09:44 [debug] 22512#0: *102725 HTTP/1.1 200 OK
Server: nginx/1.4.7
Date: Fri, 28 Mar 2014 12:09:44 GMT
Content-Type: application/octet-stream
Content-Length: 17775749
Connection: keep-alive
ETag: "532070bd-10f3c85"
Last-Modified: Fri, 2 Jan 1970 00:00:01 GMT
Accept-Ranges: bytes
2014/03/28 16:09:44 [debug] 22512#0: *102725 write new buf t:1 f:0
072252E8, pos 072252E8, size: 260 file: 0, size: 0
...
2014/03/28 16:09:44 [debug] 22512#0: *102725 write old buf t:1 f:0
072252E8, pos 072252E8, size: 260 file: 0, size: 0
2014/03/28 16:09:44 [debug] 22512#0: *102725 write new buf t:0 f:1
, pos , size: 0 file: 0, size:
17775749
...
2014/03/28 16:09:44 [debug] 22512#0: *102725 writev: 260
2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: @0 17775749
2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: 3440640, @0
3440640:17775749
...
2014/03/28 16:09:44 [debug] 22512#0: *102725 write old buf t:0 f:1
, pos , size: 0 file: 3440640, size:
14335109
2014/03/28 16:09:44 [debug] 22512#0: *102725 http write filter: l:1
f:0 s:14335109
2014/03/28 16:09:44 [debug] 22512#0: *102725 http write filter limit 0
2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: @3440640 14335109
2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile() is not ready
(11: Resource temporarily unavailable)
2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: -1, @3440640 0:14335109
2014/03/28 16:09:44 [debug] 22512#0: *102725 http write filter 07225478
2014/03/28 16:09:44 [debug] 22512#0: *102725 http copy filter: -2 "/test.bin?"
2014/03/28 16:09:44 [debug] 22512#0: *102725 http writer output
filter: -2, "/test.bin?"
2014/03/28 16:09:44 [debug] 22512#0: *102725 event timer: 154, old:
1396008594706, new: 1396008594706
...
2014/03/28 16:09:54 [debug] 22512#0: *102725 event timer del: 154: 1396008594706
2014/03/28 16:09:54 [debug] 22512#0: *102725 http run request: "/test.bin?"
2014/03/28 16:09:54 [debug] 22512#0: *102725 http writer handler: "/test.bin?"
2014/03/28 16:09:54 [info] 22512#0: *102725 client timed out (110:
Connection timed out) while sending response to client, ...
В общем как мне кажется проблема где-то около "sendfile() is not ready
(11: Resource temporarily unavailable)"
Похожая ситуация возникает с sendfile off, но уже "writev() not ready
(11: Resource temporarily unavailable)"
Сервер используется для раздачи видео с модулями mp4/flv, GeoIP вместе
с if/set, lua подсчитывает попадания по каждому урлу в именованный
location @proxy с помощью lua_shared_dict, но по факту и без
выполнения lua возникают проблемы.
Перекомпилировал nginx с необходимыми модулями:
# nginx -V
nginx version: nginx/1.4.7
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-54)
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log
--pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx
--group=nginx --add-module=../../SOURCES/ngx_devel_kit
--add-module=../../SOURCES/lua-nginx-module --with-select_module
--with-poll_module --with-rtsig_module --with-http_flv_module
--with-http_mp4_module --with-http_geoip_module
--with-http_stub_status_module --with-http_secure_link_module
--with-file-aio --with-cc-opt='-O2 -g -m64 -mtune=generic'
kernel 2.6.18-371.6.1.el5 (CentOS 5.10)
На время тестирования пробовал включать все опции по умолчанию,
тестовый файл отдельно от остального контента:
send_timeout 10s;
location = /test.bin {
root /cache/data3;
sendfile on;
}
В чем может быть проблема, в какую сторону копать?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: "Замирает" передача статичного файла
On Friday 28 March 2014 18:47:27 Алексей Щуров wrote: > Проблема заключается в периодическом "замирании" передачи статичного > файла, возникает в основном на высокоскоростных соединениях. > С включенным limit_rate 200k я ни разу не поймал проблему. > Включил debug_connection для одного тестового клиента, далее > отфильтрованные записи из лога (могу полный лог отправить если надо): > 2014/03/28 16:09:44 [debug] 22512#0: *102725 HTTP/1.1 200 OK > Server: nginx/1.4.7 > Date: Fri, 28 Mar 2014 12:09:44 GMT > Content-Type: application/octet-stream > Content-Length: 17775749 > Connection: keep-alive > ETag: "532070bd-10f3c85" > Last-Modified: Fri, 2 Jan 1970 00:00:01 GMT > Accept-Ranges: bytes > > 2014/03/28 16:09:44 [debug] 22512#0: *102725 write new buf t:1 f:0 > 072252E8, pos 072252E8, size: 260 file: 0, size: 0 > ... > 2014/03/28 16:09:44 [debug] 22512#0: *102725 write old buf t:1 f:0 > 072252E8, pos 072252E8, size: 260 file: 0, size: 0 > 2014/03/28 16:09:44 [debug] 22512#0: *102725 write new buf t:0 f:1 > , pos , size: 0 file: 0, size: > 17775749 > ... > 2014/03/28 16:09:44 [debug] 22512#0: *102725 writev: 260 > 2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: @0 17775749 > 2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: 3440640, @0 > 3440640:17775749 > ... > 2014/03/28 16:09:44 [debug] 22512#0: *102725 write old buf t:0 f:1 > , pos , size: 0 file: 3440640, size: > 14335109 > 2014/03/28 16:09:44 [debug] 22512#0: *102725 http write filter: l:1 > f:0 s:14335109 > 2014/03/28 16:09:44 [debug] 22512#0: *102725 http write filter limit 0 > 2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: @3440640 14335109 > 2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile() is not ready > (11: Resource temporarily unavailable) > 2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: -1, @3440640 0:14335109 > 2014/03/28 16:09:44 [debug] 22512#0: *102725 http write filter > 07225478 > 2014/03/28 16:09:44 [debug] 22512#0: *102725 http copy filter: -2 "/test.bin?" > 2014/03/28 16:09:44 [debug] 22512#0: *102725 http writer output > filter: -2, "/test.bin?" > 2014/03/28 16:09:44 [debug] 22512#0: *102725 event timer: 154, old: > 1396008594706, new: 1396008594706 > ... > 2014/03/28 16:09:54 [debug] 22512#0: *102725 event timer del: 154: > 1396008594706 > 2014/03/28 16:09:54 [debug] 22512#0: *102725 http run request: "/test.bin?" > 2014/03/28 16:09:54 [debug] 22512#0: *102725 http writer handler: "/test.bin?" > 2014/03/28 16:09:54 [info] 22512#0: *102725 client timed out (110: > Connection timed out) while sending response to client, ... Из лога видно, что клиент отвалился по таймауту, тех 10 секунд что вы поставили в send_timeout явно не достаточно, вероятно клиент не успевает потреблять с такой скоростью. Значение по умолчанию там 60 секунд, зачем трогали? > > В общем как мне кажется проблема где-то около "sendfile() is not ready > (11: Resource temporarily unavailable)" > Похожая ситуация возникает с sendfile off, но уже "writev() not ready > (11: Resource temporarily unavailable)" [..] Эти сообщения - часть нормальной работы: сокетный буфер заполнился, писать больше некуда. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: start time is out mp4 stsc chunks
Text ID : 3 Format : Apple text Codec ID : text Duration : 1h 54mn Bit rate mode: Variable Bit rate : 0 bps Delay relative to video : -1s 24ms Stream size : 135 Bytes (0%) Language : English Видимо, проблема в этой дорожке. Она не выглядит короткой, так что скорее всего ошибка была из-за каких-то нюансов расположения данных. Но при этом она явно не перемешана с остальными дорожками (просто из-за очень малого размера), и попытка отдать диапазон файла "начиная с такой-то секунды", видимо, требует отдачи практически всего файла, т.к. для этой дорожки данные начинаются в начале файла. Наиболее простое решение - убрать из файла эту дорожку. А как же обновление до nginx 1.5.10+, это непомогает? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: "Замирает" передача статичного файла
On Friday 28 March 2014 20:54:50 Алексей Щуров wrote: > С таймаутом 60 секунд всё тоже самое, только клиент дольше ожидает данные. > У тестового клиента очень высокая скорость и со стороны клиента это > выглядит как быстро передавшиеся первые 1-4 Мбайта, потом полное молчание > со стороны сервера и по таймауту от nginx приходит RST пакет. > > Как я понял когда буфер заканчивается sendfile возвращает nginx что он не > полностью отдал файл: > 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: @0 17775749 > 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: 1302528, @0 > 1302528:17775749 Мы не знаем причину по которой sendfile() отдал файл не полностью, поэтому зовем sendfile() ещё раз. > > а потом nginx по событию готовности клиента вызывает sendfile с последней > позиции: > 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: @1302528 16473221 Это не по событию, это просто следующий вызов sendfile() на очередной итерации цикла. В этом нет ничего необычного. > > но у меня почему то стабильно останавливается передача после этой строки: > 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile() is not ready (11: > Resource temporarily unavailable) > 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: -1, @1302528 0:16473221 > > Это был уже другой пример неудачной передачи и уже на nginx 1.5.12 с таким > же spec файлом. Значит о событии готовности nginx-у больше не сообщают. Либо клиент просто больше не читает из-за ошибки в самом клиенте или из-за проблем с сетью, либо ядро не сообщает (2.6.18 - тухлый антиквариат, там может быть что угодно), или же где-то ошибка в nginx. Стоит посмотреть тем же tcpdump-ом что происходит при этом на соединении. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-ru Digest, Vol 53, Issue 40
Hello! On Fri, Mar 28, 2014 at 08:54:50PM +0400, Алексей Щуров wrote: (В скобках замечу, что отвечать на digest - это плохая идея, т.к. в результате не строятся цепочки сообщений и нет возможности нормально посмотреть историю.) > С таймаутом 60 секунд всё тоже самое, только клиент дольше ожидает данные. > У тестового клиента очень высокая скорость и со стороны клиента это > выглядит как быстро передавшиеся первые 1-4 Мбайта, потом полное молчание > со стороны сервера и по таймауту от nginx приходит RST пакет. > > Как я понял когда буфер заканчивается sendfile возвращает nginx что он не > полностью отдал файл: > 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: @0 17775749 > 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: 1302528, @0 > 1302528:17775749 > > а потом nginx по событию готовности клиента вызывает sendfile с последней > позиции: > 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: @1302528 16473221 > > но у меня почему то стабильно останавливается передача после этой строки: > 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile() is not ready (11: > Resource temporarily unavailable) > 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: -1, @1302528 0:16473221 По получению EAGAIN из sendfile'а nginx должен сказать ядру (если не сделал этого ранее), что ему следует уведомить nginx о возможности записи в указанный сокет. А ядро, соответственно - уведомить nginx, когда такая возможность появится. Если этого не происходит, то возможно одно из двух: 1) В nginx'е где-то ошибка, и соответствующий event не устанавливается. 2) В ядре где-то ошибка, и о соответствующем event'е nginx'у не сообщают. Чтобы понять, что именно происходит, нужно как минимум видеть полный конфиг и полный debug log, а равно вывод "nginx -V" и информацию о системе. Ну и я оставлю эту ссылку здесь: http://wiki.nginx.org/Debugging -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: start time is out mp4 stsc chunks
Hello! On Fri, Mar 28, 2014 at 07:18:37PM +0200, Андрей Василишин wrote: > > >>Text > >>ID : 3 > >>Format : Apple text > >>Codec ID : text > >>Duration : 1h 54mn > >>Bit rate mode: Variable > >>Bit rate : 0 bps > >>Delay relative to video : -1s 24ms > >>Stream size : 135 Bytes (0%) > >>Language : English > > > >Видимо, проблема в этой дорожке. Она не выглядит короткой, так > >что скорее всего ошибка была из-за каких-то нюансов расположения > >данных. Но при этом она явно не перемешана с остальными дорожками > >(просто из-за очень малого размера), и попытка отдать диапазон > >файла "начиная с такой-то секунды", видимо, требует отдачи > >практически всего файла, т.к. для этой дорожки данные начинаются в > >начале файла. > > > >Наиболее простое решение - убрать из файла эту дорожку. > > > > А как же обновление до nginx 1.5.10+, это непомогает? Помогает, насколько я понял, ошибок же больше нет? Последняя рекомендация касается того факта, что при "перемотке просто идёт скачивание файла". Насколько я понимаю структуру файла, любой или почти любой запрос медиаданных по времени - будет включать практически весь файл целиком, и псевдостриминг теряет смысл. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: start time is out mp4 stsc chunks
28.03.2014 20:24, Maxim Dounin пишет: Hello! On Fri, Mar 28, 2014 at 07:18:37PM +0200, Андрей Василишин wrote: Text ID : 3 Format : Apple text Codec ID : text Duration : 1h 54mn Bit rate mode: Variable Bit rate : 0 bps Delay relative to video : -1s 24ms Stream size : 135 Bytes (0%) Language : English Видимо, проблема в этой дорожке. Она не выглядит короткой, так что скорее всего ошибка была из-за каких-то нюансов расположения данных. Но при этом она явно не перемешана с остальными дорожками (просто из-за очень малого размера), и попытка отдать диапазон файла "начиная с такой-то секунды", видимо, требует отдачи практически всего файла, т.к. для этой дорожки данные начинаются в начале файла. Наиболее простое решение - убрать из файла эту дорожку. А как же обновление до nginx 1.5.10+, это непомогает? Помогает, насколько я понял, ошибок же больше нет? Последняя рекомендация касается того факта, что при "перемотке просто идёт скачивание файла". Насколько я понимаю структуру файла, любой или почти любой запрос медиаданных по времени - будет включать практически весь файл целиком, и псевдостриминг теряет смысл. Но ведь это дорожка субтитров, получается, до 1.3.5 ее просто отбрасывало, а после 1.5.10 не работает псевдостримминг. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Странное поведение с httpready и dataready
# grep accept_filter nginx.conf listen xx.xx.xx.57 accept_filter=httpready accept_filter=dataready ; listen xx.xx.xx.60 accept_filter=httpready accept_filter=dataready ; listen xx.xx.xx.58 accept_filter=httpready accept_filter=dataready ; listen xx.xx.xx.56 accept_filter=httpready accept_filter=dataready ; В итоге отдельные боты долбят небольшими пакетами овер 5kpps ... 01:34:20.942605 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto TCP (6), length 52) 5.10.83.89.41060 > xx.xx.xx.58.80: Flags [.], cksum 0x871a (correct), seq 2, ack 1, win 115, options [nop,nop,TS val 1334154219 ecr 2410240396], length 0 01:34:20.942613 IP (tos 0x0, ttl 64, id 44144, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->766c)!) xx.xx.xx.58.80 > 5.10.83.89.41060: Flags [.], cksum 0x180e (incorrect -> 0x8d2d), seq 0, ack 1, win 32, length 0 01:34:20.942615 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto TCP (6), length 52) 5.10.83.89.41060 > xx.xx.xx.58.80: Flags [.], cksum 0x871a (correct), seq 2, ack 1, win 115, options [nop,nop,TS val 1334154219 ecr 2410240396], length 0 01:34:20.942622 IP (tos 0x0, ttl 64, id 44145, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->766b)!) xx.xx.xx.58.80 > 5.10.83.89.41060: Flags [.], cksum 0x180e (incorrect -> 0x8d2d), seq 0, ack 1, win 32, length 0 01:34:20.942976 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto TCP (6), length 52) 5.10.83.89.41060 > xx.xx.xx.58.80: Flags [.], cksum 0x871a (correct), seq 2, ack 1, win 115, options [nop,nop,TS val 1334154219 ecr 2410240396], length 0 01:34:20.942986 IP (tos 0x0, ttl 64, id 44146, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->766a)!) xx.xx.xx.58.80 > 5.10.83.89.41060: Flags [.], cksum 0x180e (incorrect -> 0x8d2d), seq 0, ack 1, win 32, length 0 01:34:20.942988 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto TCP (6), length 52) 5.10.83.89.41060 > xx.xx.xx.58.80: Flags [.], cksum 0x871a (correct), seq 2, ack 1, win 115, options [nop,nop,TS val 1334154219 ecr 2410240396], length 0 01:34:20.942996 IP (tos 0x0, ttl 64, id 44147, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->7669)!) xx.xx.xx.58.80 > 5.10.83.89.41060: Flags [.], cksum 0x180e (incorrect -> 0x8d2d), seq 0, ack 1, win 32, length 0 ... # nginx -V nginx version: nginx/1.4.7 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-file-aio --with-ipv6 --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_flv_module --with-http_stub_status_module --with-http_sub_module --with-pcre --with-http_ssl_module # uname -a FreeBSD vm-10-1.domain.com 10.0-STABLE FreeBSD 10.0-STABLE #0: Tue Mar 18 23:06:27 EET 2014 r...@vm-10-1.domain.com:/usr/obj/usr/src/sys/vm-10.3 amd64 # kldstat -v | grep accf_ 285 accf_http 284 accf_dns 283 accf_data -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Странное поведение с httpready и dataready
Здравствуйте, Vladislav. > # grep accept_filter nginx.conf > listen xx.xx.xx.57 accept_filter=httpready accept_filter=dataready ; > listen xx.xx.xx.60 accept_filter=httpready accept_filter=dataready ; > listen xx.xx.xx.58 accept_filter=httpready accept_filter=dataready ; > listen xx.xx.xx.56 accept_filter=httpready accept_filter=dataready ; Если я не ошибаюсь, то нет смысла использовать dataready, если есть httpready. Они про одно и тоже, только второй ещё проверяет, что пришедшие данные похожи на HTTP. -- С уважением, Михаил mailto:postmas...@softsearch.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
