LXF128:Что за штука

Подписка на печатную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подписка на электронную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подшивки старых номеров журнала (печатные версии) Весь 2014 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Что за штука…

Что за штука… NAPI?

Боб Мосс объясняет, почему Linux-ядро становится де-факто стандартом на серверах высокоскоростных сетей.

• Эта аббревиатура не имеет отношения к Национальному агентству прямых инвестиций?

Нет, финансы – не наш профиль: в данном случае NAPI означает просто «New API». Это технология, позволяющая программистам использовать новую методику управления пакетами на уровне драйверов в высокоскоростных сетях. И она уже встроена в ядро Linux.

• Что, и в мое тоже?

Конечно! NAPI присутствует в ядре, начиная с версии 2.5, но лишь недавно NAPI-совместимые драйверы стали применяться для управления пакетами достаточно широко. Используемые технологии позволили значительно поднять надежность и производительность бесчисленных web-серверов, работающих под Linux: нагрузка на них снизилась, а входящие пакеты обрабатываютсяболее эффективно.

• Постойте, о каких это «пакетах» вы постоянно говорите?

Пакет – это набор битов, из которых состоит сообщение или его часть. Обычно пакеты включают машинные и пользовательские данные, доставляемые совместно как часть «информационного наполнения». Машинные данные – это сведения об адресах отправителя и получателя плюс код для коррекции ошибок. Пользовательские данные – это собственно информация, пересылаемая по сети из одного места в другое.

• И как ядро Linux обращается с этими пакетами?

Сетевой контроллер каждой машины посылает процессору так называемое «прерывание», который затем передает его ядру: так Linux «узнает» о прибытии пакета. Ядро обрабатывает прерывания поочередно, с учетом назначенных приоритетов.

• И что дальше?

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

• Неплохо. А что еще происходит при переполнении буфера устаревшего типа?

Пакеты, из которых состоит информационное сообщение, отклоняются – а значит, для передачи полного сообщения их придется отправлять повторно. Вдобавок пакеты придется переупорядочить: ведь ядро попытается обработать первым последний пакет. В домашней сети вы даже не заметите повторных запросов или переупорядочения, поскольку трафик там весьма умеренный. А вот для администраторов web-серверов это дело другое!

• А что будет с web-сервером?

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

• Это, наверное, плохо?

Ошибка обращения к странице возникает, в том числе, при нехватке памяти для процесса, а это дурно влияет на любую систему. Такое явление приводит к «падениям» серверов и называется «конвульсиями» ядра – вещь, крайне нежелательная для любой машины (не говоря уже о web-серверах), поэтому любые меры, сглаживающие этот эффект – весьма полезное дополнение к Linux-ядру.

• А NAPI каким-то образом сдерживает ядро, чтобы оно не «дергалось»?

Это главная цель любой методики, которую NAPI предоставляет разработчикам. Новый API позволяет драйверу тормозить поток входящих пакетов и прекращать отправку запросов на прерывание, чтобы снизить общую нагрузку на систему. Чем меньше общая нагрузка, тем меньше вероятность сбоев ядра, которые мы с вами только что рассмотрели.

• Но ведь торможение пакетов замедлит трафик?

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

• Как же обойтись без отправки запросов на прерывание?

О, это уникальное свойство: NAPI-совместимые драйверы могут отключать прерывания при пиковых нагрузках. Таким образом, ядро не получает их и обрабатывает пакеты по очереди, в нормальной последовательности.

• А разве ядру не обязательно «знать» о прибытии пакетов?

Ядро узнает о пакетах методом опроса NAPI-совместимого драйвера, и это часто повышает эффективность, поскольку отпадает нужда в переупорядочении пакетов. Однако регулярный опрос сетевого контроллера на наличие новых пакетов, вместо того, чтобы уменьшить общие накладные расходы, может увеличить их.

• Какой тогда смысл в опросе?

Видите ли, в этом случае ядро не получает прерываний по прибытии каждого пакета, а обрабатывает пакеты в порядке поступления. Сокращается количество вычислений, связанных с реагированием на новые запросы.

• Но ведь старая проблема — отклонение пакетов — остается?

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

• А отмена прерываний не повлияет на работу системы?

Конечно, повлияет. На некоторых системах прерывания, поступающие от других устройств, могут привести к дополнительным накладным расходам и задержкам, связанным с обработкой этих прерываний. Это называется «повышением латентности» и может привести к тому, что система перестанет реагировать на запросы.

• Но ведь web-серверу так нельзя!

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

• Вот, оказывается, какая интеллектуальная мощь скрыта в моей Linux-машине! А где бы узнать об этом подробнее?

Общий обзор и спецификация NAPI содержат ся в сообщении Linux Foundation по адресу http://www.linuxfoundation.org/en/Net:NAPI. Ну, а расхрабрившись, можете почитать электронную книгу http://lwn.net/images/pdf/LDD3/ch17.pdf, чтобы взглянуть на работу NAPI-совместимых драйверов с точки зрения разработчика.