<div dir="ltr">В общем, рискнул на стектрейс и странную вещь обнаружил:<div><br></div><div><div><br></div>
<p class="">28986 open("/cache/d/3a/85c878925f816fdeee7127df6aa363ad", O_RDONLY|O_NONBLOCK) = 21 <0.000022><br>28986 fstat(21, {st_mode=S_IFREG|0600, st_size=2175620, ...}) = 0 <0.000011><br></p><div>
....</div><div><br></div><div>28986 setsockopt(17, SOL_TCP, TCP_CORK, [1], 4) = 0 <0.000011></div><div>28986 writev(17, [{"HTTP/1.1 200 OK\r\nServer: nginx\r\n"..., 155}], 1) = 155 <0.000014></div><div>
<b>28986 sendfile(17, 21, [272], 2175348 <unfinished ...></b></div><div><b>28986 <... sendfile resumed> ) = 2175348 <8.692121></b></div><div>28986 --- SIGALRM (Alarm clock) @ 0 (0) ---</div><div>
28986 rt_sigreturn(0xe) = 2175348 <0.000015></div><div>28986 shutdown(17, 1 /* send */) = 0 <0.000031></div><div>28986 recvfrom(17, "", 4096, 0, NULL, NULL) = 0 <0.000019></div>
<div>28986 getsockname(17, {sa_family=AF_INET, sin_port=htons(8802), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 <0.000010></div><div>28986 write(5, "127.0.0.1 [-] [89190498993976151"..., 240) = 240 <0.000035></div>
<div>28986 close(21) = 0 <0.000012></div></div><div><br></div><div><br></div><div>До этого момента я убеждённо считал, что если файл открыт как O_NONBLOCK, то sendfile будет неблокирующим и при недостатке данных вернёт EAGAIN.</div>
<div>Я ошибаюсь? или откуда может появиться время его выполнения в почти 8.7 секунды???....</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">23 ноября 2013 г., 18:07 пользователь Gena Makhomed <span dir="ltr"><<a href="mailto:gmm@csdoc.com" target="_blank">gmm@csdoc.com</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23.11.2013 14:32, Gelun, Artem wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
... чтение из tmpfs (считай, RAM) "застевает" в произвольные моменты<br>
времени по непонятным причинам.<br>
</blockquote>
<br>
причины могут быть разные. например, 1 - машина уходит в swap,<br>
и на самом деле тогда "чтение из tmpfs" будет чтением с диска.<br>
2 - если из tmpfs файлы считывает тот же nginx, который отдает<br>
и файлы с диска. на дисковых операциях worker`ы nginx блокируюся,<br>
поэтому и чтение из tmpfs тоже происходит с задержками и медленно.<br>
3 - используется nginx с "левыми" модулями, которые и дают такие глюки.<br>
4 - используется древняя версия nginx из EPEL, а не Pre-Built Packages для CentOS/RHEL из официального сайта <a href="http://nginx.org/en/download.html" target="_blank">http://nginx.org/en/download.<u></u>html</a><br>
подробнее - см. пост <a href="http://habrahabr.ru/post/195742/#comment_6797402" target="_blank">http://habrahabr.ru/post/<u></u>195742/#comment_6797402</a><br>
5 - и т.д. и т.п.<div class="im"><br>
<br>
On 23.11.2013 13:11, Gelun, Artem wrote:<br>
<br>
>> Для HDD nginx и ОС нужно настраивать так чтобы nginx читал с диска<br>
>> как можно бОльшими в пределах разумного кусками, 512к-2048к например.<br>
<br></div>
в некоторых случаях nginx сможет отдавать файлы быстрее, если выключить<br>
sendfile и правильно настроить output_buffers (есть в архиве рассылки)<br>
<br>
еще для отдачи больших файлов может помочь включение режима aio,<br>
вот первая статья на эту тему: <a href="http://habrahabr.ru/post/68480/" target="_blank">http://habrahabr.ru/post/<u></u>68480/</a><br>
<br>
чтобы уменьшить количество операций ввода/вывода - имеет смысл<br>
для access_log включить buffer, например, размером в 1 мегабайт,<br>
или вообще отключить access_log - "access_log off;".<br>
<br>
все диски и разделы имеет смысл монтировать с опцией noatime.<br>
в некоторых случаях может помочь использование XFS вместо ext4.<div class="im"><br>
<br>
> Насколько я понимаю, sendfile (который включен и должен отрабатывать)<br>
> не блокирует worker'а.<br>
<br></div>
блокирует. чтобы worker не блокировался - надо включать aio,<br>
<a href="http://nginx.org/en/docs/http/ngx_http_core_module.html#aio" target="_blank">http://nginx.org/en/docs/http/<u></u>ngx_http_core_module.html#aio</a><div class="im"><br>
<br>
> Единственное подозрение - воркеры блокируются при<br>
> открытии файла с "перегруженного" HDD. Но:<br>
> 1) как это проверить?<br>
<br></div>
с помощью <a href="http://nginx.org/ru/docs/debugging_log.html" target="_blank">http://nginx.org/ru/docs/<u></u>debugging_log.html</a><br>
указав debug_connection только для своего IP-адреса.<div class="im"><br>
<br>
> 3) Если я правильно понимаю, при размере файла < размера буфера сокета и<br>
> если sendfile_max_chunk не установлен, то sendfile должен вызываться<br>
> один раз. Соответсвенно, если затык в nginx, то он будет перед началом<br>
> отдачи данных.<br>
<br></div>
о том, что происходит когда включен sendfile и не установлен<br>
параметр sendfile_max_chunk - написано в документации к nginx.<br>
<br>
если выставить очень большой буфер сокета, - при 700-1000 rps<br>
не знаю как поведет себя операционная система в такой ситуации.<br>
<br>
особенно, когда кто-то захочет устроить Slowloris атаку против<br>
сервера. или она сама собой будет, если много медленных клиентов.<br>
<br>
уязвимость к Slowloris может быть и в том случае, если поставить<br>
"output_buffers 1 512k;", потому что никакой искуственный интеллект<br>
в nginx пока что не встроен и он не сможет распознать эту атаку<br>
и автоматически сбросить размер буферов для медленных клиентов.<br>
например, "output_buffers auto;" или "output_buffers adaptive;"<br>
<br>
но если не поставить "output_buffers 1 512k;" - тогда будет много<br>
iops для чтения файла с диска мелкими фрагментами и сервер тоже<br>
будет не доступен клиентам, как и в случае DDoS-атаки Slowloris.<br>
<br>
вот советы по тюнингу nginx в аналогичной ситуации:<br>
<a href="http://mailman.nginx.org/pipermail/nginx/2012-May/033761.html" target="_blank">http://mailman.nginx.org/<u></u>pipermail/nginx/2012-May/<u></u>033761.html</a><br>
<br>
эти вопросы про оптимальную настройку nginx для отдачи файлов<br>
уже давно FAQ, но на странице <a href="http://nginx.org/en/docs/faq.html" target="_blank">http://nginx.org/en/docs/faq.<u></u>html</a><br>
рекомендаций по настройке nginx для отдачи статики почему-то нет.<br>
<br>
P.S.<br>
<br>
кстати, стили на странице <a href="http://nginx.org/en/docs/faq.html" target="_blank">http://nginx.org/en/docs/faq.<u></u>html</a><br>
используются ужасные, все элементы списка сливаются между собой,<br>
если между list items сделать больше интервал - читабельность вырастет.<br>
да и подчеркивания в тексте имееют смысл только тогда, когда это редкие<br>
слова или фразы являются гиперссылками. если весь текст подчеркнут -<br>
читать его очень трудно и неудобно. на сайте <a href="http://nginx.org/" target="_blank">http://nginx.org/</a> не нашел<br>
информации куда писать с предложениями по улучшению доки, поэтому пишу<br>
в список рассылки - вдруг кто-то увидит и исправит эти глюки/проблемы?<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Best regards,<br>
Gena<br>
<br>
______________________________<u></u>_________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/<u></u>mailman/listinfo/nginx-ru</a></div></div></blockquote></div><br></div>