sendfile(2) patch и отдача больших файлов на 7-STABLE amd64

[Artemiev Igor]

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.