worker_rlimit_nofile

[Alexey Polyakov]

On 1/16/07, drmarker <drmarker at gmail.com> wrote:

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

Это на практике такая проблема возникла с 100 подключениями?
Суть-то верна, но проявляется не на таких цифрах.

> Как я это понимаю:
>
> файлов много и они большие - кэш почти бесполезен;

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

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

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

> чем больше клиентов - тем хаотичнее чтение и тем мелче порции. Тем
> больше метаний головок по блинам дисков, тем ниже пропускная
> способность дисковой подсистемы.

В принципе да. Но как я уже писал - инструментов для регулировки этих
дел много. Гораздо хуже случай, когда куча мелких файлов.

> Решений несколько:
> 1) увеличить скорость чтения с диска (RAID1 или лучше);
> 2) улучшить алгоритм чтения железно (перейти с IDE на SCSI, где есть queing);
> 3) улучшить алгоритм чтения софтверно (перейти с ext3 на XFS? JFS?);
> 4) ограничить набор файлов, чтобы луше работал кэш;
> 5) сократить количество клиентов и сессий, чтобы лучше работал кэш.
> 6) использовать multicast ;)

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

> Можно еще разделить серверы на fast и slow. C fast раздается небольшой
> набор наиболее популярных фильмов, а со slow - все остальное. Fast с
> дорогими и быстрыми, но мелкими файловыми подсистемами, а Slow - с
> медленными, но дешевыми. Можно делать сервера с мелкими SCSI дисками
> для популярных файлов и большими IDE дисками, для остальных.
>
> Все эти способы с разным успехом применяются. Жалко только, что стоит
> это все должно пять копеек :( А так бы сделали второй Akamai и не
> морочились бы :)

Ну тут весь вопрос в том, чего требуется достичь. При грамотной
настройке и из вполне дешевого железа можно выжать очень и очень
многое.

-- 
Alexey Polyakov