Lexa Software: Nginx-ru@sysoev.ru archive

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

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@xxxxxxxxx> написал:

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@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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