worker_rlimit_nofile

[drmarker]

> > 10 сессий от клиентов с каналами по 10 мегабит каждый, которые тянут
> > один файл дадут в сумме 80mb легко, ага. А вот если клиентов 100 и
> > каналы у них по 1 мегабиту, а скачивают они 20 разных больших файлов,
> > то начинают возникать проблемы.
>
> Это на практике такая проблема возникла с 100 подключениями?
> Суть-то верна, но проявляется не на таких цифрах.

Нет, конечно. 100 подключений по 1mb - это условия, близкие к идеалу.
По факту соединений может быть около 700 на сервер, скорости от 128k
до 100Mb.

> > файлов много и они большие - кэш почти бесполезен;
>
> От задачи конечно зависит, но обычно есть какие-то более полулярные
> файлы, и менее популярные, так что кеш полезен.

А реализация кеша в linux умеет думать "отсюда я уже читал N раз,
подержим это в кеше подольше"? По факту данные из кеша очень быстро
"вымываются".

> > клиентов много, все качают разные куски разных файлов, то есть
> > читаются очень разные области диска небольшими порциями;
>
> Насчет небольших порций - это регулируется в какой-то мере.
> Например - задаем размер буфера отправки (на сокете) в 2048кб, и
> snd_lowat в 1024кб.

А snd_lowat и буферы играют при использовании sendfile разве? Ну и
буферы, в общем, ту же память используют, так что...

> Queueing есть и в дешевых вариантах. Во-первых операционная система
> запросы, поступающие в очередь, переупорядочивает (и это тоже
> настраивается все, deadline iosched например можно настроить на
> максимальную пропускную способность, сильно повредив времени отклика,
> он будет сотни запросов в секунду "объединять"), во-вторых SATA на
> современных чипсетах NCQ умеет.

А где почитать про переупорядочивание?