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

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

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

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

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

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

tags: #linux #tcp #performance

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

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

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

Об IPC
(конспект по книге Performance Analysis and Tuning on Modern CPUs)

Я уже писал о показателе Instructions Per Cycle (IPC) (например тут и тут). Сейчас разберём детали глубже.

Instruction Per Cycle (IPC) — это среднее количество инструкций, завершённых за один такт процессора:

IPC = Retired Instructions / Core Cycles

Определим ключевые понятия.

Инструкции делятся на executed и retired.

- Executed инструкции уже выполнены, но результат ещё не записан в память. Они могут выполняться вне порядка (out of order) и быть отменены, например, из-за miss branch prediction;

- Retired инструкции полностью завершены, то есть и выполнены и их результаты записаны (committed). Отменить их уже нельзя.

Executed напрямую не отслеживаются, а для retired есть отдельный счётчик:

perf stat -e instructions -- ./a.exe

2173414 instructions # 0.80 insn per cycle

Cycles (циклы) процессора бывают двух видов:
- core;
- reference.

Разница важна при динамическом изменении частоты процессора:
1. если CPU работает на штатной частоте: core = reference.
2. если CPU разогнан: core > reference.

Core Cycles отражают реальную текущую, когда Reference Cycles базовую (по паспорту) частоту процессора.

perf stat -e cycles,ref-cycles -- ./a.exe

43340884632 cycles # 3.97 GHz <= Core Cycles
37028245322 ref-cycles # 3.39 GHz <= Reference Cycles

Следовательно IPC показывает единицу A) выполненной B) полезной работы в текущий момент.

IPC не зависит от изменения тактовой частоты, так как всегда рассчитывается на один цикл.

Факторы, ограничивающие IPC
(перечислены в случайном порядке, список неполный):

- скорость памяти и cache misses;
- архитектура процессора: скалярность, загрузка слотов пайплайна;
- тип и сложность инструкций;
- branch misprediction (пенальти на ошибку по 10–25 ns);
- ...

Скалярность ограничивает количество инструкций, которые процессор может обработать за один такт, и задаёт теоретический максимум IPC.

На практике этот максимум недостижим: процессор может одновременно выполнять только определённые типы инструкций. Например, в 6-wide архитектуре за такт можно провести четыре операции сложения/вычитания, одну загрузку и одну запись, но не шесть загрузок одновременно.

to be continued...

#cpu #theory