ПРОЕКТЫ 


  АРХИВ 


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 01:11:09PM +0300, Igor Sysoev wrote:
> Возможно, это из-за конфигурации рэйда.
> 
> Тот патч применялся для зеркала из 4 дисков, в этом случае 1М читался
> только с одного из четырёх дисков и, таким образом, три других диска
> были доступны для других запросов. Памяти было 4G, и большинство запросов
> обслуживались из этих закэшированных мегабайтных кусков.
> 
> Если же в рэйде этот 1М размазан по нескольким дискам, то все диски
> участвуют в обработке одного запроса. Это хорошо, когда у нас однопотоковое
> чтение (например, обработка видео), где нужна большая скорость
> последовательного чтения. А когда у нас много клиентов, причём достаточно
> медленных и читающих из разным мест, то лучше читать крупными кусками
> только с одного диска и пытаться как-то оставить эти куски в памяти
> на некоторое время.

Не уловил корреляции. Поясни, пожалуйста, свою мысль.
ОС видит один физический диск. На самом контроллере 224MB памяти, доступной для
кеширования, имеется поддержка disconnect и tagging queueing.  Проблема не в
том, что грузится контроллер и тормозит, этого как раз нет, проблема в
черезвычайно низкой эффективности патченного sendfile(2). 

При kern.ipc.sfreadahead=1 всё нормализуется. При увеличение размера блока
(например 1M), которым оперирует sendfile, отдача ухудшается на порядок. Речь
уже не идёт о конкурентных закачках, симптомы проявляются на
одной-единственной.  
При выключенном sendfile - 100MB/s, с непатченным sendfile - 51MB/s, c
патченным - 3-4MB/s. 



 




Copyright © Lexa Software, 1996-2009.