io_uring против epoll в KVM: сервер с большим числом соединений
Тест io_uring против epoll в KVM проводят на одной кодовой базе. Бенчмарк io_uring при множестве соединений корректен, если меняется только бэкенд событий. Итог зависит от ядра, цикла событий, протокола, режима io_uring и offload.
Когда io_uring обгоняет epoll на сетевом сервере?
io_uring обгоняет epoll, когда сервер пакетно отправляет операции и обрабатывает завершения, сокращая число переходов в ядро. Такой выигрыш обычно виден при множестве одновременных соединений и малом объёме работы на запрос. Простая замена epoll-уведомлений на io_uring poll может не окупить сложность.
Что обязано остаться неизменным между epoll и io_uring
Чтобы бенчмарк io_uring при множестве соединений был честным, обе ветки используют общий парсер, обработчик, TLS-режим, keep-alive и формат ответа. Сверяют чтения, записи и аллокации на запрос. Поэтому демонстрационный пример не сравнивают со зрелым сервером.
Готовность fd против очередей submission и completion
epoll сообщает о готовности fd, а приложение выполняет I/O. В io_uring приложение отправляет SQE в submission queue, а ядро записывает CQE. Пакетная отправка сокращает переходы в ядро, но неудачный цикл событий сводит выигрыш к нулю. Поэтому масштабирование epoll в KVM проверяют на том же профиле нагрузки.
Где KVM и virtio могут скрыть разницу бэкендов
Пакет идёт через сетевой стек гостя, очереди vhost-net и тракт хоста. До теста фиксируют число очередей, offload, привязку vCPU и IRQ. Иначе задержка сетевого сервера io_uring объясняется хостом, а не бэкендом.
Какой тест позволяет честно сравнить эти модели?
Используйте один код сервера, протокол, объём работы на запрос и правила соединений, меняя только бэкенд событий. После прогрева запускайте серии с одинаковым CPU-бюджетом на каждой ступени concurrency. Публикуйте пропускную способность, p99, число системных вызовов, ошибки и загрузку гостя и хоста отдельно.
Соединения, запросы и backpressure без скрытых различий
Задайте размеры запросов и ответов, долю новых соединений и keep-alive. Повышайте concurrency до насыщения, следя за ошибками, таймаутами и очередью. Накладные расходы цикла событий оценивайте по CPU на запрос и числу системных вызовов, сопоставляя их с p99 и пропускной способностью.
Syscalls, переключения контекста и CPU на запрос
Счётчики cycles, instructions и context-switches делят на число запросов. Отдельно измеряют расход CPU рабочими и vhost-потоками. Многократный accept в io_uring снижает число постановок accept, но каждый CQE нужно обработать. К отчёту прикладывают коммит, конфиги бэкендов, генератор и сырой CSV.
Где преимущество появляется и где исчезает
Сравните низкую нагрузку, рабочую точку и перегрузку. Проверьте мелкие и крупные сообщения. Сохраняйте p50, p99, пропускную способность, соединения в секунду и разброс повторов. Если разбросы перекрываются, не выбирайте победителя.
Какие накладные расходы добавляет KVM?
Часть ожидания vCPU отражается в %steal, остальные паузы видны только на хосте.
Очереди гостя, vhost и NIC хоста могут накапливать пакеты независимо от бэкенда.
IRQ, softirq и offload влияют на расход CPU, поэтому настройки фиксируют до теста.
Как найти источник p99 внутри ring или цикла событий
При росте p99 трассируют SQ/CQ, обработку CQE и паузы рабочих потоков. Проверяют переполнение ring, незавершённые операции и backpressure. Если хвостовая латентность растёт вместе с паузами vCPU, сначала проверяют хост.
Когда выигрыш оправдывает новый бэкенд
До перехода фиксируют версию ядра, поддержку отмены, наблюдаемость и fallback. Настройки virtio не меняют, иначе выигрыш не отнести к бэкенду. Порог связывают с целевой метрикой и ценой сопровождения. Новый бэкенд включают поэтапно, с откатом на epoll.
io_uring против epoll в KVM выбирают не по новизне API. Переход оправдан, если серии дают выигрыш по p99, пропускной способности или CPU на запрос, а поведение при перегрузке и fallback предсказуемо. Иначе epoll остаётся более простым бэкендом.
