<div dir="ltr">Геннадий, Вы говорите про оптимизацию дисковой подсистемы. А я - про то, что чтение из tmpfs (считай, RAM) "застевает" в  произвольные моменты времени по непонятным причинам. Это несколько разные проблемы. В этом случае ни ngx_slowfs_cache, ни SSD, ни двойное проксирование решения не дадут.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">23 ноября 2013 г., 16: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">
<div class="im">On 23.11.2013 11:03, Alex Vorona wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
А вообще я не уверен что при перегруженных HDD проблема имеет решение,<br>
если поступающих запросов больше, чем может обслужить дисковая подсистема.<br>
</blockquote>
<br></div>
есть очень похожая задача - что делать, если трафика больше,<br>
чем Bandwidth сетевой подсистемы. и эта задача успешно решена<br>
практически во всех операционных системах. например, для линукса<br>
- <a href="http://xgu.ru/wiki/QoS_%D0%B2_Linux" target="_blank">http://xgu.ru/wiki/QoS_в_Linux</a><u></u>, Hierarchy Token Bucket и т.п.<br>
<br>
разница только в том, что Bandwidth сетевой подсистемы измеряется<br>
в мегабитах в секунду, а Bandwidth дисковой подсистемы - в IOPS.<br>
например, в новых версиях OpenVZ уже появилась опция --iopslimit iops<br>
также в линуксе есть ionice с 4 класами и 8 приоритетами внутри класса.<br>
<br>
теоретически, - если клиенты не однородны, (например, те, кто платит<br>
деньги за доступ к контенту и те, кто получает доступ к нему бесплатно)<br>
то можно разделить их по классам и назначить разные уровни приоритета.<br>
сейчас же обычно все свалено в одну кучу, и никаких QoS настроек нет.<br>
<br>
поскольку native поддержки для этого в nginx нет и вряд ли когда-либо<br>
появится, то это все придется делать средствами операционной системы.<br>
<br>
хотя обычно тюнинг nginx и операционной системы, чтобы данные с дисков<br>
читались большими блоками по 1 мегабайту - помогает и этого достаточно.<br>
<br>
еще скрытые резервы для повышения производительности могут быть в том,<br>
что дисковое хранилище собрано в виде RAID массива 5/6/10/... - в таком<br>
случае сам RAID массив является узким местом и его лучше разобрать<br>
на "отдельные" диски или RAID-1 массивы из N дисков. в этом случае,<br>
если software raid / hardware raid не кривой - скорость random<br>
чтения с RAID-1 массива из N дисков будет примерно в N раз выше.<br>
<br>
или же - добавить SSD к системе хранения файлов в том или ином виде<br>
(Bcache,Flashcache,Btier,<u></u>EnhanceIO, nginx+ngx_slowfs_cache, etc...)<br>
туда уйдет самый "горячий" контент и вся система выдаст больше IOPS.<br>
<br>
кстати, странно что функциональности модуля ngx_slowfs_cache<br>
нет в основной ветке nginx, - чтобы сделать что-то аналогичное<br>
без ngx_slowfs_cache придется использовать "двойное проксирование".<br>
хотя может быть overhead от этого не большой и это вполне приемлимо.<br>
но настройка получается не тривиальной: <a href="http://habrahabr.ru/post/202290/" target="_blank">http://habrahabr.ru/post/<u></u>202290/</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Best regards,<br>
 Gena</font></span><div class="HOEnZb"><div class="h5"><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>