Яка формула визначає, скільки пам'яті споживає сокет під Linux?


11

Я займаюся деяким плануванням потужностей, і мені було цікаво, чи існує формула, яку я міг би використати, щоб передбачити (з точки зору пам'яті), скільки TCP-з'єднань я міг би обробити на своєму сервері. На даний момент мене турбують лише вимоги пам’яті.

Деякі змінні, які, на мою думку, з'являться у формулі:

  • sysctl net.ipv4.tcp_wmem(мінімум або значення за замовчуванням)
  • sysctl net.ipv4.tcp_rmem(мінімум або значення за замовчуванням)
  • розмір носка, sock_common, proto та інших структур даних на сокет.

Я не впевнений, скільки фактично виділено tcp_wmem та tcp_rmem і коли ця пам'ять буде виділена. На час створення розетки? На вимогу?

Відповіді:


2

Якщо ви можете змінити вихідний код, використовуйте дані про використання для вимірювання RSS та запишіть, скільки підключень TCP відтворюється на момент вимірювання.

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

Збирайте ці дані щохвилини, коли ваша програма переміщується через пікове навантаження, і з цих даних ви можете скласти формулу, яка стосується кількості підключень до використання оперативної пам'яті.

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


Дякуємо за напружене вимірювання та за те, що вказали на посилання, які показують, як збирати ці показники!
Тім Стюарт

8

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

1
Дякуємо за інформативну відповідь. Це показує, скільки мені потрібно дізнатися про мережу.
Тім Стюарт

1

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

Для планування потужностей немає заміни для тестування сервера та обчислення регресії використання пам'яті навантаженням.


Дякую, це чудово, коли вийде проста формула, але є такі часи, коли просто потрібно виміряти.
Тім Стюарт
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.