network linux troubleshooting - ghdrako/doc_snipets GitHub Wiki

tags:

linux
networking
performance
sysadmin
troubleshooting

Diagnostyka odbioru ruchu sieciowego w Linux

1. Przepływ pakietu

Uproszczony przepływ odebranego pakietu:

SIEĆ
  ↓
NIC
  ↓
RX ring / buffer karty
  ↓
NAPI
  ↓
CPU / softirq
  ↓
softnet / backlog
  ↓
kernel network stack
  ↓
UDP socket
  ↓
aplikacja

Problem z odbiorem może wystąpić na każdym z tych etapów.

2. NIC queue / RX ring

Sprawdzenie

ethtool -g ens2f1

Pokazuje rozmiary sprzętowych kolejek karty sieciowej.

Przykład:

Ring parameters for ens2f1:
Pre-set maximums:
RX: 4096
TX: 4096

Current hardware settings:
RX: 1024
TX: 1024

Najważniejsze jest:

RX – Receive, czyli kolejka odbieranych pakietów,
TX – Transmit, czyli kolejka wysyłanych pakietów.

Można to traktować jako miejsce, w którym karta odkłada odebrane pakiety, zanim CPU je przetworzy.

Jeżeli ruch jest bardzo duży i CPU nie nadąża, RX ring może się zapełnić i mogą wystąpić dropy.

3. Dropy na karcie sieciowej

Sprawdzenie

ethtool -S ens1f1 | grep -Ei 'drop|miss|error|discard'

ethtool -S pokazuje szczegółowe statystyki sterownika/NIC.

Interesujące są przede wszystkim liczniki związane z:

rx_*drop*
rx_*miss*
rx_*error*

Nazwy liczników zależą od konkretnej karty i sterownika.

Do obserwacji w czasie można użyć:

watch -n 1 'ethtool -S ens1f1 | grep -Ei "drop|miss|error|discard"'

Interpretacja

Drop na tym poziomie oznacza, że pakiet został utracony zanim został normalnie przekazany dalej do stosu sieciowego.

4. `/proc/net/softnet_stat`

cat /proc/net/softnet_stat

Pokazuje statystyki przetwarzania ruchu sieciowego przez kernel.

Każdy wiersz odpowiada jednemu CPU:

CPU0 → pierwszy wiersz
CPU1 → drugi wiersz
CPU2 → trzeci wiersz
CPU3 → czwarty wiersz
...

Dane są zapisane w postaci szesnastkowej.

Uwaga: znaczenie poszczególnych kolumn zależy od wersji kernela. Nie należy bezwarunkowo interpretować kolumn wyłącznie na podstawie ich numeru bez sprawdzenia wersji kernela/dokumentacji.

5. NAPI i `netdev_budget`

Sprawdzenie:

cat /proc/sys/net/core/netdev_budget

netdev_budget określa budżet pracy NAPI podczas jednego przebiegu przetwarzania ruchu sieciowego.

Uproszczony przykład:

netdev_budget = 300

Do obsłużenia jest 1000 pakietów:

300 → pierwszy przebieg
300 → drugi
300 → trzeci
100 → kolejny

Mechanizm ten chroni CPU przed sytuacją, w której obsługa sieci zablokowałaby CPU na zbyt długo.

6. `dev_weight`

Sprawdzenie:

cat /proc/sys/net/core/dev_weight

dev_weight określa domyślną wagę/limit liczby pakietów obsługiwanych przez NAPI w jednym przebiegu dla danego CPU.

Uproszczony model:

netdev_budget
    ↓
budżet pracy dla przebiegu softirq/NAPI

dev_weight
    ↓
domyślna waga NAPI na CPU

Nie należy traktować tego dosłownie jako:

netdev_budget = wszystkie NIC
dev_weight   = jeden NIC

Jest to bardziej złożone i zależy od wersji kernela oraz implementacji NAPI.

7. Backlog

Sprawdzenie:

cat /proc/net/softnet_stat

oraz:

cat /proc/sys/net/core/netdev_max_backlog

Backlog jest kolejką pakietów oczekujących na dalsze przetwarzanie przez kernel.

Schemat:

NIC → NAPI → backlog → kernel network stack → socket → aplikacja

Jeżeli pakiety napływają szybciej, niż CPU może je przetwarzać:

napływ pakietów
████████████████████████

CPU przetwarza
██████

backlog
██████████████████

Backlog zaczyna rosnąć.

Jeżeli kolejka zostanie przepełniona, pakiety mogą zostać odrzucone.

`netdev_max_backlog`

cat /proc/sys/net/core/netdev_max_backlog

Określa maksymalną liczbę pakietów oczekujących w kolejce backlog, gdy ruch jest odbierany szybciej, niż kernel może go przetwarzać.

8. UDP socket buffer

Po przejściu przez NIC, NAPI i kernel network stack pakiet UDP musi trafić do odpowiedniego socketu.

Można to przedstawić:

NIC
 ↓
NAPI
 ↓
CPU
 ↓
kernel network stack
 ↓
UDP socket
 ↓
receive buffer
 ↓
aplikacja

Sprawdzenie parametrów:

cat /proc/sys/net/core/rmem_default
cat /proc/sys/net/core/rmem_max

`rmem_default`

Domyślny rozmiar receive buffer dla socketu.

`rmem_max`

Maksymalny rozmiar receive buffer, jaki może zostać przydzielony socketowi.

rmem_max nie oznacza, że każdy socket automatycznie otrzymuje bufor tej wielkości.

9. Dlaczego UDP jest istotne przy diagnostyce dropów?

UDP nie zapewnia retransmisji na poziomie protokołu tak jak TCP.

Jeżeli aplikacja nie odbiera danych wystarczająco szybko:

NIC
 ↓
kernel
 ↓
UDP socket buffer
 ↓
████████████████  ← pełny
 ↓
DROP

Pakiet może zostać utracony.

Dlatego przy problemach z UDP trzeba ustalić, na którym etapie następuje drop.

                    DROP
                      ↓
NIC → RX ring → NAPI → backlog → UDP socket → aplikacja
       ↑          ↑        ↑          ↑
       │          │        │          │
    ethtool    softnet   backlog    UDP stats

10. Statystyki UDP – `netstat -s -u`

netstat -s -u

Pokazuje statystyki protokołu UDP.

Przykładowe interesujące pola:

Udp:
    packets received
    packet receive errors
    receive buffer errors
    send buffer errors

Szczególnie ważne przy problemach z odbiorem:

packet receive errors
receive buffer errors

11. Statystyki UDP – `/proc/net/snmp`

Alternatywnie:

cat /proc/net/snmp | grep Udp

Typowo pojawią się dwa wiersze.

Pierwszy zawiera nazwy pól:

Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors ...

Drugi zawiera wartości:

Udp: 100000 10 500 80000 400

Najważniejsze pola

`InDatagrams`

Liczba datagramów UDP dostarczonych do aplikacji.

`NoPorts`

Liczba pakietów UDP skierowanych na port, na którym nie ma nasłuchującego socketu.

`InErrors`

Błędy podczas odbierania UDP.

`RcvbufErrors`

Sytuacje, w których nie udało się umieścić odebranego datagramu w buforze odbiorczym socketu.

Jeżeli RcvbufErrors rośnie podczas problemu, warto sprawdzić:

rozmiar receive buffer,
szybkość odbierania danych przez aplikację,
obciążenie CPU,
wcześniejsze etapy ścieżki pakietu.

12. `netstat -i`

netstat -i

Pokazuje podstawowe statystyki interfejsów sieciowych.

Przykładowe kolumny:

Iface    MTU   RX-OK RX-ERR RX-DRP TX-OK TX-ERR TX-DRP
ens1f1   1500  ...

Najważniejsze przy odbiorze:

RX-OK – poprawnie odebrane pakiety,
RX-ERR – błędy odbioru,
RX-DRP – odrzucone pakiety.

Do szczegółowej diagnostyki NIC lepsze jest:

ethtool -S ens1f1

ponieważ pokazuje znacznie więcej informacji zależnych od karty i sterownika.

13. Najważniejsza zasada diagnostyczna – obserwuj przyrosty

Nie należy patrzeć tylko na aktualną wartość licznika.

Najważniejszy jest przyrost licznika podczas występowania problemu.

Przykład:

START
RcvbufErrors = 1000

test przez 60 sekund

KONIEC
RcvbufErrors = 1000

Brak nowych błędów receive buffer.

Natomiast:

START
RcvbufErrors = 1000

test przez 60 sekund

KONIEC
RcvbufErrors = 150000

oznacza:

150000 - 1000 = 149000

nowych problemów z receive buffer UDP.

To jest znacznie bardziej wartościowa informacja diagnostyczna niż sama wartość:

rmem_max = 212992

14. Praktyczna procedura diagnostyczna UDP

Podczas występowania problemu warto zebrać:

NIC

ethtool -g ens1f1

ethtool -S ens1f1 | grep -Ei 'drop|miss|error|discard'

CPU / softnet

cat /proc/net/softnet_stat

Parametry NAPI

cat /proc/sys/net/core/netdev_budget
cat /proc/sys/net/core/dev_weight

Backlog

cat /proc/sys/net/core/netdev_max_backlog
cat /proc/net/softnet_stat

UDP

netstat -s -u

lub:

cat /proc/net/snmp | grep Udp

Socket buffers

cat /proc/sys/net/core/rmem_default
cat /proc/sys/net/core/rmem_max

15. Jak znaleźć miejsce występowania dropów?

Ogólny model:

                 ┌── RX drop / miss
                 │
                 ▼
NIC → RX ring → NAPI → softnet/backlog → UDP socket → aplikacja
                  │          │              │
                  │          │              │
             softnet      backlog       RcvbufErrors

Jeżeli rosną liczniki NIC

Sprawdzaj:

ethtool -S

Podejrzenie:

przepełnienie RX ring,
problem sterownika,
problem sprzętowy,
zbyt duży napływ ruchu,
niewystarczająca obsługa przez CPU.

Jeżeli problem widać w `softnet_stat`

Sprawdzaj:

obciążenie CPU,
rozkład ruchu pomiędzy CPU,
NAPI,
netdev_budget,
dev_weight.

Jeżeli problem dotyczy backlog

Sprawdzaj:

cat /proc/sys/net/core/netdev_max_backlog

oraz statystyki softnet_stat.

Jeżeli rośnie `RcvbufErrors`

Sprawdzaj:

cat /proc/sys/net/core/rmem_default
cat /proc/sys/net/core/rmem_max

oraz przede wszystkim:

czy aplikacja nadąża odbierać UDP,
czy socket receive buffer nie jest za mały,
czy CPU nie jest przeciążone.

16. Ściąga

Element	Komenda	Co sprawdzamy
RX/TX ring	`ethtool -g ens1f1`	rozmiar kolejek NIC
Statystyki NIC	`ethtool -S ens1f1`	dropy, miss, błędy
Softnet	`cat /proc/net/softnet_stat`	przetwarzanie przez CPU/NAPI
NAPI budget	`cat /proc/sys/net/core/netdev_budget`	budżet pracy NAPI
NAPI weight	`cat /proc/sys/net/core/dev_weight`	domyślna waga NAPI
Backlog	`cat /proc/sys/net/core/netdev_max_backlog`	rozmiar kolejki backlog
UDP	`netstat -s -u`	błędy UDP
UDP	`cat /proc/net/snmp \| grep Udp`	`InErrors`, `RcvbufErrors`
Interface	`netstat -i`	RX/TX OK, ERR, DRP
Socket buffer	`rmem_default`	domyślny receive buffer
Socket buffer	`rmem_max`	maksymalny receive buffer

Najważniejszy model

NIC
 ↓
RX ring
 ↓
NAPI
 ↓
CPU / softirq
 ↓
softnet / backlog
 ↓
UDP network stack
 ↓
UDP socket buffer
 ↓
aplikacja

Przy problemie z UDP należy ustalić, na którym z tych etapów pakiety są gubione.

network linux troubleshooting - ghdrako/doc_snipets GitHub Wiki

Diagnostyka odbioru ruchu sieciowego w Linux

1. Przepływ pakietu

2. NIC queue / RX ring

Sprawdzenie

3. Dropy na karcie sieciowej

Sprawdzenie

Interpretacja

4. /proc/net/softnet_stat

5. NAPI i netdev_budget

6. dev_weight

7. Backlog

netdev_max_backlog

8. UDP socket buffer

rmem_default

rmem_max

9. Dlaczego UDP jest istotne przy diagnostyce dropów?

10. Statystyki UDP – netstat -s -u

11. Statystyki UDP – /proc/net/snmp

Najważniejsze pola

InDatagrams

NoPorts

InErrors

RcvbufErrors

12. netstat -i

13. Najważniejsza zasada diagnostyczna – obserwuj przyrosty

14. Praktyczna procedura diagnostyczna UDP

NIC

CPU / softnet

Parametry NAPI

Backlog

UDP

Socket buffers

15. Jak znaleźć miejsce występowania dropów?

Jeżeli rosną liczniki NIC

Jeżeli problem widać w softnet_stat

Jeżeli problem dotyczy backlog

Jeżeli rośnie RcvbufErrors

16. Ściąga

Najważniejszy model

4. `/proc/net/softnet_stat`

5. NAPI i `netdev_budget`

6. `dev_weight`

`netdev_max_backlog`

`rmem_default`

`rmem_max`

10. Statystyki UDP – `netstat -s -u`

11. Statystyki UDP – `/proc/net/snmp`

`InDatagrams`

`NoPorts`

`InErrors`

`RcvbufErrors`

12. `netstat -i`

Jeżeli problem widać w `softnet_stat`

Jeżeli rośnie `RcvbufErrors`