- PVSM.RU - https://www.pvsm.ru -
Привет! На связи Наташа, UX-исследователь в Selectel [1], с технической темой на дизайнерском. Последние полгода я исследую опыт взаимодействия с серверной операционной системой. В ходе исследований мы увидели спрос на повышение производительности сетевого стека и провели некоторые эксперименты, чтобы понять реализуемость и целесообразность внедрения технологий обхода ядра. Это история о том, как мы разгоняли и без того шустрый Nginx и тестировали результат внедрения технологии kernel bypass.
Зачем вообще юиксеру лезть во что-то техническое? А затем, что самые частые пожелания к серверной ОС — это стабильность, надежность и производительность. Моя цель — превратить эти абстрактные ожидания в конкретные кейсы и UX-задачи.
Используйте навигацию, если не хотите читать текст полностью:
→ Kernel что? [2]
→ Как мы начали ускорять сетевой стек [3]
→ Как мы тестировали внедрение DPDK [4]
→ Результаты внутреннего тестирования: RPS и latency [5]
→ Вместо заключения [6]
В Unix-подобных операционных системах есть проблема производительности сетевого стека. Она связана с тем, что ядро не слишком эффективно справляется с высокой сетевой нагрузкой, то есть с передачей данных в больших объемах.
Так случилось, потому что Unix-ядро было разработано для своего времени, когда серверы в первую очередь были мощными вычислительными машинами. Сетевая нагрузка появилась позже и не сразу достигла сегодняшних объемов. Получается, ядро операционной системы задействовано в очень большом количестве процессов: сетевых, фоновых и вычислительных. Чтобы обработать сетевой трафик, ядро вынуждено прерываться, менять контекст, отвечать на системные вызовы. Это создает заторы на пути сетевых пакетов и замедляет скорость передачи данных.
Операционные системы на базе Linux получили эту проблему по наследству от Unix-ядра. Конечно, были разработаны решения для улучшения ситуации, такие как DMA [7] и NewAPI [8]. Но чтобы повысить скорость передачи данных в более заметных масштабах, применяется технология обхода ядра — kernel bypass.
Например, можно применить DPDK: добавить специальный модуль в приложение, настроить сетевой драйвер DPDK и обойти ядро. Данные будут попадать напрямую от сетевой карты в целевое приложение, не отвлекая ядро операционной системы от своих дел.
Kernel bypass на примере DPDK.
Недавно мы в Selectel презентовали собственную серверную ОС. Если вам интересны подробности, запись вебинара на эту тему доступна в Академии Selectel [9]. Здесь же я расскажу о том, что в ходе работы над ускорением сетевого стека мы применили DPDK к Nginx:
Почему первым (но не единственным) модифицированным приложением стал Nginx? Потому что наши исследования показали его высокую востребованность в серверной инфраструктуре. Конечно, Nginx и так довольно шустрый, ведь он создан решить проблему десятков тысяч соединений, но даже такую производительность удалось улучшить. Это оказалось особенно актуальным для стриминговых и веб-сервисов, которые отдают много статического контента и работают примерно по такой схеме:
Схема работы веб-сервера.
Прирост производительности позволил бы сократить качественно-количественный состав серверного железа при той же сетевой нагрузке. Например, было три дорогих мощных сервера, которые обслуживали трафик, а после модификации — два менее мощных и, соответственно, более дешевых.
Оптимизация серверной инфраструктуры за счет ускорения сетевого стека.
Проблема тестирования разработок под highload в том, что синтетически создать высокую нагрузку сложно. Особенно, когда речь идет о сравнении двух решений и нужно минимизировать рандом в нагрузке, снять «чистые» бенчмарки, замерить именно работу приложения с железом. В итоге первые тесты для ванильного и «ускоренного» Nginx мы проводили на десктопном железе.
Тестовый стенд — это две машины с десктопным железом. Одна — сервер, вторая — клиент. С клиента создается нагрузка — улетают запросы на сервер. На сервере развернут Nginx, который принимает запросы и отдает ответы. Машины подключены друг к другу через коммутатор. К коммутатору кроме тестового стенда больше ничего не было подключено, чтобы исключить погрешность сети.
Инфраструктурная схема тестового стенда.
Технические характеристики тестового «сервера» | |
NIC: | Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02) |
CPU | AMD Ryzen 9 7950 X 16-Core Processor |
Memory | 128GB |
OS | SelectOS GNU/Linux 1.0 (alpha) |
Kernel | Linux 6.1.0-22-amd64 |
Nginx version | nginx/1.25.2 |
На «клиент» поставили сетевую карту помощнее — 25 Гбит/c, а для «сервера» с Nginx — послабее, 10 Гбит/c. Мы думали, что это даст нам возможность загрузить все ядра ЦП сервера, но об этом отдельно. При этом на одном и том же «сервере» сначала тестировали ванильный Nginx, а потом заменяли его на «ускоренный», не меняя характеристики железа.
Схема тестирования Nginx.
Нагрузку задавали с помощью утилиты wrk:
Каждую из версий Nginx тестировали в двух вариантах, отправляя разный ответ:
Вот так выглядела команда утилиты wrk:
wrk -t 32 -c 1000 -d 60s http://10.10.10.10/test_small
В обоих случаях тест заключался в следующем:
Для наглядности нарисовала схему, которая показывает, как все происходило. Для каждой версии Nginx (ванильной и ускоренной) прогоняли по два варианта теста с единственной разницей в величине ответного пакета. И делали до 32 вариаций команды утилиты, добавляя количество потоков, то есть всего запускали утилиту около 100 раз.
Два вида тестирования Nginx.
Ниже сопоставлены графики роста RPS (requests per second) в зависимости от количества загружаемых потоков для четырех случаев:
Графики роста RPS/threads для четырех комбинаций тестирования Nginx.
На этих графиках мы видим, что в случае модифицированного Nginx рост RPS быстро упирается в пропускную способность сетевой карты. В зависимости от величины пакета это происходит раньше или позже. На третьем потоке — для большого ответа (красный график), на шестом потоке — для малого ответа (зеленый график). Эти точки стали для нас опорными в сравнении.
Результаты синтетического тестирования Nginx.
Синтетическое тестирование подсветило для нас следующие моменты.
Сейчас мы внедряем нашу операционную систему SelectOS [1] c модифицированным Nginx в некоторые существующие инфраструктурные решения клиентов и даем продовую нагрузку. Вот некоторые реальные запросы клиентов, которые мы хотим удовлетворить своим решением:
А какие метрики вы используете при оптимизации своей инфраструктуры? Делитесь в комментариях
Автор: Liisign
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/linux/405448
Ссылки в тексте:
[1] в Selectel: https://selectel.ru/services/selectel-os/?utm_source=habr.com&utm_medium=referral&utm_campaign=selectos_article_kernelbypass_121224_content
[2] Kernel что?: #1
[3] Как мы начали ускорять сетевой стек: #2
[4] Как мы тестировали внедрение DPDK: #3
[5] Результаты внутреннего тестирования: RPS и latency: #4
[6] Вместо заключения: #5
[7] DMA: https://ru.wikipedia.org/wiki/%25D0%259F%25D1%2580%25D1%258F%25D0%25BC%25D0%25BE%25D0%25B9_%25D0%25B4%25D0%25BE%25D1%2581%25D1%2582%25D1%2583%25D0%25BF_%25D0%25BA_%25D0%25BF%25D0%25B0%25D0%25BC%25D1%258F%25D1%2582%25D0%25B8
[8] NewAPI: https://en.wikipedia.org/wiki/New_API
[9] в Академии Selectel: https://selectel.ru/blog/events/selectos-presentation/
[10] Источник: https://habr.com/ru/companies/selectel/articles/865644/?utm_source=habrahabr&utm_medium=rss&utm_campaign=865644
Нажмите здесь для печати.