Re: Затыки при отдаче статики

Sat Nov 23 14:54:38 UTC 2013

В общем, рискнул на стектрейс и странную вещь обнаружил:

28986 open("/cache/d/3a/85c878925f816fdeee7127df6aa363ad",
O_RDONLY|O_NONBLOCK) = 21 <0.000022>
28986 fstat(21, {st_mode=S_IFREG|0600, st_size=2175620, ...}) = 0 <0.000011>
....

28986 setsockopt(17, SOL_TCP, TCP_CORK, [1], 4) = 0 <0.000011>
28986 writev(17, [{"HTTP/1.1 200 OK\r\nServer: nginx\r\n"..., 155}], 1) =
155 <0.000014>
*28986 sendfile(17, 21, [272], 2175348 <unfinished ...>*
*28986 <... sendfile resumed> )          = 2175348 <8.692121>*
28986 --- SIGALRM (Alarm clock) @ 0 (0) ---
28986 rt_sigreturn(0xe)                 = 2175348 <0.000015>
28986 shutdown(17, 1 /* send */)        = 0 <0.000031>
28986 recvfrom(17, "", 4096, 0, NULL, NULL) = 0 <0.000019>
28986 getsockname(17, {sa_family=AF_INET, sin_port=htons(8802),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 <0.000010>
28986 write(5, "127.0.0.1 [-] [89190498993976151"..., 240) = 240 <0.000035>
28986 close(21)                         = 0 <0.000012>

До этого момента я убеждённо считал, что если файл открыт как O_NONBLOCK,
то sendfile будет неблокирующим и при недостатке данных вернёт EAGAIN.
Я ошибаюсь? или откуда может появиться время его выполнения в почти 8.7
секунды???....

23 ноября 2013 г., 18:07 пользователь Gena Makhomed <gmm at csdoc.com> написал:

> On 23.11.2013 14:32, Gelun, Artem wrote:
>
>  ... чтение из tmpfs (считай, RAM) "застевает" в произвольные моменты
>> времени по непонятным причинам.
>>
>
> причины могут быть разные. например, 1 - машина уходит в swap,
> и на самом деле тогда "чтение из tmpfs" будет чтением с диска.
> 2 - если из tmpfs файлы считывает тот же nginx, который отдает
> и файлы с диска. на дисковых операциях worker`ы nginx блокируюся,
> поэтому и чтение из tmpfs тоже происходит с задержками и медленно.
> 3 - используется nginx с "левыми" модулями, которые и дают такие глюки.
> 4 - используется древняя версия nginx из EPEL, а не Pre-Built Packages для
> CentOS/RHEL из официального сайта http://nginx.org/en/download.html
> подробнее - см. пост http://habrahabr.ru/post/195742/#comment_6797402
> 5 - и т.д. и т.п.
>
>
> On 23.11.2013 13:11, Gelun, Artem wrote:
>
> >> Для HDD nginx и ОС нужно настраивать так чтобы nginx читал с диска
> >> как можно бОльшими в пределах разумного кусками, 512к-2048к например.
>
> в некоторых случаях nginx сможет отдавать файлы быстрее, если выключить
> sendfile и правильно настроить output_buffers (есть в архиве рассылки)
>
> еще для отдачи больших файлов может помочь включение режима aio,
> вот первая статья на эту тему: http://habrahabr.ru/post/68480/
>
> чтобы уменьшить количество операций ввода/вывода - имеет смысл
> для access_log включить buffer, например, размером в 1 мегабайт,
> или вообще отключить access_log - "access_log off;".
>
> все диски и разделы имеет смысл монтировать с опцией noatime.
> в некоторых случаях может помочь использование XFS вместо ext4.
>
>
> > Насколько я понимаю, sendfile (который включен и должен отрабатывать)
> > не  блокирует worker'а.
>
> блокирует. чтобы worker не блокировался - надо включать aio,
> http://nginx.org/en/docs/http/ngx_http_core_module.html#aio
>
>
> > Единственное подозрение - воркеры блокируются при
> > открытии файла с "перегруженного" HDD. Но:
> > 1) как это проверить?
>
> с помощью http://nginx.org/ru/docs/debugging_log.html
> указав debug_connection только для своего IP-адреса.
>
>
> > 3) Если я правильно понимаю, при размере файла < размера буфера сокета и
> > если sendfile_max_chunk не установлен, то sendfile должен вызываться
> > один раз. Соответсвенно, если затык в nginx, то он будет перед началом
> > отдачи данных.
>
> о том, что происходит когда включен sendfile и не установлен
> параметр sendfile_max_chunk - написано в документации к nginx.
>
> если выставить очень большой буфер сокета, - при 700-1000 rps
> не знаю как поведет себя операционная система в такой ситуации.
>
> особенно, когда кто-то захочет устроить Slowloris атаку против
> сервера. или она сама собой будет, если много медленных клиентов.
>
> уязвимость к Slowloris может быть и в том случае, если поставить
> "output_buffers 1 512k;", потому что никакой искуственный интеллект
> в nginx пока что не встроен и он не сможет распознать эту атаку
> и автоматически сбросить размер буферов для медленных клиентов.
> например, "output_buffers auto;" или "output_buffers adaptive;"
>
> но если не поставить "output_buffers 1 512k;" - тогда будет много
> iops для чтения файла с диска мелкими фрагментами и сервер тоже
> будет не доступен клиентам, как и в случае DDoS-атаки Slowloris.
>
> вот советы по тюнингу nginx в аналогичной ситуации:
> http://mailman.nginx.org/pipermail/nginx/2012-May/033761.html
>
> эти вопросы про оптимальную настройку nginx для отдачи файлов
> уже давно FAQ, но на странице http://nginx.org/en/docs/faq.html
> рекомендаций по настройке nginx для отдачи статики почему-то нет.
>
> P.S.
>
> кстати, стили на странице http://nginx.org/en/docs/faq.html
> используются ужасные, все элементы списка сливаются между собой,
> если между list items сделать больше интервал - читабельность вырастет.
> да и подчеркивания в тексте имееют смысл только тогда, когда это редкие
> слова или фразы являются гиперссылками. если весь текст подчеркнут -
> читать его очень трудно и неудобно. на сайте http://nginx.org/ не нашел
> информации куда писать с предложениями по улучшению доки, поэтому пишу
> в список рассылки - вдруг кто-то увидит и исправит эти глюки/проблемы?
>
>
> --
> Best regards,
>  Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20131123/f36621b9/attachment.html>