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

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

tags: #linux #performance #network #tuning

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

Scaling in the Linux Networking Stack (scaling.txt)

Документ от разработчиков ядра Linux описывает пять техник, которые помогают повысить производительность сетевого стека в многоядерных системах.

Это:
* RSS: Receive Side Scaling
* RPS: Receive Packet Steering
* RFS: Receive Flow Steering
* Accelerated Receive Flow Steering
* XPS: Transmit Packet Steering

В нашей инфраструктуре мы уже давно и успешно используем RSS.

Это аппаратная технология, суть следующая.

Когда поступает сетевой пакет, на основе его заголовков вычисляется хеш. Полученное значение сопоставляется с таблицей, где каждому значению соответствует определенная очередь (RX).

Каждая RX-очередь привязана к конкретному ядру процессора.

Таким образом:
1. Обработка трафика распределяется между несколькими CPU, что позволяет эффективно использовать ресурсы;
2. Все пакеты одного соединения попадают в одну очередь. Это исключает проблему "out of order" пакетов.

Однако бывают ситуации, когда распределить обработку трафика между ядрами не получается, и отдельное ядро или группа ядер оказывается сильно перегруженной:

- одно конкретное соединение прокачивает кратно больший объем трафика, чем другие;
- RX-очередей в системе меньше, чем доступных CPU.

Мы, например, сталкивались с такими проблемами при использовании MetalLB в L2-режиме: весь трафик шел через одну машину MetalLB (мастер) и "приклеивался" к одной RX-очереди на Ingress Controller. Остальные ядра и RX-очереди при этом простаивали.

В подобных случаях может помочь другая техника, описанная в том же документе — RPS (Receive Packet Steering).

RPS — это программная реализация RSS. Она позволяет распределить RX-очереди по конкретным ядрам, выравнивая нагрузку между ними.

Но есть и минусы:
- Программная реализация создает дополнительную нагрузку на CPU, что проявляется в увеличении числа IRQ на графике загрузки процессора;
- Снижается "локальность" данных в кэшах процессора, что может повлиять на производительность.

(на скрине RPS включили после 16:00)

———

Тема сложная, и я не уверен, что до конца понимаю, как это все работает;)
Было бы интересно узнать, какие техники масштабирования трафика используете вы и как справляетесь с подобными проблемами.

Дальнейшее чтение:
- сам документ scaling.txt
- расшифровка доклада от Одноклассников, где ребята решали похожие проблемы;
- примерно тоже самое, но забугорный доклад по перформансу сетевого стека.

tags: #network #tuning #linux #кейс

Из серии "Смотрите что нашел!"

Low latency tuning guide - сборник техник по оптимизации системы для минимизации задержек.

Внутри как привычные подходы вроде изоляции ядер и отключения гиперпоточности, так и совсем для меня новые:

- сокращение прерываний таймера планировщика через nohz_full, что будет снижать накладные расходы на context swithing.
- закрепление страниц в RAM с помощью mlockall(MCL_CURRENT | MCL_FUTURE), чтобы избежать их выгрузки на диск.

Особую ценность добавляет обилие ссылок для более глубокого погружения в предмет.

Упражнение: задавать себе вопросы из разряда: "Для low latency советуют SCHED_RR и SCHED_FIFO, а что если важнее пропускная способность? Как бы я изменил подход? Почему?"

#kernel #tuning #low_latency