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

Текущая версия на 16:23, 30 октября 2011

Что за штука…

[править] Что за штука… 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-совместимых драйверов с точки зрения разработчика.