A Complete Guide of 'ss' Output Metrics by Mark Zhu

Самое подробное описание использования утилиты ss что я встречал.

tags: #network #linux #troubleshooting #tooling

Написал в блог заметку о методологии "Thread State Analysis" (TSA).

Это когда о поведении системы судят по тому, в каком состоянии (state) пребывают её потоки: running, sleep, stopped и т.д.

TSA, как и другие высокоуровневые методологии (USE, RED), может помочь сориентироваться, определить направления для дальнейшего анализа и сократить общее время устранения проблем.

tags: #methodology #linux #troubleshooting

Есть такой ресурс sadservers.com, позиционирует себя как «leetcode для linux”.

На нём собраны задачки разной степени сложности из разряда «процесс PostgreSQL перестал работать, найди причину и устрани».

Подобное может встречаться на секциях технических собесов, что добавляет полезности, да и просто интересно проверить свои навыки.

В качестве пробы пера записал видео с прохождением первой задачи с небольшими теоретическими отступлениями.

SadServers №15 | Middle-level | Tokyo

Траблшутинг в ленту!

Tokyo - пятнадцатая задача среднего (middle) уровня на sadservers.com:
- изучим состояние сокетов через ss;
- посмотрим на ретрансмиты в tcpdump;
- поправив правила netfilter (iptables);
- и наконец приведем в чувства webserver.

#sadservers #linux #devops #troubleshooting #sre #tcpdump

В свое время читал статью Why does one NGINX worker take all the load? от Cloudflare, где обсуждалась проблема неравномерной балансировки трафика по воркерам nginx.

Типичная картина может выглядеть так:

# ps -eo comm,%cpu --sort=-%cpu | grep nginx
nginx           54.8
nginx           40.6
nginx           24.6
nginx           10.7
nginx            2.9
nginx            0.4
nginx            0.0

Как решение предлагалось использовать опцию TCP сокета SO_REUSEPORT, что позволяет выровнять нагрузку путем совместного шаринга одного порта несколькими воркерами.

В nginx директива зовется reuseport (см. документацию), выключенная по умолчанию.

А вот в Nginx Ingress Controller или в Haproxy наоборот - опция идет "из коробки".

В последнем даже есть интереcный комментарий:

Since HAProxy uses SO_REUSEPORT and supports having multiple independent
processes bound to the same IP:port, during troubleshooting it can happen that
an old process was not stopped before a new one was started. This provides
absurd test results which tend to indicate that any change to the configuration
is ignored. The reason is that in fact even the new process is restarted with a
new configuration, the old one also gets some incoming connections and
processes them, returning unexpected results...

Вот на такую штуку мы и наткнулись - старый Haproxy по ошибке не был выведен из строя, рядом подняли новый и в моменте два независимых вебсервера параллельно обрабатывали запросы с одного порта. А мы гадали какого черта ответы от одной и той же машины такие разные.

Надо быть аккуратнее ;)

P.S. кстати отключить в Haproxy эту дивную оптимизацию можно через noreuseport.

tags: #haproxy #troubleshooting #кейс

The Art of System Debugging — Decoding CPU Utilization

Или как баг в Java вызвал перегрузку CPU из-за избыточного чтения cgroupfs.

Заметка показывает, как eBPF помогает быстро находить сложные проблемы, и насколько труднее обходиться без него.

Статья интересна:

1. обилием реальных кейсов с использованием bcc утилит — всегда полезно увидеть, как коллеги исследуют системы с их помощью;

2. баги связанные со spinlock сложны для диагностики - создают ложное впечатление работы (высокий CPU System Time), хотя на деле система просто "активно ждет", перегружая процессор. Поэтому такие расследования всегда увлекательны.

В общем два в одном;)

tags: #cpu #troubleshooting

Kafka и медленная запись

Новая заметка по расследованию деградации записи в Kafka, с флеймграфом и флагами.

#troubleshooting #performance #linux #kafka #кейс

CPU Throttling и Runqueue

Заметка о том как выглядит троттлинг со стороны процесса в Linux и почему его стоит избегать.

——
Лайки, репосты приветствуются.

tags: #cpu #troubleshooting

Ранее я писал о баге Haproxy: после рестарта треды не завершались, что приводило к их накоплению, память иссякала и приходил OOM Killer.

Проблему решали костылем — директива hard-stop-after принудительно завершает треды после рестарта.

Но Haproxy не сдается и наносит ответный удар!

Причины еще предстоит выяснить, поэтому это скорее "заметка с полей"

Симптомы схожи: утечка памяти.

Но сбой наступает когда (это гипотеза) заканчивается память для TCP-буферов (net.ipv4.tcp_mem) - ядро с переменным успехом пытается освободить память для новых / существующих соединений, что приводит к затруднению в сетевых взаимодействиях.

На скрине такой период отмечен красным прямоугольником.

# sysctl net.ipv4.tcp_mem
net.ipv4.tcp_mem = 90435  120582  180870

Где 180870 - максимальное значение (в страницах памяти) под все TCP сокеты в системе, что равно ~ 706MB.

Оказалось, что система насыщается "повисшими" соединениями, чьи буферы сокетов содержат данные:

# ss -ntOai | awk '{for(i=1;i<=NF;i++)if($i~/^lastsnd:/){split($i,a,":");print a[2], $2, $4, $5}}' | sort -n | tail 

#lastsnd # Recv-Q #Src #Dst
234423668 157355 10.11.12.4:57354 10.11.6.123:80
235316436 302417 10.11.12.4:56232 10.11.6.124:80
238200680 301585 10.11.12.4:37940 10.11.6.124:80
238726828 300103 10.11.12.4:58944 10.11.6.124:80
243816724 297015 10.11.12.4:51700 10.11.6.125:80
251456440 302959 10.11.12.4:52324 10.11.6.125:80
252237780 302464 10.11.12.4:47786 10.11.6.123:80
257868244 163453 10.11.12.4:41568 10.11.6.125:80
259905196 300433 10.11.12.4:40202 10.11.6.123:80
261307944 214022 10.11.12.4:54888 10.11.6.123:80 # это ~ 72 часа

где:
* lastsnd - время с последней отправки данных, в милисекундах;
* Recv-Q - объем не прочитанных данных, в байтах.

А раз есть не прочитанные данные, значит таймер TCP keepalive не взводится:

static void tcp_keepalive_timer (struct timer_list *t)
{
  ...
  /* It is alive without keepalive 8) */
  if (tp->packets_out || !tcp_write_queue_empty(sk))
    goto resched;
  
  ...
  
  resched:
  inet_csk_reset_keepalive_timer (sk, elapsed);
  goto out;
  
  ...
  
  out:
    bh_unlock_sock(sk);
    sock_put(sk);
}

Был бы повод, а костыль найдется!

Ребята из CloudFlare писали в свое время статью When TCP sockets refuse to die, где в виде решения предлагалось использовать опцию сокета TCP_USER_TIMEOUT:

...it specifies the maximum amount of time in milliseconds that transmitted data may remain unacknowledged, or buffered data may remain untransmitted (due to zero window size) before TCP will forcibly close the corresponding connection and return **ETIMEDOUT** to the application...

В свою очередь Haproxy поддерживает ее через tcp-ut.

Посмотрим, как себя покажет.

tags: #tcp #linux #kernel #troubleshooting #кейс