Сколько возможно подключений к сокетам?

Question

Кто-нибудь имеет представление о том, сколько соединений с tcp-сокетами возможно на современном стандартном корневом сервере?(Как правило, на каждом соединении меньше трафика, но все соединения должны быть подключены постоянно.)

Редактировать: Мы будем использовать сервер Linux.

Answer 1

Google в поисках " C10K " проблема. Это в основном обсуждение и технология управления 10 000 или более одновременными подключениями.

Я подозреваю, что это число было выбрано, потому что это сложно, но теоретически возможно.

Answer 2

Я добился 1600 тыс. одновременных подключений к простаивающим сокетам и в то же время 57 тыс. запросов в секунду на рабочем столе Linux (16 ГБ оперативной памяти, процессор I7 2600).Это однопоточный http-сервер, написанный на C с помощью epoll.Исходный код включен гитхаб, а ведите блог здесь.

Редактировать:

Я выполнил 600 тысяч одновременных HTTP-подключений (клиент и сервер) на одном компьютере с JAVA / Clojure .подробная информация Публикация, обсуждение HN: http://news.ycombinator.com/item?id=5127251

Стоимость подключения (с epoll):

• приложению требуется некоторое количество оперативной памяти для каждого подключения
• TCP-буфер 2 * 4k ~ 10k или более
• epoll требуется немного памяти для файлового дескриптора из epoll(7)

Каждый зарегистрированный файловый дескриптор стоит примерно 90 байт в 32-разрядном ядре и примерно 160 байт в 64-разрядном ядре.

Answer 3

Это зависит не только от рассматриваемой операционной системы, но и от конфигурации, потенциально от конфигурации в реальном времени.

Для Linux:

cat /proc/sys/fs/file-max

покажет текущее максимальное количество файловых дескрипторов, общее количество которых разрешено открывать одновременно. Ознакомьтесь с http://www.cs.uwaterloo.ca/~brecht/servers /openfiles.html

Answer 4

10,000?70,000?и это все :)

FreeBSD, вероятно, именно тот сервер, который вам нужен, Вот небольшой пост в блоге что касается настройки его на обработку 100 000 подключений, то в нем уже некоторое время есть некоторые интересные функции, такие как сокеты с нулевым копированием, а также kqueue, выполняющий роль механизма завершения порта.

Solaris может обрабатывать 100 000 подключений вернемся в прошлое столетие!.Они говорят, что linux был бы лучше

Лучшее описание, с которым я столкнулся, - это презентация / документ о написании масштабируемого веб-сервера.Он не боится сказать все как есть :)

То же самое касается программного обеспечения:кретины на уровне приложений внедрили отличные инновации на уровне операционной системы.Поскольку Lotus Notes поддерживает открытым одно TCP-соединение для каждого клиента, IBM внесла значительный вклад в оптимизацию для случая "один процесс, 100 000 открытых подключений” для Linux

И планировщик O (1) изначально был создан для хороших результатов в каком-то не относящемся к делу Java бенчмарке.Суть в том, что это раздувание приносит пользу всем нам.

Answer 5

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

Я полагаю, что вы должны иметь возможность достигать 100 тыс. соединений на разумной машине.

Answer 6

Ограничение на количество открытых сокетов настраивается в файловой системе / proc

cat /proc/sys/fs/file-max

Максимум для входящих соединений в ОС, определенных целочисленными ограничениями.

Сам Linux допускает миллиарды открытых сокетов.

Для использования сокетов необходимо прослушивание приложения, например, веб-сервер, который будет использовать определенный объем оперативной памяти на сокет.

RAM и CPU введут реальные ограничения. (современный 2017 год, думаю, миллионы, а не миллиарды)

1 миллион возможно, а не просто. Ожидайте использовать X гигабайт оперативной памяти для управления 1 миллионом сокетов.

Исходящие TCP-соединения ограничены номерами портов ~ 65000 на IP. Вы можете иметь несколько IP-адресов, но не неограниченные IP-адреса. Это ограничение в TCP, а не в Linux.

Answer 7

зависит от приложения. если есть только несколько пакетов от каждого клиента, 100K очень легко для Linux. Инженер моей команды провел тест несколько лет назад, и результат показывает: когда после установки соединения нет пакета от клиента, linux epoll может наблюдать 400k fd на предмет читабельности при уровне использования процессора ниже 50%.

Answer 8

Какая операционная система?

Для компьютеров с Windows, если вы пишете сервер для хорошего масштабирования и, следовательно, используете порты завершения ввода-вывода и асинхронный ввод-вывод, то основным ограничением является объем пула без выгрузки, который вы используете для каждого активного подключения.Это напрямую приводит к ограничению, основанному на объеме памяти, установленном на вашем компьютере (пул без выгрузки - это конечный объем фиксированного размера, основанный на общем объеме установленной памяти).

Для соединений, которые не получают большого трафика, вы можете уменьшить их эффективность, разместив "чтения с нулевым байтом", которые не используют пул без выгрузки страниц и не влияют на лимит заблокированных страниц (еще один потенциально ограниченный ресурс, который может помешать вам открыть множество подключений к сокетам).

Кроме того, вам нужно будет создать профиль, но мне удалось получить более 70 000 одновременных подключений к скромно указанному серверу (760 МБ памяти);смотрите здесь http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html для получения более подробной информации.

Очевидно, что если вы используете менее эффективную архитектуру, такую как "поток на соединение" или "выбор", то вам следует ожидать достижения менее впечатляющих показателей;но, ИМХО, просто нет причин выбирать такие архитектуры для серверов сокетов Windows.

Редактировать: смотрите здесь http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx;способ расчета объема пула без выгрузки изменился в Vista и Server 2008, и теперь доступно гораздо больше.

Answer 9

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