Журнал LinuxFormat - перейти на главную

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

Материал из Linuxformat
Версия от 16:23, 30 октября 2011; Ewgen (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Что за штука…

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