Так. Какие исходя из этого будут рекомендации? У меня же есть еще куча свободной памяти! Как ее пустить на те же цели? Ядро тюнить?<br><br>А.<br><br><div class="gmail_quote">2009/2/11 Igor Sysoev <span dir="ltr"><<a href="mailto:is@rambler-co.ru">is@rambler-co.ru</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="Wj3C7c">On Wed, Feb 11, 2009 at 02:08:35PM +0300, Roman Sokolov wrote:<br>
<br>
> Hello Igor Sysoev,<br>
><br>
> on 11.02.2009 13:02, you wrote:<br>
> >>> Кхе, что +1? Похоже меня не поняли. Могу и 16 поставить, но зачем когда и 4<br>
> >>> НЕ используются.<br>
> >>> вот полная строчка из top<br>
> >>> Mem: 94M Active, 1471M Inact, 341M Wired, 93M Cache, 199M Buf, 2996K Free<br>
> >>><br>
> >>> Вопрос остается актуальным - как побольше памяти отдать под операции кэша<br>
> >>> для nginx? Чтобы в память читалось большими кусками, а из нее отдавалось как<br>
> >>> надо клиенту. Кстати этот механизм очень красиво и понятно отображается в<br>
> >>> utorrent на закладке скорость на графике диска.<br>
> >> Inact - это память, используемая системой под кеш страниц. И<br>
> >> именно туда читаются данные с диска при sendfile() с readahead.<br>
> >><br>
> >> BTW, вас кто-то жестоко обманул - это не 4 гига. Судя по<br>
> >> вышеприведённой строчке - системе доступно всего 2.2 гигабайта<br>
> >> памяти.<br>
> ><br>
> > На самом деле, 94+1471+341+93+3 = 2002M, Buf не считается, это просто маппинг.<br>
> А в такие объемы вполне себе вписываются проблемы при большом readahead для<br>
> sendfile:<br>
> берем начальные настройки kern.ipc.sfreadahead=524288 -> 512к данных в кеш на<br>
> одно соединение -> 800м памяти только sendfile на 1600 соединений + буфера на<br>
> 1600 соединений, что уже недалеко от наблюдаемых сейчас 1.5г кешей. А что<br>
> происходит с sendfile когда место в кеше заканчивается?<br>
<br>
</div></div>Когда место заканчивается, содержимое некоторых страниц (насколько я понимаю,<br>
в порядке FIFO) из Cache и Inact выкидывается, а страницы используются<br>
для чтения. Похоже, именно в этом заключается проблема в данном случае.<br>
Пока памяти хватает дял хранения read ahead для всех соединений - всё<br>
работает. Как только памяти перестаёт хватать, sendfile чаще читает диск,<br>
потому что, то, что он прочитал раньше как ahead, с некоторой вероятностью<br>
выкинуто. Таким образом, теперь приходится читать как для новых sendfile'ов,<br>
так и для тех старых, которые раньше ходили на диск реже, так как<br>
обслуживались из read ahead. Это объясняет резкое увеличение загрузки диска.<br>
<br>
Как на это влияет sendfile_max_chunk, пока не могу понять.<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
--<br>
Игорь Сысоев<br>
<a href="http://sysoev.ru" target="_blank">http://sysoev.ru</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Best regards,<br>Anton Kuznetsov. <br>