Jaka jest formuła określająca, ile pamięci zużywa gniazdo w systemie Linux?

Robię planowanie pojemności i zastanawiam się, czy istnieje formuła, której można użyć do przewidzenia (z punktu widzenia pamięci), ile połączeń TCP mogę obsłużyć na moim serwerze. W tej chwili martwię się tylko o wymagania dotyczące pamięci.

Niektóre zmienne, które, jak sądzę, pojawią się we wzorze, to:

• sysctl's net.ipv4.tcp_wmem(wartość minimalna lub domyślna)
• sysctl's net.ipv4.tcp_rmem(wartość minimalna lub domyślna)
• rozmiar sock, sock_common, proto i innych struktur danych dla poszczególnych gniazd.

Nie jestem pewien, ile z tcp_wmem i tcp_rmem jest faktycznie przydzielonych i kiedy ta pamięć jest przydzielona. W czasie tworzenia gniazda? Na żądanie?

Jeśli możesz zmodyfikować kod źródłowy, użyj danych rażenia do zmierzenia RSS i zanotuj, ile połączeń TCP jest w grze w czasie pomiaru.

Jeśli nie można zmienić kodu źródłowego, użyj kanału RSS aplikacji sieciowej zgłoszonego przez top lub ps i uzyskaj liczbę połączeń sieciowych w momencie pomiaru od lsof -i.

Zbieraj te dane co minutę, gdy Twoja aplikacja przechodzi przez szczytowe obciążenie, i na podstawie tych danych możesz opracować formułę, która wiąże liczbę połączeń z użyciem pamięci RAM.

Oczywiście jest o wiele więcej rzeczy, które można zmierzyć, w szczególności możesz zmierzyć użycie pamięci RAM jądra, chociaż struktury danych tcp powinny być przewidywalne i obliczalne z góry. W każdym razie zapoznaj się z tym pytaniem /server/10852/what-limits-the-maximum-number-of-connections-on-a-linux-server, aby uzyskać więcej informacji na temat strojenia TCP i jak uzyskać jasny obraz tego, co dzieje się na stosie sieciowym.

tcp_mem jest ważniejszy, ponieważ określa, jak powinien zachowywać się stos tcp, jeśli chodzi o użycie pamięci. Bufor wysyłania i odbierania IMO powinien być wielokrotnością tcp_mem. Oto link do formuły dla bufora odbiorczego: http://www.acc.umu.se/~maswan/linux-netperf.txt . W skrócie:

Narzut to: window / 2 ^ tcp_adv_win_scale (domyślna wartość tcp_adv_win_scale to 2) Tak więc dla domyślnych parametrów linux dla otrzymanego okna (tcp_rmem): 87380 - (87380/2 ^ 2) = 65536. Biorąc pod uwagę transatlantycki link (150 ms RTT), maksymalna wydajność kończy się na: 65536 / 0,150 = 436906 bajtów / s lub około 400 kb / s, co dzisiaj jest naprawdę wolne. Przy zwiększonym domyślnym rozmiarze: (873800 - 873800/2 ^ 2) /0.150 = 4369000 bajtów / s lub około 4 MB / s, co jest rezonansowe dla nowoczesnej sieci. I zauważ, że jest to ustawienie domyślne, jeśli nadawca jest skonfigurowany z większym rozmiarem okna, z radością skaluje się nawet 10-krotnie (8738000 * 0,75 / 0,150 = ~ 40 MB / s), całkiem nieźle jak na nowoczesną sieć.

Oto, co artykuł mówi o tcp_mem:

To, co usuwasz, to sztuczny limit wydajności tcp, bez tego ograniczenia jesteś ograniczony dostępną przepustowością i stratą. Więc możesz skończyć bardziej nasycając łącze uplink, ale tcp dobrze sobie z tym radzi.

IMO większa środkowa wartość tcp_mem przyspiesza połączenie przy utracie bezpieczeństwa i nieznacznie zwiększa zużycie pamięci.

Możesz monitorować stos sieciowy za pomocą:

grep skbuff /proc/slabinfo

David udzielił bardzo dobrej odpowiedzi na zadane pytanie, jednak jeśli nie używasz wyłącznie sieci LFN , to nawet na serwerze opartym na zdarzeniach bufory TCP prawdopodobnie będą tylko niewielką częścią śladu na połączenie.

W przypadku planowania pojemności nie ma substytutu testowania serwera i obliczania regresji zużycia pamięci według obciążenia.