Linux

На днях диагностировал утечку памяти в кластере haproxy, в процессе исследования допустил несколько ошибок, что привело к более долгой локализации проблемы. На примере данного кейса хочу провести небольшое ретро. Моя основная деятельность связана с поиском и устранением проблем, негативно влияющих на производительность системы в целом, будь то runtime приложения, сеть, слой виртуализации, база данных или что-угодно еще. В этот раз по OOM прибило несколько экземпляров haproxy - согласитесь событие нестандартное. Требовалось понять причины и предложить решение....

Объем 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’ом: Проблема в слишком “общей” картине таких метрик....