Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: worker_rlimit_nofile
> 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 умеет.
А где почитать про переупорядочивание?
| 
