Tcp

Или как траблшутить контейнеры когда нечем.

Протестировал работу TCP Congestion Control в Linux в различных по качеству окружениях, поделюсь результатами.

Привет! Продолжаем изучать маршрут сетевого пакета по подсистемам ядра linux. В первой части мы разобрали отрезок от сетевой карты гипервизора до txqueue - очередь перед виртуальной машиной в которой и крутится наш сервис. Теперь разберем следующий отрезок - от сетевой карты ВМ и до самого приложения. RX queue Процесс обработки трафика виртуальной машиной идентичен с гипервизоров - softirqd демоны разгребают RX очереди. Ничего нового. Различия начинаются на уровнях сетевого стека, точнее перед ним....

Прежде чем сетевой пакет из сервиса А попадет в сервис Б, ему следует миновать множество систем по середине…

Объем TCP ретрансмитов пожалуй один из наиболее говорящих симптомов деградации системы. Причины возникновения могут быть различны, самые частые в моей практике: переполнения очередей, на уровнях сетевого оборудования, NIC, операционной системы, сокетов, etc; out of order пакеты, связанные например с неоднородными маршрутами в рамках одного сетевого потока. В момент проблемы хочется быстро ее обнаружить и определить источник. Стандартные утилиты На помощь приходят встроенные в linux утилиты: netstat -s | grep -i retr 3951614 segments retransmitted 1434 times recovered from packet loss due to fast retransmit Detected reordering 149 times using reno fast retransmit TCPLostRetransmit: 2931590 981 timeouts after reno fast retransmit 3538 fast retransmits 4126 retransmits in slow start TCPSynRetrans: 3918500 Те же метрики мы можем собрать и node_exporter’ом: Проблема в слишком “общей” картине таких метрик....