ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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



 




Copyright © Lexa Software, 1996-2009.