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

[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