ПРОЕКТЫ 


  АРХИВ 


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: read_ahead



On Tue, Sep 29, 2009 at 03:38:24PM +0400, Михаил Монашёв wrote:

> Здравствуйте, Игорь.
> 
> >> Игорь, а поясни пожалуйста что даёт aio sendfile? Ниже ты описал
> >> алгоритм работы, а зачем он нужен не понятно.
> 
> IS> Он нужен, когда весь контент не помещается в память. aio sendfile
> IS> позволяет воркеру не блокироваться на диске при использовани sendfile.
> IS> Вместо этого воркер может принять другое соединение и, если данные
> IS> для него уже закэшированны в VM, то отдать их из кэша.
> 
> А в каких случаях лучше делать aio on, а в каких aio sendfile? Я вот
> сейчас дополз до того, чтобы попробовать aio на рабочей машине и если
> всё получится, оставлю его вместо 1000 воркеров.

aio sendfile включает в себя aio on. То есть, если содержимое файла
нужно прочитать для SSI/gzip/charset/etc, то aio sendfile разрешает
чтение файла с помощью aio, даже если файл не будет отдавать sendfile'ом.

На мой взгляд, aio sendfile + read_ahead имеет смысл использовать всегда -
это самая лучшая комбинация. Без read_ahead aio sendfile неэффективен
для файлов больше 128K.

> IS> В идеале, если файлов не много, но они большие, то вся информация о
> IS> vnode'ах уже будет в памяти, и воркеры не будут блокироваться на
> IS> открытии файлов. Если же файлов много, то воркеры будут блокироваться
> IS> на открытии.
> 
> У  меня  как раз файлов очень много, но вроде бы большинство влезает в
> память:
> 
> kern.maxvnodes: 2000000
> vfs.numvnodes:  1167098
> 
> Видимо сейчас блокировки возникают из-за открытия редких файлов,
> которые почему-то не попали в кэш vnode-ов...

Возможно.

> Эх, жаль никак не получается ограничиться одним воркером... :-)

Есть идея, всё блокирующееся делать отдельным трэдом, но это не скоро.

> Кстати, нормально ли делать vfs.aio.max_aio_procs: 256 ? Или ядро
> может не потянуть столько ядерных тредов?

Нет, с нитями, я думаю, проблем не будет, но, мне кажется, 32 достаточно.

> Мог  бы  ты  описать  вкратце, как работает AIO во FreeBSD. Там каждый
> ядерный  тред  имеет  свою  очередь  файлов  на чтение и по очереди их
> читает? По sysctl -d vfs.aio можно лишь догадываться о том как там всё
> работает...

Насколько я понимаю, все процессы берут запросы из одной общей очереди,
размер которой vfs.aio.max_aio_queue. Текущее число необработанных
запросов в vfs.aio.num_queue_count.


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



 




Copyright © Lexa Software, 1996-2009.