Jak Receive-Side Scaling rozkłada obciążenie sieciowe serwera domowego?

Receive-Side Scaling rozkłada obciążenie sieciowe serwera domowego, haszując przychodzące strumienie do wielu kolejek odbiorczych karty sieciowej (NIC) i przypisując te kolejki do różnych rdzeni procesora. Zamiast jednego rdzenia obsługującego niemal każde przerwanie odbioru i zadania protokołu, kilka rdzeni może przetwarzać niezależne połączenia równolegle.

RSS jest najbardziej przydatne, gdy serwer odbiera wystarczająco dużo pakietów, aby jeden rdzeń stał się wąskim gardłem. Nie przyspiesza pojedynczego dysku, nie zwiększa przepustowości sieci ani nie dzieli jednego zwykłego strumienia TCP równomiernie na wszystkie rdzenie. Jego zadaniem jest usunięcie wąskiego gardła w przetwarzaniu pakietów przy zachowaniu kolejności strumienia.

Główny mechanizm: wiele kolejek odbiorczych zasila wiele rdzeni

Bez wielokolejkowego przetwarzania odbioru szybka karta sieciowa może dostarczać pracę do jednej ścieżki przerwań szybciej, niż jeden rdzeń CPU jest w stanie ją obsłużyć. Całkowite użycie CPU może wyglądać na niewielkie, ponieważ pozostałe rdzenie są bezczynne, jednak przepustowość osiąga plateau, a opóźnienia sieci rosną na przeciążonym rdzeniu.

RSS wykorzystuje wiele kolejek odbiorczych, dzięki czemu przychodzące strumienie mogą być obsługiwane równocześnie. Każda kolejka generuje własne przerwanie i ścieżkę przetwarzania, co pozwala systemowi operacyjnemu wykorzystać więcej dostępnych zasobów CPU.

Ma to znaczenie na serwerze domowym, który jednocześnie obsługuje udostępnianie plików, strumienie multimedialne, kopie zapasowe i aplikacje kontenerowe. Te niezależne połączenia zapewniają równoległą pracę, której potrzebuje RSS; lekko obciążone łącze 1GbE może nigdy nie wygenerować wystarczającego natężenia pakietów, aby różnica była zauważalna.

Haszowanie strumieni zachowuje kolejność przy rozkładaniu połączeń

Karta sieciowa oblicza hash na podstawie pól nagłówka pakietu, takich jak adresy źródłowe i docelowe, porty oraz protokół. Tabela pośrednia mapuje ten hash na kolejkę odbiorczą. Pakiety z tego samego strumienia zwykle trafiają do tej samej kolejki, co zapobiega zmianie kolejności strumienia podczas równoległego przetwarzania.

Zależność między RSS, powiązaniem IRQ i RPS decyduje o tym, gdzie praca jest faktycznie wykonywana w systemie Linux. Sprzętowe RSS wybiera kolejkę odbiorczą; powiązanie przerwań łączy tę kolejkę z rdzeniem CPU; oprogramowanie może później przekierować pracę protokołu, gdy liczba kolejek sprzętowych jest ograniczona.

Haszowanie równoważy wiele strumieni statystycznie, a nie idealnie. Kilka ciężkich strumieni może zderzyć się w jednej kolejce, a jeden dominujący strumień może pozostać przypisany do jednego rdzenia. Dlatego obserwacje na poziomie rdzenia i kolejki są bardziej przydatne niż zakładanie, że wielordzeniowy CPU gwarantuje równomierne obciążenie sieci.

Więcej kolejek może wymienić ulgę w wąskim gardle na narzut CPU

Zwiększenie liczby kolejek stwarza więcej możliwości równoległości, ale także generuje więcej przerwań, zadań planowania i przemieszczania pamięci podręcznej. Optymalna liczba kolejek zależy od możliwości karty sieciowej, topologii CPU, natężenia ruchu oraz tego, czy aplikacje przetwarzające pakiety działają blisko przetwarzania odbioru.

Praktyczne wyjaśnienie nasycenia odbioru na jednym rdzeniu pokazuje, dlaczego całkowity procent użycia CPU może ukrywać prawdziwe ograniczenie. Przydatnym testem jest sprawdzenie, czy jeden rdzeń jest obciążony przerwaniami lub pracą softirq, podczas gdy inne rdzenie mają zapas mocy.

RSS może też zwiększać narzut, gdy ruch jest zbyt lekki, by go potrzebować. Równoległy rozdział pakietów poprawia skalowalność, ale rozmieszczenie kolejek i lokalność strumień-rdzeń nadal wpływają na efektywność. Dlatego włączenie wszystkich możliwych kolejek nie jest uniwersalną optymalizacją.

Jak RSS zmienia wąskie gardło serwera domowego

RSS pomaga, gdy ścieżka odbioru jest ograniczona przez CPU: jeden rdzeń wykazuje wysokie obciążenie przetwarzaniem sieci, kilku klientów jest aktywnych, a pamięć masowa ma jeszcze zapas mocy. Nie pomoże, gdy łącze Ethernet jest pełne, dyski nie nadążają z obciążeniem, szyfrowanie dominuje czas CPU lub jedna aplikacja serializuje wszystkie żądania.

Porównaj liczniki kolejek NIC, obciążenie przerwań na rdzeń, przepustowość i opóźnienia aplikacji przed i po kontrolowanej zmianie. Szersza analiza wąskich gardeł serwera domowego pomaga zapobiec sytuacji, w której zmiana ustawień sieci maskuje ograniczenia pamięci masowej, pamięci operacyjnej lub mocy obliczeniowej.

Najczęściej zadawane pytania

Czy RSS dzieli jedno połączenie TCP na wszystkie rdzenie?

Zazwyczaj nie. RSS utrzymuje pakiety z jednego strumienia w tej samej kolejce, aby zachować kolejność. Korzyść ze skalowania jest najbardziej widoczna, gdy kilka niezależnych strumieni może być haszowanych do kilku kolejek.

Czy RSS jest przydatne na serwerze domowym z 1GbE?

Może być, zwłaszcza przy wielu małych pakietach lub niskonapięciowym CPU, ale wiele systemów jest w stanie obsłużyć 1GbE na jednym rdzeniu. Zmierz obciążenie na rdzeń, zanim uznasz RSS za brakującą funkcję wydajnościową.

Czy RSS i RPS to to samo?

Nie. RSS kieruje pakiety w sprzęcie NIC do kolejek odbiorczych, podczas gdy Receive Packet Steering (RPS) wykonuje powiązany krok dystrybucji w oprogramowaniu. Mogą się uzupełniać, gdy liczba kolejek sprzętowych jest ograniczona.