Заглавный пост. TODO

TCP Retransmission May Be Misleading (2023) by Arthur Chiao

Про типы TCP ретрансмитов в linux, как наблюдать и влиять на них.

tags: #linux #network #tcp

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