Проблема при >1500 одновременных коннектов.

[Igor Sysoev]

On Wed, Feb 11, 2009 at 05:34:19PM +0100, ArjLover wrote:

> Так. Какие исходя из этого будут рекомендации? У меня же есть еще куча
> свободной памяти! Как ее пустить на те же цели? Ядро тюнить?

Что показывает

grep 'memory *= ' /var/run/dmesg.boot

?

> А.
> 
> 2009/2/11 Igor Sysoev <is at rambler-co.ru>
> 
> > On Wed, Feb 11, 2009 at 02:08:35PM +0300, Roman Sokolov wrote:
> >
> > > Hello Igor Sysoev,
> > >
> > > on 11.02.2009 13:02, you wrote:
> > > >>> Кхе, что +1? Похоже меня не поняли. Могу и 16 поставить, но зачем
> > когда и 4
> > > >>> НЕ используются.
> > > >>> вот полная строчка из top
> > > >>> Mem: 94M Active, 1471M Inact, 341M Wired, 93M Cache, 199M Buf, 2996K
> > Free
> > > >>>
> > > >>> Вопрос остается актуальным  - как побольше памяти отдать под операции
> > кэша
> > > >>> для nginx? Чтобы в память читалось большими кусками, а из нее
> > отдавалось как
> > > >>> надо клиенту. Кстати этот механизм очень красиво и понятно
> > отображается в
> > > >>> utorrent на закладке скорость на графике диска.
> > > >> Inact - это память, используемая системой под кеш страниц.  И
> > > >> именно туда читаются данные с диска при sendfile() с readahead.
> > > >>
> > > >> BTW, вас кто-то жестоко обманул - это не 4 гига.  Судя по
> > > >> вышеприведённой строчке - системе доступно всего 2.2 гигабайта
> > > >> памяти.
> > > >
> > > > На самом деле, 94+1471+341+93+3 = 2002M, Buf не считается, это просто
> > маппинг.
> > > А в такие объемы вполне себе вписываются проблемы при большом readahead
> > для
> > > sendfile:
> > > берем начальные настройки kern.ipc.sfreadahead=524288 -> 512к данных в
> > кеш на
> > > одно соединение -> 800м памяти только sendfile на 1600 соединений +
> > буфера на
> > > 1600 соединений, что уже недалеко от наблюдаемых сейчас 1.5г кешей. А что
> > > происходит с sendfile когда место в кеше заканчивается?
> >
> > Когда место заканчивается, содержимое некоторых страниц (насколько я
> > понимаю,
> > в порядке FIFO) из Cache и Inact выкидывается, а страницы используются
> > для чтения. Похоже, именно в этом заключается проблема в данном случае.
> > Пока памяти хватает дял хранения read ahead для всех соединений - всё
> > работает. Как только памяти перестаёт хватать, sendfile чаще читает диск,
> > потому что, то, что он прочитал раньше как ahead, с некоторой вероятностью
> > выкинуто. Таким образом, теперь приходится читать как для новых
> > sendfile'ов,
> > так и для тех старых, которые раньше ходили на диск реже, так как
> > обслуживались из read ahead. Это объясняет резкое увеличение загрузки
> > диска.
> >
> > Как на это влияет sendfile_max_chunk, пока не могу понять.
> >
> >
> > --
> > Игорь Сысоев
> > http://sysoev.ru
> >
> >
> 
> 
> -- 
> Best regards,
> Anton Kuznetsov.

-- 
Игорь Сысоев
http://sysoev.ru