Рубрика «epoll»

Введение

Совсем недавно, 25 января 2022 года вышел новый релиз Nginx - 1.21.6, в котором исправлена проблема неравномерного распределения входящих соединений между несколькими worker процессами в дефолтной конфигурации на Linux системах. Если конкретнее - use epoll, accept_mutex off, reuseport выключен.

В данной конфигурации при определенном характере нагрузки большинство входящих в Nginx соединений обрабатывается лишь одним worker процессом. 

Читать полностью »

Это — последний материал из серии четырёх статей (часть 1, часть 2, часть 3), посвящённой реализации epoll. Тут речь пойдёт о том, как epoll передаёт события из пространства ядра в пользовательское пространство, и о том, как реализованы режимы срабатывания по фронту и по уровню.

Реализация epoll, часть 4 - 1

Эта статья написана позже остальных. Когда я начинал работу над первым материалом, самой свежей стабильной версией ядра Linux была 3.16.1. А во время написания данной статьи это уже версия 4.1. Именно на коде этой версии ядра и основана данная статья. Код, правда, изменился не особенно сильно, поэтому читатели предыдущих статей могут не беспокоиться о том, что что-то в реализации epoll очень сильно изменилось.
Читать полностью »

В предыдущих двух материалах (часть 1, часть 2) этой серии речь шла об общих вопросах работы epoll, и о том, как epoll получает уведомления о новых событиях от файловых дескрипторов, за которыми наблюдает. Здесь я расскажу о том, как epoll хранит уведомления о событиях, и о том, как эти уведомления получают приложения, работающие в пользовательском режиме.

Реализация epoll, часть 3 - 1
Читать полностью »

Сегодня мы публикуем перевод первой статьи из серии материалов, посвящённых реализации epoll в ядре Linux 3.16.1*. Автор исходит из предположения о том, что читатели знакомы с API и с использованием epoll. Он уделяет основное внимание реализации подсистемы epoll в ядре Linux, а не особенностям её применения. Если вы не знаете о том, как пользоваться epoll — автор рекомендует сначала почитать документацию. Это значительно облегчит понимание деталей реализации этого механизма.

Реализация epoll, часть 1 - 1

* — Linux 3.16.1 достаточно старое ядро, но информация работы с epoll актуальна и сегодня (прим. переводчика).
Читать полностью »

Полнофункциональный I-O реактор на голом Си - 1

Введение

I/O реактор (однопоточный цикл событий) — это паттерн для написания высоконагруженного ПО, используемый во многих популярных решениях:

В данной статье мы рассмотрим подноготную I/O реактора и принцип его работы, напишем реализацию на меньше, чем 200 строк кода и заставим простой HTTP сервер обрабатывать свыше 40 миллионов запросов/мин.

Читать полностью »

io_submit: альтернатива epoll, о которой вы никогда не слышали - 1

Недавно внимание автора привлекла статья на LWN о новом интерфейсе ядра для опроса (polling). В ней обсуждается новый механизм опроса в Linux AIO API (интерфейс для асинхронной работы с файлами), который добавили в ядро версии 4.18. Идея довольно интересная: автор патча предлагает использовать Linux AIO API для работы с сетью.

Но постойте! Ведь Linux AIO был создан для работы с асинхронным вводом-выводом с диска / на диск! Файлы на диске — это не то же самое, что сетевые соединения. Возможно ли вообще использовать Linux AIO API для работы с сетью?

Оказывается, да, возможно! В этой статье объясняется, как использовать сильные стороны Linux AIO API для создания более быстрых и лучших сетевых серверов.

Но давайте начнём с разъяснения, что представляет собой Linux AIO.
Читать полностью »

Ну или почти вся...

Вся правда о linux epoll - 1

Я считаю, что проблема в современном интернете — это переизбыток информации разного качества. Найти материал по интересующей теме не проблема, проблема отличить хороший материал от плохого, если у вас мало опыта в данной области. Я наблюдаю картину, когда очень много обзорной информации "по верхам" (практически на уровне простого перечисления), очень мало углубленных статей и совсем нет переходных статей от простого к сложному. Тем не менее именно знание особенностей того или иного механизма и позволяет нам сделать осознанный выбор при разработке.

В статье я постараюсь раскрыть то, что является фундаментальным отличием epoll от других механизмов, то что делает его уникальным, а так же привести статьи, которые просто необходимо прочитать для более глубокого осмысления возможностей и проблем epoll.

Anyone can wield an axe, but it takes a true warrior to make it sing melees melody.

Я предполагаю, что читатель знаком с epoll, по крайней мере прочел страницу man. О epoll, poll, select написано достаточно много, чтобы каждый кто разрабатывал под Linux, хоть раз о нем слышал.

Читать полностью »

Введение

В этой статье мы попробуем разобраться чем на практике отличается механизм epoll от портов завершения (Windows I/O Completion Port или IOCP). Это может быть интересно системным архитекторам, проектирующим высокопроизводительные сетевые сервисы или программистам, портирующим сетевой код с Windows на Linux или наоборот.

Обе эти технологии весьма эффективны для обработки большого количества сетевых соединений.

Они отличаются от других методов по следующим пунктам:

  • Нет ограничений (кроме общих ресурсов системы) на общее количество наблюдаемых дескрипторов и типов событий
  • Масштабирование работает достаточно хорошо — если вы уже мониторите N дескрипторов, то переход к мониторингу N + 1 займёт очень мало времени и ресурсов
  • Достаточно легко задействовать пул потоков для параллельной обработки происходящих событий
  • Нет никакого смысла использовать при единичных сетевых соединениях. Все преимущества начинают проявляться при 1000+ соединений

Если перефразировать всё вышесказанное, обе данные технологии созданы для разработки сетевых сервисов, обрабатывающих множество входящих соединений от клиентов. Но в то же время между ними есть существенная разница и при разработке тех же сервисов её важно знать.
Читать полностью »

При проектировании высокопроизводительных сетевых приложения с неблокирующими сокетами важно решить, какой именно метод мониторинга сетевых событий мы будем использовать. Их есть несколько и каждый хорош и плох по-своему. Выбор правильного метода может быть критически важной вещью для архитектуры вашего приложения.

В этой статье мы рассмотрим:

  • select()
  • poll()
  • epoll()
  • libevent

Читать полностью »

Метод масштабирования TCP-серверов, как правило, очевиден. Начни с одного процесса, когда будет нужно — просто добавь ещё. Так делают многие приложения, включая HTTP-серверы типа Apache, NGINX или Lighttpd.

Почему один процесс NGINX берёт на себя всю работу? - 1

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

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js