worker_rlimit_nofile

[drmarker]

> > Забыл сказать, что сессий мало, а файлы - большие. Мелких файлов,
> > проксируемых страниц и прочего такого нет.
> >
> > Есть какие-нибудь дополнения с учетом этого?
>
> А какую пропускную способность надо обеспечить?
> Если канал 100-мегабитный, то при подобной задаче его полностью
> загрузить можно без всяких специальных ухищрений.

Ну не совсем.

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

Как я это понимаю:

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

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

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

Задача в том, чтобы читались по возможности ПОСЛЕДОВАТЕЛЬНО соседние
области диска или читались большими кусками.

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

Можно еще разделить серверы на fast и slow. C fast раздается небольшой
набор наиболее популярных фильмов, а со slow - все остальное. Fast с
дорогими и быстрыми, но мелкими файловыми подсистемами, а Slow - с
медленными, но дешевыми. Можно делать сервера с мелкими SCSI дисками
для популярных файлов и большими IDE дисками, для остальных.

Все эти способы с разным успехом применяются. Жалко только, что стоит
это все должно пять копеек :( А так бы сделали второй Akamai и не
морочились бы :)