Linux

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

Об утилите cachestat я узнал из статьи Brendan Gregg - Analyzing a High Rate of Paging. В ней расследуются причины аномально долгого процессинга файлов размером в 100Gbytes, тогда как файлы в 40Gbytes обрабатывались на несколько порядков быстрее. В том кейсе точно поставить диагноз - большой объект не помещался в кеш, что приводило к trashing’у страниц памяти, автору помог инструмент cachestat. Если в кратце, то утилита подсчитывает соотношение попаданий в кеш файловой системы относительно общего числа операций на чтение - cache hit ratio:...

Проблематика Чтобы оценить производительность ввода/вывода обычно принято обращаться к метрикам дисковой подсистемы, благо они богато представлены “стандартными” инструментами linux - sar, iostat, atop, etc. Проблема данного подхода, в упрощении общей картины, он игнорирует такой важный компонент в работе I/O подсистемы как файловая система. Например: приложение может использовать асинхронную модель записи и flush на диск происходит порциями и когда-то потом; приложение хочет прочитать 1 байт данных, но считать с диска возможно только блоком в 4096 байт; используется read-ahead при последовательном чтении; чтение происходит из кеша файловой системы - запросов на чтение много, а диск почти не загружен; и так далее....

На днях диагностировал утечку памяти в кластере 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’ом: Проблема в слишком “общей” картине таких метрик....