Саша пытается в SRE

Это я и мои кварталки #memes

Доброе утро #morning

Кстати, вот как выглядят ретрансы ха-ха трансы. Значений выше >0.1 во внутренней инфраструктуре примерно никогда не увидишь, а тут у нас такое.

Собсна, если это действительно происходит, то команде SRE предстоит либо ебля с параметрами ядра, либо скалирование кол-ва виртуалок в DMZ для распределения нагрузки. Об этом история умалчивает, потому что коллеги пока не приступили ни к тому ни к другому, но для своих читателей я, конечно же, оставлю материалов по этой теме: • https://github.com/SergiyBabenkov/linux-network-buffer-tuning • https://itnext.io/maximizing-tcp-throughput-in-linux-understanding-and-tuning-send-and-receive-buffers-92df654c415f Печально, что с моим переходом на тимлидскую позицию я всё реже стал заниматься такими интересными вещами. #network #sre #troubleshooting #кулстори #nginx #highload

Повесть о response_time > 1 секунды... ...или история о том, как я раскурил почему у нас веб тормозит. Присаживайтесь поудобнее. Одним прекрасным днем коллеги из Т-Авто пожаловались на неприятно высокие метрики загрузки страниц на вебе по телеметрии NGINX... Справедливости ради, эти метрики строились на nginx-prometheus-exporter. Хочу заметить, что это один из худших экспортеров в индустрии, потому что он не предоставляет абсолютно никакой детализации происходящего. То есть если у условных HAProxy или Envoy потрясающая телеметрия, то NGINX невероятным образом отстал в развитии. Возможно, что спустя пять лет после моей последней вменяемой настройки этого балансировщика что-то и поменялось, но я крайне сомневаюсь. Хотя бы по той причине, что в Envoy калькуляция метрик заложена прямо в дизайн, а в NGINX прилеплено как "сбоку припека". ...и это довольно важное лирическое отступление, потому что по метрики NGINX, из-за свойств своего экспорера, рисовали ну просто какой-то космический latency (в районе 8-10 секунд в 95-ом перцентиле), который никак не метчился ни с экспериментальными тестами, но с данными по логам тех же запросов. Почти что какой-то random walk, но в то же время сигнализирующий о проблеме. — По метрикам стало бесполезно разбираться, поэтому погрузился в логи — большое спасибо ребятам из веба за настройку модуля nginx-module-vts. Модуль позволяет проливать прямо в логи запросов метрики upstream_response_time_sec, upstream_connect_time_sec и upstream_header_receive_time_sec, что должно было позволить локализовать проблему. Запросов много, так что сразу фильтрую по медленным запросам. Спойлер: запросы по 8-10 секунд я НЕ нахожу, поэтому продолжаю понижать трешхолд. Вижу немного запросов > 2-3 секунд, но самый большой перцентаж медленных запросов попадает в диапазон ~1 секунды. При этом, смотрим детальнее: • upstream_connect_time_sec - в большинстве случаев > 1 секунды • дельта между upstream_header_receive_time_sec и upstream_connect_time_sec — минимальная (!) — то есть бек всегда отвечает почти моментально! В конфиге NGINX параметр connect_timeout выставлен в 2s, я заранее проверил. То есть это сразу наводит на мысль о каких-то проблемах с установкой коннекта. — Далее, я обращаю внимание на то, что 1 секунда — это дефолтный TCP-таймаут для переотправки потерянного SYN-пакета (бекофф идет по 1s → 2s → 4s → ...), согласно RFC6298. При некоторых параметрах ядра он может быть 200ms, но у нас, скорее всего, он такой и есть. Ну а дальше у меня возникает вполне логичная мысль: а не проверить ли нам метрики node-exporter тех самых тачек NGINX, где вполне резонно могут возникать TCP-таймауты? Пытаюсь найти нужные дашборды у команды веба — не нахожу. Модифицирую свои, вывожу метрики. Сразу листаю к секции Network и смотрю ретрансмитты пакетов, и их там туева гора. В здоровой системе ретрансмиттов TCP-пакетов возникать практически не должно, но если у вас хайлоад, то смотреть на их появление вполне резонно, потому что это явный звоночек либо на то, что у вас нестабильная сеть, либо на то что вы не перевариваете сетевую нагрузку. — К сожалению, тут мое расследование заканчивается на том, что я репорчу проблему команде SRE веб-сервисов, потому что у меня "не дотягиваются ручки" до виртуалок с NGINX, чтобы запустить там sar, netstat, ethtool или другие утилиты для инструментирования сетевого стека. Единственная гипотеза заключается в том, что на нодах происходит перегрузка входящих/исходящих буфферов — ситуация вполне себе ожидаемая, учитывая то какая у нас нагрузка на вебе www.tbank.ru и примыкающих к нему сервисах.

Доброе утро #morning #memes

#durka

Доброе утро Всем хорошей недели И не спрашивайте почему у меня утро начинается в обед)) #morning

#sre #memes

Доброе утро Всем хороших выходных #morning

Нагоняю аудиторию для Ани, чтоб не втыкала))

Митап для томских QA-инженеров и тестировщиков В программе 2 доклада и нетворкинг: 🔵Анна Торгунакова, Т-Банк: «QA как драйвер производительности: от нагрузочного тестирования до оптимизации кода» 🔵Евгений Деркач, ИнфоТеКС: «Манифест осознанной рутины: 6 шагов к устойчивому QA» 🕥Когда: 30 июня, 19:00 Тск 📍Где: ул. Советская 78, 4 этаж (БЦ «The Елань») Регистрация и подробная программа: https://l.tbank.ru/tqa3006

#durka

Доброе утро #morning

#cheburnet #memes

Каждый раз перекрещиваюсь, когда собираюсь новый мем про VPN запостить #cheburnet #durka

Доброе утро #morning

#memes

Простите)) #memes

Доброе утро #morning