Performance matters!
Open in Telegram
Канал про SRE, Linux и производительность от Александра Лебедева (@alebsys). Разбираю сбои, ускоряю системы, делюсь опытом. 🔹 Обо мне: alebedev.tech/about 🧑💻 Менторинг: alebedev.tech/mentoring
Show more1 193
Subscribers
No data24 hours
-47 days
No data30 days
Posts Archive
1 193
Рубрика "Вредные советы" ч.2 — больше не всегда лучше.
Увеличение размера очередей - один из самых частых и эффективных советов по тюнингу, который можно услышать.
И сложно спорить, всего один параметр, а сколько пользы:
* сглаживание всплесков нагрузки;
* меньше переполнений => меньше потери данных;
* пропускная способность растет, как и эффективность обработки (пакетами, а не штуками);
* больше асинхронности, меньше боимся "морганий";
* ...
Но у любого совета, пусть и очень хорошего, всегда найдутся недостатки.
Представим два сервиса (1 и 2), взаимодействующих по сети через большую очередь, например на сетевой карте (2).
Пока (2) успевает обрабатывать поток данных, все работает гладко, с описанными выше преимуществами.
Но как только (2) замедляется на значительное время, могут возникнуть проблемы:
* latency каждого пакета в буфере растет кумулятивно, а хвосты ожидают слишком долго;
* срабатывают таймауты (на уровне приложения, TCP) и происходит переотправка, еще больше нагружая очередь;
* все накопленные данные будут обработаны (2), даже если они давно устарели;
* из-за отсутствия своевременной обратной связи TCP (1) реагирует с опозданием — отсутствует failfast;
* перегрузка накапливается в одной части системы, вместо того чтобы равномерно распределяться — отсутствует backpressure.
Список можно продолжить.
Вывод: не следует слепо следовать интернет-советам — всё нужно ставить под сомнение, проверять и подбирать оптимальные параметры именно под вашу систему.
P.S. проблеме раздутых буферов в свое время даже дали название - bufferbloat. Подробнее почитать о ней можно на www.bufferbloat.net.
tags: #network #tcp #theory
1 193
The Art of System Debugging — Decoding CPU Utilization
Или как баг в Java вызвал перегрузку CPU из-за избыточного чтения
cgroupfs.
Заметка показывает, как eBPF помогает быстро находить сложные проблемы, и насколько труднее обходиться без него.
Статья интересна:
1. обилием реальных кейсов с использованием bcc утилит — всегда полезно увидеть, как коллеги исследуют системы с их помощью;
2. баги связанные со spinlock сложны для диагностики - создают ложное впечатление работы (высокий CPU System Time), хотя на деле система просто "активно ждет", перегружая процессор. Поэтому такие расследования всегда увлекательны.
В общем два в одном;)
tags: #cpu #troubleshooting1 193
🔥 Топовые инженеры в сферах SRE, производительности и Linux, на которых стоит подписаться (Linkedin)
👉 Mark Dawson, Jr.
Ведет активную деятельность как на LinkedIn, так и в своем блоге. Море "deep dive" по устройству Linux, его взаимодействию с вычислительными ресурсами и тому, как это влияет на производительность приложений.
👉 Tanel Poder
Создатель 0xtools (утилиты для траблшутинга), частый гость P99CONF и автор множества статей в блоге о Linux и поиске проблем в системах.
👉 Jose Fernandez
Двигает тему eBPF в Netflix, разрабатывая утилиты для повышения наблюдаемости и надежности систем. Активно делится своим опытом с сообществом.
👉 Viacheslav Biriukov
В бытность Яндекса читал лекции в КИТ, а позже завел блог, где простыми словами рассказывает про внутреннее устройство Unix-систем. Супер познавательно!
🎯 Бонус трек — @bobrik (github)
Создатель ebpf_exporter и активный контрибьютер в популярные open-source решения. Его код полезно и интересно читать. А еще ведет страничку в Mastodon про eBPF, Linux и все вокруг.
💬 А кто у вас в подписках?
1 193
Рубрика "Вредные советы" ч.1 — асинхронность в Nginx
В интернетах вращается множество статей из разряда "Top Five Tips for <Твоя технология> in 2024", обещающих повысить, ускорить, оптимизировать.
Подобные гайды передаются из уст в уста и заботливо копируются в инфраструктуры, ведь "на прошлом месте работы это помогло!".
И не важно, что это было в 2012 году, на версии Linux kernel 2.4.x, в другом стеке и вообще не у меня, а у знакомого :)
Такой вот cargo cult.
С другой стороны, чем я хуже? У меня тоже есть парочка советов 😁
—————————————————————————————————
Nginx под капотом использует event‑driven архитектуру. Это когда у воркера есть очередь с ивентами, которую он последовательно "перемалывает".
И чем дольше занимает обработка события (например, чтение с диска), тем дольше ждут остальные в очереди.
Одно из решений — асинхронная обработка событий.
И у Nginx есть что предложить по опциям:
aio threads;
aio_write on;ngx_process_events_and_timers (ссылка) — сколько времени уходит на обработку ивента.
1. Без внедрения aio
# funclatency-bpfcc /usr/sbin/nginx:ngx_process_events_and_timers -m -d 100
Function = b'ngx_process_events_and_timers' [147018]
msecs : count distribution
0 -> 1 : 60492 |********************************|
2 -> 3 : 5567 |*** |
4 -> 7 : 3937 |** |
8 -> 15 : 1899 |* |
16 -> 31 : 429 | |
...
avg = 27 msecs, total: 3797767 msecs, count: 136964
2. С aio:
# funclatency-bpfcc /usr/sbin/nginx:ngx_process_events_and_timers -m -d 100
Function = b'ngx_process_events_and_timers' [146165]
msecs : count distribution
0 -> 1 : 103291 |*******************************|
2 -> 3 : 2581 | |
4 -> 7 : 1962 | |
8 -> 15 : 1757 | |
16 -> 31 : 0 | |
32 -> 63 : 374 | |
64 -> 127 : 49 | |
...
avg = 10 msecs, total: 3534364 msecs, count: 342992
Гистограмма показывает значительное сокращение задержек тяжелых операций, а среднее время обработки снизилось почти втрое. Неплохо!
—————————————————————————————————
P.S. Использовать на свой страх и риск, с предварительной проверкой на своей рабочей нагрузке!
Удачи!1 193
+6
💥 Выступил на perfconf#10 с неделю назад💥
C докладом:
"Когда код идеален, но система тормозит. Скрытые враги производительности"
(немного пафосно звучит, но что поделать😉)
Рассказывал почтенной публике о влиянии TCP Retransmits и CPU Throttling на производительность приложений — как, зачем и что с этим делать.
Такой ликбез с небольшим deep dive в нюансы.
По ощущениям получилось вполне неплохо, и думаю, стоит повторять такие упражнения в будущем😊
По традиции — спасибо всем причастным! 🙌
P.S. Несколько фото и презентация прилагаются 📸💻
tags: #tcp #cpu
1 193
В свое время читал статью 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.0reuseport (см. документацию), выключенная по умолчанию.
А вот в 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
1 193
performance_tuning_tutorial with
perf
Часто использую perf, чтобы понять, на что уходит CPU time через perf top или для генерации FlameGraph, когда установка eBPF утилит затруднена.
Инструмент — настоящий швейцарский нож для исследования производительности Linux-систем.
Так что, туториал, кстати.1 193
All you need to know about timeouts
Собирал информацию по лучшим практикам вокруг выставления таймаутов и наткнулся на любопытную заметку от Zalando, где обсуждается:
* как подобрать оптимальные значения таймаутов;
* взаимосвязь таймаутов и ретраев;
* как не похоронить свои системы под лавиной ретраев.
Краткая выжимка:
* set timeout explicitly on any remote calls * set connection timeout = expected RTT * 3 * set request timeout based on collected metrics and SLA * fail-fast or return a fallback value * consider wrapping chained calls into time limiter * retry on 5xx error and do not retry on 4xx * think about implementing a circuit breaker when retrying * be polite and ask the API owner for permission to enable retries * support Idempotency-Key header in your API—— Для тех, кто захочет чуть углубиться в тематику еще немного ссылок: 1. Xороший ретрай, плохой ретрай, или История одного падения - лонг рид от Яндекс про ретраи, очень подробно и с картинками; 2. Understanding Fail-Safe and Fail-Fast Strategies - сравнение стратегий и как их использовать в реальных системах; 3. What is Backoff For? - про бекофы и когда они могут помочь, а когда нет (кстати отличный блог!).
1 193
Новая статья в блог bash: curl: command not found" или как траблшутить контейнеры когда нечем.
Несколько способов запуска команд в контейнерах, когда утилиты не установлены.
1 193
What every SRE should know about GNU/Linux resolvers and Dual-Stack applications
С Viacheslav Biriukov познакомился по лекциям на Яндекс КИТ, когда еще только начинал узнавать, что такое Linux.
Тогда еще подумал "вау, вот это уровень, хочу так же!" :)
В последствии Вячеслав завел блог https://biriukov.dev/, где опубликовал мини книгу про Linux Page Cache (куча практических знаний как работает виртуальная память и чем на нее можно повлиять), а так же начал серию серий постов с говорящим названием "What every SRE should know about ...":
- первый заход был про файловые дескриторы, пайпы, терминалы, процессы и тд;
- а теперь подъехала и совсем свежая What every SRE should know about GNU/Linux resolvers and Dual-Stack applications про процесс резолвинга.
Must read, как говорится!
1 193
SadServers №15 | Middle-level | Tokyo
Траблшутинг в ленту!
Tokyo - пятнадцатая задача среднего (middle) уровня на sadservers.com:
- изучим состояние сокетов через ss;
- посмотрим на ретрансмиты в tcpdump;
- поправив правила netfilter (iptables);
- и наконец приведем в чувства webserver.
#sadservers #linux #devops #troubleshooting #sre #tcpdump
1 193
TCP Congestion Control в разных окружениях
Написал заметку как влияет потеря сетевых пакетов на пропускную способность TCP соединения.
p.s. катастрофически.
tags: #linux #tcp #performance
1 193
Есть такой ресурс sadservers.com, позиционирует себя как «leetcode для linux”.
На нём собраны задачки разной степени сложности из разряда «процесс PostgreSQL перестал работать, найди причину и устрани».
Подобное может встречаться на секциях технических собесов, что добавляет полезности, да и просто интересно проверить свои навыки.
В качестве пробы пера записал видео с прохождением первой задачи с небольшими теоретическими отступлениями.
1 193
An introduction to benchmarks
Ликбез от Matt Fleming по бенчаркингу. В краткой форме освещается:
* зачем нужен бенчмаркинг;
* какие типы бывают;
* и когда их стоит использовать в разработке ПО.
1 193
Написал в блог заметку о методологии "Thread State Analysis" (TSA).
Это когда о поведении системы судят по тому, в каком состоянии (state) пребывают её потоки: running, sleep, stopped и т.д.
TSA, как и другие высокоуровневые методологии (USE, RED), может помочь сориентироваться, определить направления для дальнейшего анализа и сократить общее время устранения проблем.
tags: #methodology #linux #troubleshooting
1 193
About Pool Sizing
Заметка из wiki HikariCP про установку "правильного" размера пула коннектов к базам данных.
Основные мысли
1. Последовательное исполнение на одном CPU двух тредов всегда быстрее "параллельного" (потери на context-swithing и cache miss).
2. БОльшее кол-во тредов нежели доступных CPU ведет к замедлению системы (при идеальной CPU-bound модели использования);
3. Как только в уравнение добавляются IO-операции (диск, сеть, memory), правило меняется - чем дольше треды способны находиться в заблокированном состоянии (IO-wait), тем бОльший пул коннектов следует выставлять;
Сообщество PostgreSQL ввело в оборот формулу:
connections = ((core_count * 2) + effective_spindle_count)
* core_count должен учитывать только физически ядра (никакого вам HT);
* effective_spindle_count равен 0 если вся БД способна поместиться в кеш и приближается к фактическому кол-ву дисков по мере снижения cache hit rate.
Axiom: You want a small pool, saturated with threads waiting for connections.
P.S. думаю, что подход выше будет справедлив для всех типов коммунальных ресурсов.
tags: #performance #reliability1 193
Memory Soft limits
Опубликовал в блоге заметку-исследование механизма cgroup Memory Soft Limits, он же
memory.soft_limit_in_bytes.
Позапускал контейнеры в разных вариациях и наблюдал как настройка влияет на распределение памяти при нехватки оной на машине.
Выглядит как CPU throttling, но конечно есть нюансы.1 193
Сложные системы тяготеют к отказам.
Отказы такое же свойство систем, как надёжность, наблюдаемость, масштабируемость и т. д.
Работа Richard I. Cook How Complex Systems Fail освещает:
- природу отказов;
- двойственную роль оператора системы - как защитник от хаоса, так и непосредственно причина его появления;
- заблуждения пост-анализа инцидентов - всегда есть совокупность причин, пост-знание всегда предвзято;
- отказы как следствие возрастания сложности систем.
Полезное чтение для построения причинно-следственных связей.
tags: #reliability #sre_theory
1 193
Let's talk about resources isolation
Ветка на форуме proxmox, где топик-стартер подсвечивает недостатки существующих инструментов изоляции ресурсов в proxmox.
В частности отсутствие функционала "из коробки":
- vCPU pinning, что прямо или косвенно приводит к излишнему context-switching и L3 cache промахам;
- SMP-aware pinning - два логических ядра не всегда равны двум физическим (hyper threading) и при планировании тредов на процессор хорошо бы учитывать chiplets - задержка доступа к кешу между соседними ядрами может различаться в разы.
Автор подсвечивает пять уровней изоляции ресурсов виртуальной машины на гипервизоре и как их можно достичь:
1. CPU pinning тредов VM;
2. Освобождение vCPU от обработки IRQ;
3. Изоляция VM от userspace процессов гипервизора;
4. Изоляция VM от kernelspace процессов гипервизора;
5. Изоляция VM от других VM на гипервизоре (cgroups).
---
Тред пригодится в борьбе за производительность CPU-bound приложений в виртуальных окружениях.
#virualization #proxmox #linux #performance
