Optimizing web servers for high throughput and low latency by Dropbox.tech

Разбор всех компонентов Linux машины участвующих в обработке трафика и методы оптимизаций их производительности, от типов CPU и до алгоритмов сжатия.

tags: #linux #performance #network #tuning

CPU Utilization is Wrong by Brendan Gregg

B. Gregg показывает почему метрика утилизации %CPU может вводить в заблуждение - она включает в себя не только время затраченное на полезную работу CPU, но и ожидание обращения к памяти.

Как решение предлагается ориентироваться на показатель IPC (instructions per cycle), доступный в perf stat, atop, perf коллектор в node_exporter, etc.

tags: #linux #performance #metrics #cpu

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

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

tags: #network #linux #troubleshooting #tooling

TCP Puzzlers by Dave Pacheco

Исследуется поведение TCP протокола в ситуациях как нормального закрытия соединений так и при:

* отключение питания сервера
* перезагрузка сервера
* внештатный обрыв соединения.

Авто подсвечивает не совсем очевидные моменты, о которых хорошо бы знать.

tags: #tcp #network

CPU pinning та тема о которой постоянно слышу, но разобраться в деталях еще не привелось.

Это странно, потому как применение подхода в нужном месте в нужное время способно принести пользу, навскидку:

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

На днях вдохновлялся статьей Predictive CPU isolation of containers at Netflix, где ребята борются с проблемой “шумного соседа” используя ML - прогнозируют тип workload’а и выставляют контейнеру подходящие параметры на старте: использовать ли CPU pinning, на какой NUMA Ноде стоит планироваться, чтобы не аффектить соседей и тому подобное.

Далее гугл подбросил ссылку на white paper The Art of CPU-Pinning. Авторы провели ресерч для каких типов нагрузок (CPU bound / IO bound) в каких окружениях (Bare-metal, VM, container on VM, container on Baremetal) как влияет CPU pinning.

Нашел себе чтение на ближайшие дни.

Написал заметку как сеть в Kubernetes может обманывать при учете объемов трафика. Не без помощи ebpf.

https://alebsys.github.io/posts/metallb-calico-ebpf/

#kubernetes #calico #ebpf #metallb #linux

How does hyperthreading work

Статья от performance engineer Peter Veentjer о технологии Hyper-Threading:

- архитектура CPU: frontend, backend, superscalar, pipelines, ...;
- за счет чего возможно использовать одно ядро для нескольких потоков;
- почему Hyper-Threading это не про быструю смену контекста.

Кстати, Peter является соавтором Performance Analysis and Tuning on Modern CPUs от Denis Bakhvalov.

#CPU #HT #performance

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 #tuning

Сложные системы тяготеют к отказам.

Отказы такое же свойство систем, как надёжность, наблюдаемость, масштабируемость и т. д.

Работа Richard I. Cook How Complex Systems Fail освещает:

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


Полезное чтение для построения причинно-следственных связей.

tags: #reliability #sre_theory

Memory Soft limits

Опубликовал в блоге заметку-исследование механизма cgroup Memory Soft Limits, он же memory.soft_limit_in_bytes.

Позапускал контейнеры в разных вариациях и наблюдал как настройка влияет на распределение памяти при нехватки оной на машине.

Выглядит как CPU throttling, но конечно есть нюансы.

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 #reliability

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

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

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

tags: #methodology #linux #troubleshooting

An introduction to benchmarks

Ликбез от Matt Fleming по бенчаркингу. В краткой форме освещается:

* зачем нужен бенчмаркинг;
* какие типы бывают;
* и когда их стоит использовать в разработке ПО.

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

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

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

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

TCP Congestion Control в разных окружениях

Написал заметку как влияет потеря сетевых пакетов на пропускную способность TCP соединения.

p.s. катастрофически.

tags: #linux #tcp #performance

SadServers №15 | Middle-level | Tokyo

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

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

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

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, как говорится!

Новая статья в блог bash: curl: command not found" или как траблшутить контейнеры когда нечем.

Несколько способов запуска команд в контейнерах, когда утилиты не установлены.

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? - про бекофы и когда они могут помочь, а когда нет (кстати отличный блог!).

performance_tuning_tutorial with perf

Часто использую perf, чтобы понять, на что уходит CPU time через perf top или для генерации FlameGraph, когда установка eBPF утилит затруднена.

Инструмент — настоящий швейцарский нож для исследования производительности Linux-систем.

Так что, туториал, кстати.