Теоретический предел файловых дескрипторов в Linux

Question

Я использую выделенный прокси-сервер со Squid и пытаюсь определить максимальное количество соединений, которые может обработать сервер. Я понял, что это сводится к доступным файловым дескрипторам на компьютере с Linux.

Я нашел много информации об увеличении максимальных дескрипторов файлов, но я бы хотел узнать теоретический максимум. Согласно вопросу StackOverflow «Почему операционные системы ограничивают файловые дескрипторы?» , это сводится к доступной системной памяти, что имеет большой смысл.

Теперь, учитывая, сколько у меня доступно ОЗУ, как я могу определить максимальное значение для файловых дескрипторов для операционной системы? Некоторое значение, которое, очевидно, все еще позволяло бы системе стабильно работать.

Возможно, у кого-то может быть идея о других высокопроизводительных производственных серверах? Какова «норма» для максимизации потенциального числа одновременных соединений (файловых дескрипторов)? Буду очень признателен за понимание того, как я могу максимально использовать файловые дескрипторы для системы Linux.

Answer 1

У вас много ограничений.

• Multiplexing. Это не должно быть проблемой, если ваше приложение использует достойный бэкэнд. Libev претендует на мультиплексирование с задержкой 350us на 100 000 файловых дескрипторов.

• Скорость нанесения. Задержка приложения в 1 мс при таком масштабе (довольно низком) на запрос может занять почти две минуты для обслуживания 100 000 запросов в оптимальных условиях.

• Bandwidth. В зависимости от вашего приложения и эффективности протокола, это может быть проблемой. Вы говорите, что это прокси-сервер squid ... если вы используете прокси-серверы: клиент без кеша, запрашивающий сайт, может получать от нескольких сотен КБ до нескольких МБ. Если ваш средний полностраничный запрос на одного клиента составлял 500 КБ, вы бы максимально использовали полное гигабитное соединение со скоростью 2000 запросов в секунду. Это может быть вашим ограничивающим фактором.

2000 файловых дескрипторов - довольно небольшое количество. Я видел простые приложения на таких языках, как Python, для масштабирования более 3000 активных соединений на одном ядре процессора без больших задержек.

Вы можете протестировать свой прокси-сервер Squid с помощью программного обеспечения, такого как apachebench, работающего на нескольких клиентских компьютерах, чтобы получить реалистичные цифры. Довольно легко установить ограничение на количество дескрипторов файлов до 2000+ и посмотреть, что произойдет, и будет ли это вообще иметь значение.