ПРОЕКТЫ 


  АРХИВ 


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: sendfile(2) patch и отда ча больших файлов на 7-STABLE amd64



On Mon, Feb 02, 2009 at 04:03:48PM +0300, Artemiev Igor wrote:

> On Mon, Feb 02, 2009 at 02:25:34PM +0300, Igor Sysoev wrote:
> > > > kern.ipc.sfrefer не использовался ?
> > > 
> > > Использовался, но эффекта не замечено. То есть при параллельной закачке с
> > > разных хостов тестового гигового файла ощутимого уменьшения дисковой 
> > > нагрузки
> > > нет (стартовались не одновременно, от 3х до 5 клиентов)
> > 
> > Его как раз использовать не нужно. Там возможен как раз описанный эффект,
> > когда с диска читается на максимуме, а в сеть отдаются совсем мало.
> 
> Чтобы не быть голословным:
> 
> kern.ipc.sfreadahead=16
> kern.ipc.sfrefer=0
> В конфиге ядра:
> options           MAXPHYS=(1024*1024)
> 
> Сразу после загрузки:
> $fetch -o /dev/null http://10.0.0.1/1g
> /dev/null                                     100% of 1024 MB   58 MBps 00m00s
> 
> Повторный прогон:
> $fetch -o /dev/null http://10.0.0.1/1g
> /dev/null                                      45% of 1024 MB 4591 kBps 
> 02m04s^C
> fetch: transfer interrupted
> 
> Последующие запуски результат не меняют:
> $fetch -o /dev/null http://10.0.0.1/1g
> /dev/null                                       4% of 1024 MB 4516 kBps^C
> fetch: transfer interrupted

Правильно ли понимаю, что при повторных загрузках к диску обращения уже
не происходит ?


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



 




Copyright © Lexa Software, 1996-2009.