Нужный эффект неблокируемости достигнут, но наблюдаю родившийся
негативный. Однопотоковая закачка идёт в скорость диска - >50Мбайт/сек.
Закачка в 2 и больше потоков через 1 воркер с диска приводит к падению
суммарной скорости отдачи местами и меньше 10Мбайт/сек. Запустив 2
воркера и 2 закачки, убедившись через lsof -p каждого воркера, что идёт
по 1 закачке на воркер - получил желаемую суммарную скорость отдачи
>50Мбайт.
Пересобрал nginx с ngx_linux_sendfile_limit = 512 * 1024;
28Мбайт/сек в 2 потока с 1 воркера, утилизация диска 100%
~60 Мбайт 2 потока с 2-х воркеров, утилизация диска 100%
~65Мб 1 поток, утилизация диска 100%
lighttpd рядом с aio-sendfile показывает до 40мбайт на 2-х закачках с
диска, но скорость падает до ещё меньшего значения чем у nginx -
6-7Мбайт/сек суммарно, утилизация диска 15% :). При убивании одной из
закачек вторая оживает до 50Мбайт в сек, при возобновлении 2-й закачки
о5 всё возвращается на 7Мбайт суммарно.
i386 ядро с патчем на sendfile(не в 128000,а в текущий размер буфера
сокета), nginx 0.5.19 + патч 0.5.18.3, отдача 5G файла
Один поток - ~47Мбайт, утилизация диска 60-80% по iostat
2 потока 1 воркер - суммарная 20-25Мбайт, утилизация диска 90% по iostat
lighttpd sendfile
Один поток - ~50Мбайт, утилизация диска 99-100% по iostat
2 потока суммарная 30-40Мбайт, утилизация диска 99-100% по iostat
Можно в nginx сделать размер равным текущему размеру буфера сокета,
вроде того, как я присылал патч и спрашивал почему он не работает :) ?
Мне кажется, это положительно скажется на производительности. Хотя
лишний системный вызов перед каждым sendfile ...
Пытаюсь разшевелить lkml'щиков http://lkml.org/lkml/2007/4/23/289, но
особо много не добился. Проскочила разве что идея про новый системный
вызов splice(2.6.17+)