Какая формула определяет, сколько памяти использует сокет под Linux?

Я занимаюсь планированием емкости, и мне было интересно, есть ли формула, которую я мог бы использовать, чтобы предсказать (с точки зрения памяти), сколько TCP-соединений я мог бы обработать на моем сервере. На данный момент меня интересуют только требования к памяти.

Некоторые переменные, которые, я думаю, будут отображаться в формуле:

• sysctl net.ipv4.tcp_wmem(мин или значение по умолчанию)
• sysctl net.ipv4.tcp_rmem(мин или значение по умолчанию)
• размер sock, sock_common, proto и других структур данных для каждого сокета.

Я не уверен, сколько из tcp_wmem и tcp_rmem фактически выделено и когда выделяется эта память. Во время создания сокета? По требованию?

Если вы можете изменить исходный код, то используйте данные rusage, чтобы измерить RSS и записать, сколько соединений TCP воспроизводится во время измерения.

Если исходный код не может быть изменен, используйте RSS-канал сетевого приложения, сообщенный top или ps, и получите количество сетевых подключений на момент измерения от lsof -i.

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

Конечно, вы можете измерить намного больше вещей, в частности, вы можете измерить использование ОЗУ ядра, хотя структуры данных tcp должны быть предсказуемыми и рассчитанными заранее. В любом случае, посмотрите на этот вопрос /server/10852/what-limits-the-maximum-number-of-connections-on-a-linux-server для получения дополнительной информации о настройке TCP и как получить четкое представление о том, что происходит в сетевом стеке.

tcp_mem более важен, потому что он определяет, как должен вести себя стек tcp, когда речь идет об использовании памяти. Буфер отправки и получения IMO должен быть кратным tcp_mem. Вот ссылка на формулу для буфера приема: http://www.acc.umu.se/~maswan/linux-netperf.txt . Короче говоря:

Служебные расходы: window / 2 ^ tcp_adv_win_scale (tcp_adv_win_scale по умолчанию равно 2). Таким образом, для параметров по умолчанию в linux для окна получения (tcp_rmem): 87380 - (87380/2 ^ 2) = 65536. Учитывая трансатлантическую ссылку (150 мс RTT), максимальная производительность достигает 65536 / 0,150 = 436906 байт / с или около 400 кбайт / с, что сегодня очень медленно. С увеличенным размером по умолчанию: (873800 - 873800/2 ^ 2) /0.150 = 4369000 байт / с или около 4 Мбайт / с, что является приемлемым для современной сети. И обратите внимание, что это значение по умолчанию, если отправитель настроен на больший размер окна, он с радостью увеличится в 10 раз (8738000 * 0,75 / 0,150 = ~ 40 Мбайт / с), что очень хорошо для современной сети.

Вот что говорится в статье о tcp_mem:

То, что вы удаляете, - это искусственное ограничение производительности TCP, без которого вы ограничены доступной сквозной пропускной способностью и потерями. Таким образом, вы можете закончить насыщение восходящей линии более эффективно, но tcp хорошо справляется с этим.

IMO большее среднее значение tcp_mem ускоряет соединение при потере меньшей безопасности и немного увеличивает использование памяти.

Вы можете контролировать сетевой стек с помощью:

grep skbuff /proc/slabinfo

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

Для планирования емкости нет альтернативы тестированию сервера и вычислению регрессии использования памяти под нагрузкой.