ПРОЕКТЫ 


  АРХИВ 


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



а так "дымит" только нгинх? или фтп, тфтп, сфтп, dd в конце-концов?

On 03.02.2009, at 9:26, Igor Sysoev wrote:

On Mon, Feb 02, 2009 at 11:47:46PM +0300, Artemiev Igor wrote:

On Mon, Feb 02, 2009 at 10:11:21PM +0300, Igor Sysoev wrote:
Судя по этому, nginx уходит в sendfile() с закэшированным контентом один раз.
Что он там делает - непонятно.
угу

А если на этой машине сделать пару загрузок с большим kern.ipc.sfreadahead, а потому поставить его в 1, то скорость подымается до 50MB/s ? По идее,
должна остаться такой же - на уровне нескольких MB/s.
И, насколько я понимаю, на непатченном ядре должно повториться то же самое:
быстрая первая закачка и медленный последующие.

Нет, установка kern.ipc.sfreadahead=1 восстанавливает скорость до 51MB/s, как это и было в случае с непатченным sendfile (я уже приводил порядок скоростей)

То есть,

1) загрузились,
2) поставили kern.ipc.sfreadahead=64,
3) сделали несколько закачек, первая из них быстрая, остальные - медленные,
4) поставили kern.ipc.sfreadahead=1,
5) сделали несколько закачек, все из них быстрые.

Так ?
И при этом при повторных закачках всё равно происходит обращение к диску ?

Если это так, то я не понимаю, почему: sfreadahead используется только
во время чтения. Если страница файла уже в памяти (а они все в памяти, о чём
говорит 1039M Inactive), то код проходит мимо sfreadahead и он вообще
не должно влиять на выполнение.


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




 




Copyright © Lexa Software, 1996-2009.