Ссылка вопреки печальной статистике этого ресурса оказалась живой
http://libcode.org/projects/birq/
И не просто живой. В 2018 году версия BIRQ была поднята до 1.5.
на страничке
http://libcode.org/projects/birq/documents
есть англоязычное руководство пользователя
http://libcode.org/attachments/download ... 170704.pdf
которое я и перевел (жалко, что не было русскоязычного руководства, автор-то судя по всему наш соотечественник)
Сергей Каличев <serj.kalichev@gmail.com>
2017
Обзор
BIRQ означает баланс IRQ. Это программное обеспечение для балансировки прерываний между процессорами в Linux при высокой нагрузке. Проект birq написан на C. Он не имеет внешних зависимостей. Автор проекта birq - Сергей Каличев <serj.kalichev (at) gmail.com>. Спонсором разработки проекта выступает компания «Фактор-ТС» http://www.factor-ts.ru/.
Балансировка IRQ является важной задачей для систем с высокой нагрузкой ввода-вывода. Балансировщик собирает системную статистику и затем устанавливает соответствие IRQ для освобождения перегруженных процессоров. Статистика может содержать информацию об использовании процессора, количестве прерываний, топологии системы и т. Д.
Есть два хорошо известных проекта балансировки:
• irqbalance https://github.com/Irqbalance/irqbalance
• irqd https://github.com/vaesoo/irqd
Оба проекта имеют свои преимущества и недостатки. Я использовал irqbalance в течение длительного времени. Это хороший проект, но теперь накопившиеся проблемы заставляют меня начинать новый проект балансировки. Позже я рассмотрю некоторые проблемы с irqd и irqbalace, но сначала хочу отметить несколько важных проблем с балансировкой IRQ, которые не могут быть решены сейчас любым балансировщиком, включая birq.
Проект BIRQ использует лицензию BSD начиная с версии birq-1.3.0. Более ранние версии содержат некоторый код GPL.
BIRQ ссылки
Есть ссылки, связанные с BIRQ:
• GIT репозиторий https://src.libcode.org/birq
• Загрузки http://birq.libcode.org/files
• Отслеживание проблем http://birq.libcode.org/issues/new
• Список рассылки обсуждения BIRQ http://groups.google.com/group/birq
Бесполезная статистика
Одна из наиболее важных проблем для балансировки IRQ - бесполезная статистика ядра об использовании CPU IRQ. Ядро Linux показывает следующую информацию:
• Время, которое процессор потратил в обработчиках IRQ и в soft-irq. Смотрите /proc/stat. Это время является общим для всех IRQ и Softirq.
• Количество прерываний для каждого IRQ. Смотрите /proc/stat или /proc/interrupts.
Наиболее важным источником прерываний при балансировке IRQ является сеть. Ранее сетевые драйверы полностью управлялись прерываниями. Больший трафик приводит к большему количеству прерываний от сетевой карты. В целом, интерфейсы с большим количеством прерываний приводят к большей загрузке процессора. Но сейчас это не так.
Сетевые драйверы в современном ядре Linux используют механизм NAPI для увеличения производительности при высокой пропускной способности. Драйвер может отключить аппаратные прерывания и назначить программу soft-irq для опроса новых данных позже. Программа soft-irq будет запрашивать новые данные, обрабатывать соответствующие действия и затем планировать программу снова. Обратите внимание, что прерывания по-прежнему отключены. Единственный случай, когда драйвер разрешает прерывания, - это когда все данные получены и нечего получать. Часто NAPI приводит к обратной логике для количества прерываний и загрузки процессора. Больший трафик приводит к меньшему количеству прерываний. Таким образом, меньшее количество прерываний в случае NAPI означает большую нагрузку на процессор. Но если трафик не очень высок, количество прерываний будет по-прежнему большим, потому что прерывания включаются почти все время (нечего получать -> включить прерывания).
Это беспорядок. Невозможно определить загрузку ЦП, вызванную указанным IRQ, используя количество прерываний для этого IRQ. Кроме того, запланированные soft-irq не имеют никакой связи с оригинальным IRQ. Из-за мягкого опроса количество прерываний является бесполезной информацией для определения загрузки ЦП, вызванной IRQ. Таким образом, балансировщик ничего не знает о весе IRQ при выборе IRQ для удаления от перегруженного процессора.
IRQ sticking (IRQ прилипание)
Следующая нерешенная проблема для балансировки IRQ - это залипание IRQ. Когда процессор имеет очень высокую нагрузку, механизм опроса всегда включен, и прерываний нет вообще. Балансировщик может изменить привязку IRQ, но не может изменить процессор для запланированного смягчения. Таким образом, опрос может выполняться на текущем процессоре неопределенно долго, пока драйвер не получит все данные и не разрешит прерывания.
Для балансировщика это означает неверную статистику о загрузке процессора и соответствии IRQ. Балансировщик предполагает, что IRQ имеет новое сродство, но фактически использует старый процессор. Старый ЦП имеет высокую нагрузку, но новый ЦП вообще не имеет дополнительной нагрузки. Обманутый балансировщик будет снова и снова отодвигать IRQ от старого процессора. Но ничего не происходит. Иногда эксперименты могут показать пустой (без IRQ) процессор со 100% нагрузкой. Через некоторое время (может быть несколько минут) IRQ будут действительно перемещены на другой процессор. Старая загрузка ЦП станет 0%, но некоторая другая загрузка ЦП, вероятно, станет 100%, потому что балансировщик перемещает IRQ к минимально загруженному ЦП. Часто минимально загруженный ЦП одинаков для серии движений ЦП, потому что перемещение торчащих прерываний не влияет на целевую нагрузку ЦП. Процессор со 100% нагрузкой имеет большие шансы заставить свои IRQ зависать. Ситуация будет повторяться снова и снова.
Это не способ официально определить IRQ прилипания. И я не знаю, как отключить IRQ. Это проблема драйвера сетевого интерфейса и ядра.
Initial IRQ allocation (Начальное распределение IRQ)
В ядре Linux есть проблема с начальным распределением IRQ. Во время инициализации системы Linux ставит IRQ на первый процессор. CPU имеет 256 слотов для обработки IRQ. Некоторые из этих слотов используются служебными IRQ. Поэтому, когда все слоты заняты, Linux будет использовать второй процессор. И так далее. Если таблица CPU IRQ заполнена, вы не можете переместить другой IRQ на этот процессор (для него нет свободного места). Вторая проблема - настройки соответствия IRQ будут применены, когда IRQ действительно прибыл. До этого момента IRQ находится в старой таблице CPU и не удаляется из нее. В то же время он зарезервирует слот в новой таблице CPU. Таким образом, перемещение неактивных IRQ может привести к загрязнению таблиц ЦП.
Поэтому бирк пытается минимизировать движение IRQ. Бирк (начиная с версии 1.2.0) не меняет начальное сродство для всех IRQ при запуске (старая бирка сделала это). Он получает текущую привязку IRQ. Он может изменить соответствие IRQ, если процессор перегружен и если IRQ имеет хотя бы одно прерывание во время текущего интервала (периода итерации). То есть позволяет перемещать только активные IRQ.
В нашем тесте у нас были процессоры с занятыми таблицами IRQ. Большинство IRQ были пассивными, а CPU простаивал, но мы не можем переместить активные IRQ на этот простаивающий CPU, поскольку его слоты IRQ были заняты. Это серьезная проблема ядра Linux для больших платформ с большим количеством интерфейсов локальной сети. Обратите внимание, что каждый интерфейс имеет несколько очередей. Каждая очередь имеет свой собственный IRQ.
Another problems and peculiarities (Другие проблемы и особенности)
Я попытаюсь показать некоторые проблемы с балансировкой на примере существующих балансировщиков.
В проекте irqd используется управление пакетами получения пакетов (RPS) для балансировки нагрузки на процессор. В нескольких словах RPS - это механизм для разделения обработки сетевых пакетов между несколькими процессорами. RPS разделяет поток, исходящий из одного источника. Источником является сетевой интерфейс или очередь приема по сети. Весь поток будет обработан на одном процессоре без RPS. Поиск сведений о RPS в документации по Интернету или ядру Linux. Первая проблема с RPS - RPS зависит от сети. На самом деле это не серьезная проблема, я думаю. Вторая проблема заключается в том, что RPS подходит для одного большого потока, но не подходит для многих небольших потоков. Так что это не может быть универсальным. Эксперименты показывают, что сервер может получать больше сетевых пакетов из одного большого потока, используя RPS, но загрузка ЦП очень высока для общего объема полученных данных. И третья проблема - имя очереди приема не стандартизировано. Поэтому irqd должен проанализировать /proc/interrupts для имен источников IRQ и использовать нечеткую логику, чтобы найти соответствующие записи RPS-контролирующей файловой системы. Каждый сетевой драйвер использует свою собственную схему именования.
Несбалансированность основывается на статистике прерываний, предположим, что IRQ с большим количеством прерываний вызывают большую нагрузку на процессор. Затем он вычисляет веса IRQ, чтобы установить более оптимальное сродство. К сожалению, это не работает из-за NAPI. Вес не подходит для высоконагруженной системы. Irqbalance слишком интеллектуален для текущего состояния статистики ядра.
Irqbalance классифицирует IRQ (устройства) и использует разные уровни баланса для разных классов устройств. В результате некоторые устройства имеют связь с несколькими процессорами одновременно. Это нехорошо, потому что большинство контроллеров прерываний все равно используют один процессор. Это приводит к неправильным расчетам веса.
Hyper Threading
В ранних выпусках birq предполагается, что HT - бесполезная функция для балансировки IRQ, и поэтому наилучшее поведение - использовать только первый поток HT для IRQ. Но реальные тесты показывают, что использование обоих потоков HT ускоряет обработку IRQ. Для наших тестов мы использовали платформы с большим количеством интерфейсов локальной сети, и наша система была сильно загружена. Когда я отключил HT (использую первый поток HT процессора и не использую второй поток HT этого процессора), суммарная скорость была ниже. И мы не видели примеров, когда система с HT медленнее, чем система без HT. HT рекомендуется использовать.
Обратите внимание, что текущий birq с отключенным HT получит текущее сродство. Текущее сходство в основном используют HT. Birq не изменит эту привязку, если соответствующий процессор не перегружен и IRQ не активен. Поэтому люди думают, что отключение HT не работает. На самом деле это работает. Это переместит IRQ только в первый поток HT. Но вторые потоки уже имеют IRQ на старте Birk.
Some BIRQ features (Некоторые функции BIRQ)
BIRQ собирает статистику загрузки процессора и выбирает наиболее перегруженную. Затем он выбирает IRQ для удаления от перегруженного процессора. Балансировщик может использовать три разные стратегии для выбора IRQ.
Стратегии:
• Выберите IRQ с максимальным количеством прерываний.
• Выберите IRQ с минимальным количеством прерываний.
• Случайный выбор.
Эксперименты показывают, что наиболее эффективной стратегией является случайный выбор. Теперь это по умолчанию. Пользователь может выбрать стратегию, используя аргументы командной строки для исполняемого файла birq. В случае минимального/максимального выбора проблема заключается в периодических процессах. Более интеллектуальное размещение IRQ бесполезно из-за бесполезной статистики ядра.
Birk не использует классификацию устройств. Все IRQ равны.
На самом деле балансировка BIRQ не идеальна. Но я думаю, что идеальная балансировка невозможна из-за бесполезной статистики ядра и зависания IRQ.
Usage (Использование)
Текущая версия birq - 1.4.0.
(на выше приведенном сайте уже появилась версия 1.5, однако "Руководство пользователя" еще не обновилось. Прим. переводчика).
$ birq [options]
Options :
• -h, –help- Справка по печати.
• -d, –debug- Режим отладки. Не демонизировать.
• -v, -verbose- быть многословным.
• -c <PATH>, –conf = <PATH> - файл конфигурации. По умолчанию используется /etc/birq/birq.conf. Реализовано начиная с birq-1.4.0.
• -x <PATH>, –pxm = <PATH> - указать конфигурационный файл близости. (??) Реализовано начиная с бирк-1.1.0.
• -p <path>, –pid = <путь> - файл для сохранения PID демона.
• -O <facility>, –facility = <facility> - средство системного журнала. По умолчанию это DAEMON.
Следующие опции являются устаревшими. Используйте конфигурационный файл вместо параметров командной строки:
• -r, –ht- Включить поддержку Hyper Threading. Вторые потоки будут рассматриваться как реальный процессор. Не рекомендуется.
• -t <float>, –threshold = <float> - порог, который учитывает перегрузку процессора, в процентах. Значение с плавающей запятой. Порог по умолчанию составляет 99%.
• -l <float>, –load-limit = <float> - не перемещать IRQ на процессоры, загруженные больше этого предела, в процентах. Предел по умолчанию составляет 95%.
• -i <sec>, –short-interval = <sec> - короткий интервал итерации в секундах. Он будет использоваться при обнаружении перегруженного процессора. По умолчанию 2 секунды.
• -I <sec>, –long-interval = <sec> - длинный интервал итерации в секундах. Он будет использоваться, когда нет перегруженных процессоров. По умолчанию 5 секунд.
• -s <стратегия>, –strategy = <стратегия> - стратегия выбора IRQ для перемещения. Возможные значения: «min», «max», «rnd». По умолчанию это «rnd». Обратите внимание, что birq-1.0.0 использует имя -c, -chooseoption для той же функциональности.
Configuration file
Расположение файла конфигурации по умолчанию - /etc/birq/birq.conf. Но вы можете указать другое местоположение с помощью параметра командной строки «-c» birq.
Конфигурационный файл можно перечитать, послав сигнал SIGHUP на демона birq.
Опции:
• threshold = <float> - пороговое значение, которое учитывает перегрузку процессора, в процентах. Значение с плавающей запятой. Порог по умолчанию составляет 99%.
• load-limit = <float> - не перемещать IRQ к процессорам, загруженным больше этого предела, в процентах. Предел по умолчанию составляет 95%.
• short-interval = <sec> - короткий интервал итерации в секундах. Он будет использоваться при обнаружении перегруженного процессора. По умолчанию 2 секунды.
• long-interval = <sec> - Длинный интервал итерации в секундах. Он будет использоваться, когда нет перегруженных процессоров. По умолчанию 5 секунд.
• strategy=<strategy> - стратегия выбора IRQ для движения. Возможные значения: «min», «max», «rnd». По умолчанию это «rnd».
• exclude-cpus = <cpumap> - позволяет исключить некоторые ЦП из списка ЦП, обрабатывающих IRQ. «Cpumap» - это битовая маска в шестнадцатеричном формате, подобная файлам / proc / irq / * / smp_affinity.
Proximity (Близость?)
Близость узла NUMA является очень важной характеристикой для балансировки IRQ. Часто шины PCI имеют разное расстояние до процессоров от разных узлов NUMA. Вы можете видеть схемы блоков материнских плат больших серверов - мосты PCI подключены к определенному узлу NUMA (пакет ЦП). Таким образом, путь от устройства PCI к нелокальному ЦП (ЦП от другого узла NUMA) не является прямым. Обработка IRQ на нелокальных процессорах снижает производительность. Например, обработка IRQ сети на нелокальном процессоре может вдвое снизить производительность и пропускную способность трафика.
На большинстве аппаратных платформ есть информация о близости устройств PCI. Балансировщик может получить эту информацию от sysfs. Но на некоторых платформах нет информации о близости или нет вообще. В этом случае для локального узла NUMA устанавливается значение -1, а маска локального ЦП включает в себя все ЦП системы. Это неоптимально.
BIRQ позволяет установить близость вручную, чтобы восстановить настройки системы. Используйте параметр командной строки «-x» или «–pxm», чтобы указать конфигурационный файл близости. Конфигурационный файл близости выглядит так:
Первое поле - это PCI-адрес. Вы можете узнать адреса PCI, используя следующую команду:
Формально адрес PCI содержит следующие части с разделителем «:».
<Domain>:<Bus>:<Device>.<Func>
•Domain - 4 символа. Пример «0000»
•Bus - 2 символа. Пример «08»
•Device - 2 символа. Пример «1с»
•Func - 1 символ. Пример «6». Обратите внимание на разделитель между (Device и Func) «.».
Файл конфигурации близости может содержать неполный PCI-адрес. В первой строке примера сказано, что все устройства PCI с адресом, начинающимся с «0000:» (т. е. адрес домена, равный «0000»), будут привязаны к узлу NUMA 1. Вторая строка дает команду birq связывать устройство PCI с адресом «0000: 08: 00.0 »к узлу NUMA 0. Третья строка указывает привязать PCI-устройство« 0000: 00: 1c.6 »к процессорам с номерами 0, 1, 2, 3, 4, 5, 6, 7.« ff » »- это маска процессора для привязки. Это позволяет связывать устройства PCI более конкретным способом, чем определение узла NUMA.
Если адрес устройства PCI совпадает с несколькими строками в файле конфигурации, будет использоваться более конкретная (более длинная) строка. Устройство PCI «0000: 08: 00.0» соответствует первой и второй строкам. Вторая строка будет использоваться, потому что «0000: 08: 00.0» более конкретно, чем «0000:».
Обратите внимание, что вам не нужен файл конфигурации близости, если ваша платформа показывает правильные значения для близости устройства PCI.
2017
Обзор
BIRQ означает баланс IRQ. Это программное обеспечение для балансировки прерываний между процессорами в Linux при высокой нагрузке. Проект birq написан на C. Он не имеет внешних зависимостей. Автор проекта birq - Сергей Каличев <serj.kalichev (at) gmail.com>. Спонсором разработки проекта выступает компания «Фактор-ТС» http://www.factor-ts.ru/.
Балансировка IRQ является важной задачей для систем с высокой нагрузкой ввода-вывода. Балансировщик собирает системную статистику и затем устанавливает соответствие IRQ для освобождения перегруженных процессоров. Статистика может содержать информацию об использовании процессора, количестве прерываний, топологии системы и т. Д.
Есть два хорошо известных проекта балансировки:
• irqbalance https://github.com/Irqbalance/irqbalance
• irqd https://github.com/vaesoo/irqd
Оба проекта имеют свои преимущества и недостатки. Я использовал irqbalance в течение длительного времени. Это хороший проект, но теперь накопившиеся проблемы заставляют меня начинать новый проект балансировки. Позже я рассмотрю некоторые проблемы с irqd и irqbalace, но сначала хочу отметить несколько важных проблем с балансировкой IRQ, которые не могут быть решены сейчас любым балансировщиком, включая birq.
Проект BIRQ использует лицензию BSD начиная с версии birq-1.3.0. Более ранние версии содержат некоторый код GPL.
BIRQ ссылки
Есть ссылки, связанные с BIRQ:
• GIT репозиторий https://src.libcode.org/birq
• Загрузки http://birq.libcode.org/files
• Отслеживание проблем http://birq.libcode.org/issues/new
• Список рассылки обсуждения BIRQ http://groups.google.com/group/birq
Бесполезная статистика
Одна из наиболее важных проблем для балансировки IRQ - бесполезная статистика ядра об использовании CPU IRQ. Ядро Linux показывает следующую информацию:
• Время, которое процессор потратил в обработчиках IRQ и в soft-irq. Смотрите /proc/stat. Это время является общим для всех IRQ и Softirq.
• Количество прерываний для каждого IRQ. Смотрите /proc/stat или /proc/interrupts.
Наиболее важным источником прерываний при балансировке IRQ является сеть. Ранее сетевые драйверы полностью управлялись прерываниями. Больший трафик приводит к большему количеству прерываний от сетевой карты. В целом, интерфейсы с большим количеством прерываний приводят к большей загрузке процессора. Но сейчас это не так.
Сетевые драйверы в современном ядре Linux используют механизм NAPI для увеличения производительности при высокой пропускной способности. Драйвер может отключить аппаратные прерывания и назначить программу soft-irq для опроса новых данных позже. Программа soft-irq будет запрашивать новые данные, обрабатывать соответствующие действия и затем планировать программу снова. Обратите внимание, что прерывания по-прежнему отключены. Единственный случай, когда драйвер разрешает прерывания, - это когда все данные получены и нечего получать. Часто NAPI приводит к обратной логике для количества прерываний и загрузки процессора. Больший трафик приводит к меньшему количеству прерываний. Таким образом, меньшее количество прерываний в случае NAPI означает большую нагрузку на процессор. Но если трафик не очень высок, количество прерываний будет по-прежнему большим, потому что прерывания включаются почти все время (нечего получать -> включить прерывания).
Это беспорядок. Невозможно определить загрузку ЦП, вызванную указанным IRQ, используя количество прерываний для этого IRQ. Кроме того, запланированные soft-irq не имеют никакой связи с оригинальным IRQ. Из-за мягкого опроса количество прерываний является бесполезной информацией для определения загрузки ЦП, вызванной IRQ. Таким образом, балансировщик ничего не знает о весе IRQ при выборе IRQ для удаления от перегруженного процессора.
IRQ sticking (IRQ прилипание)
Следующая нерешенная проблема для балансировки IRQ - это залипание IRQ. Когда процессор имеет очень высокую нагрузку, механизм опроса всегда включен, и прерываний нет вообще. Балансировщик может изменить привязку IRQ, но не может изменить процессор для запланированного смягчения. Таким образом, опрос может выполняться на текущем процессоре неопределенно долго, пока драйвер не получит все данные и не разрешит прерывания.
Для балансировщика это означает неверную статистику о загрузке процессора и соответствии IRQ. Балансировщик предполагает, что IRQ имеет новое сродство, но фактически использует старый процессор. Старый ЦП имеет высокую нагрузку, но новый ЦП вообще не имеет дополнительной нагрузки. Обманутый балансировщик будет снова и снова отодвигать IRQ от старого процессора. Но ничего не происходит. Иногда эксперименты могут показать пустой (без IRQ) процессор со 100% нагрузкой. Через некоторое время (может быть несколько минут) IRQ будут действительно перемещены на другой процессор. Старая загрузка ЦП станет 0%, но некоторая другая загрузка ЦП, вероятно, станет 100%, потому что балансировщик перемещает IRQ к минимально загруженному ЦП. Часто минимально загруженный ЦП одинаков для серии движений ЦП, потому что перемещение торчащих прерываний не влияет на целевую нагрузку ЦП. Процессор со 100% нагрузкой имеет большие шансы заставить свои IRQ зависать. Ситуация будет повторяться снова и снова.
Это не способ официально определить IRQ прилипания. И я не знаю, как отключить IRQ. Это проблема драйвера сетевого интерфейса и ядра.
Initial IRQ allocation (Начальное распределение IRQ)
В ядре Linux есть проблема с начальным распределением IRQ. Во время инициализации системы Linux ставит IRQ на первый процессор. CPU имеет 256 слотов для обработки IRQ. Некоторые из этих слотов используются служебными IRQ. Поэтому, когда все слоты заняты, Linux будет использовать второй процессор. И так далее. Если таблица CPU IRQ заполнена, вы не можете переместить другой IRQ на этот процессор (для него нет свободного места). Вторая проблема - настройки соответствия IRQ будут применены, когда IRQ действительно прибыл. До этого момента IRQ находится в старой таблице CPU и не удаляется из нее. В то же время он зарезервирует слот в новой таблице CPU. Таким образом, перемещение неактивных IRQ может привести к загрязнению таблиц ЦП.
Поэтому бирк пытается минимизировать движение IRQ. Бирк (начиная с версии 1.2.0) не меняет начальное сродство для всех IRQ при запуске (старая бирка сделала это). Он получает текущую привязку IRQ. Он может изменить соответствие IRQ, если процессор перегружен и если IRQ имеет хотя бы одно прерывание во время текущего интервала (периода итерации). То есть позволяет перемещать только активные IRQ.
В нашем тесте у нас были процессоры с занятыми таблицами IRQ. Большинство IRQ были пассивными, а CPU простаивал, но мы не можем переместить активные IRQ на этот простаивающий CPU, поскольку его слоты IRQ были заняты. Это серьезная проблема ядра Linux для больших платформ с большим количеством интерфейсов локальной сети. Обратите внимание, что каждый интерфейс имеет несколько очередей. Каждая очередь имеет свой собственный IRQ.
Another problems and peculiarities (Другие проблемы и особенности)
Я попытаюсь показать некоторые проблемы с балансировкой на примере существующих балансировщиков.
В проекте irqd используется управление пакетами получения пакетов (RPS) для балансировки нагрузки на процессор. В нескольких словах RPS - это механизм для разделения обработки сетевых пакетов между несколькими процессорами. RPS разделяет поток, исходящий из одного источника. Источником является сетевой интерфейс или очередь приема по сети. Весь поток будет обработан на одном процессоре без RPS. Поиск сведений о RPS в документации по Интернету или ядру Linux. Первая проблема с RPS - RPS зависит от сети. На самом деле это не серьезная проблема, я думаю. Вторая проблема заключается в том, что RPS подходит для одного большого потока, но не подходит для многих небольших потоков. Так что это не может быть универсальным. Эксперименты показывают, что сервер может получать больше сетевых пакетов из одного большого потока, используя RPS, но загрузка ЦП очень высока для общего объема полученных данных. И третья проблема - имя очереди приема не стандартизировано. Поэтому irqd должен проанализировать /proc/interrupts для имен источников IRQ и использовать нечеткую логику, чтобы найти соответствующие записи RPS-контролирующей файловой системы. Каждый сетевой драйвер использует свою собственную схему именования.
Несбалансированность основывается на статистике прерываний, предположим, что IRQ с большим количеством прерываний вызывают большую нагрузку на процессор. Затем он вычисляет веса IRQ, чтобы установить более оптимальное сродство. К сожалению, это не работает из-за NAPI. Вес не подходит для высоконагруженной системы. Irqbalance слишком интеллектуален для текущего состояния статистики ядра.
Irqbalance классифицирует IRQ (устройства) и использует разные уровни баланса для разных классов устройств. В результате некоторые устройства имеют связь с несколькими процессорами одновременно. Это нехорошо, потому что большинство контроллеров прерываний все равно используют один процессор. Это приводит к неправильным расчетам веса.
Hyper Threading
В ранних выпусках birq предполагается, что HT - бесполезная функция для балансировки IRQ, и поэтому наилучшее поведение - использовать только первый поток HT для IRQ. Но реальные тесты показывают, что использование обоих потоков HT ускоряет обработку IRQ. Для наших тестов мы использовали платформы с большим количеством интерфейсов локальной сети, и наша система была сильно загружена. Когда я отключил HT (использую первый поток HT процессора и не использую второй поток HT этого процессора), суммарная скорость была ниже. И мы не видели примеров, когда система с HT медленнее, чем система без HT. HT рекомендуется использовать.
Обратите внимание, что текущий birq с отключенным HT получит текущее сродство. Текущее сходство в основном используют HT. Birq не изменит эту привязку, если соответствующий процессор не перегружен и IRQ не активен. Поэтому люди думают, что отключение HT не работает. На самом деле это работает. Это переместит IRQ только в первый поток HT. Но вторые потоки уже имеют IRQ на старте Birk.
Some BIRQ features (Некоторые функции BIRQ)
BIRQ собирает статистику загрузки процессора и выбирает наиболее перегруженную. Затем он выбирает IRQ для удаления от перегруженного процессора. Балансировщик может использовать три разные стратегии для выбора IRQ.
Стратегии:
• Выберите IRQ с максимальным количеством прерываний.
• Выберите IRQ с минимальным количеством прерываний.
• Случайный выбор.
Эксперименты показывают, что наиболее эффективной стратегией является случайный выбор. Теперь это по умолчанию. Пользователь может выбрать стратегию, используя аргументы командной строки для исполняемого файла birq. В случае минимального/максимального выбора проблема заключается в периодических процессах. Более интеллектуальное размещение IRQ бесполезно из-за бесполезной статистики ядра.
Birk не использует классификацию устройств. Все IRQ равны.
На самом деле балансировка BIRQ не идеальна. Но я думаю, что идеальная балансировка невозможна из-за бесполезной статистики ядра и зависания IRQ.
Usage (Использование)
Текущая версия birq - 1.4.0.
(на выше приведенном сайте уже появилась версия 1.5, однако "Руководство пользователя" еще не обновилось. Прим. переводчика).
$ birq [options]
Options :
• -h, –help- Справка по печати.
• -d, –debug- Режим отладки. Не демонизировать.
• -v, -verbose- быть многословным.
• -c <PATH>, –conf = <PATH> - файл конфигурации. По умолчанию используется /etc/birq/birq.conf. Реализовано начиная с birq-1.4.0.
• -x <PATH>, –pxm = <PATH> - указать конфигурационный файл близости. (??) Реализовано начиная с бирк-1.1.0.
• -p <path>, –pid = <путь> - файл для сохранения PID демона.
• -O <facility>, –facility = <facility> - средство системного журнала. По умолчанию это DAEMON.
Следующие опции являются устаревшими. Используйте конфигурационный файл вместо параметров командной строки:
• -r, –ht- Включить поддержку Hyper Threading. Вторые потоки будут рассматриваться как реальный процессор. Не рекомендуется.
• -t <float>, –threshold = <float> - порог, который учитывает перегрузку процессора, в процентах. Значение с плавающей запятой. Порог по умолчанию составляет 99%.
• -l <float>, –load-limit = <float> - не перемещать IRQ на процессоры, загруженные больше этого предела, в процентах. Предел по умолчанию составляет 95%.
• -i <sec>, –short-interval = <sec> - короткий интервал итерации в секундах. Он будет использоваться при обнаружении перегруженного процессора. По умолчанию 2 секунды.
• -I <sec>, –long-interval = <sec> - длинный интервал итерации в секундах. Он будет использоваться, когда нет перегруженных процессоров. По умолчанию 5 секунд.
• -s <стратегия>, –strategy = <стратегия> - стратегия выбора IRQ для перемещения. Возможные значения: «min», «max», «rnd». По умолчанию это «rnd». Обратите внимание, что birq-1.0.0 использует имя -c, -chooseoption для той же функциональности.
Configuration file
Расположение файла конфигурации по умолчанию - /etc/birq/birq.conf. Но вы можете указать другое местоположение с помощью параметра командной строки «-c» birq.
Конфигурационный файл можно перечитать, послав сигнал SIGHUP на демона birq.
Опции:
• threshold = <float> - пороговое значение, которое учитывает перегрузку процессора, в процентах. Значение с плавающей запятой. Порог по умолчанию составляет 99%.
• load-limit = <float> - не перемещать IRQ к процессорам, загруженным больше этого предела, в процентах. Предел по умолчанию составляет 95%.
• short-interval = <sec> - короткий интервал итерации в секундах. Он будет использоваться при обнаружении перегруженного процессора. По умолчанию 2 секунды.
• long-interval = <sec> - Длинный интервал итерации в секундах. Он будет использоваться, когда нет перегруженных процессоров. По умолчанию 5 секунд.
• strategy=<strategy> - стратегия выбора IRQ для движения. Возможные значения: «min», «max», «rnd». По умолчанию это «rnd».
• exclude-cpus = <cpumap> - позволяет исключить некоторые ЦП из списка ЦП, обрабатывающих IRQ. «Cpumap» - это битовая маска в шестнадцатеричном формате, подобная файлам / proc / irq / * / smp_affinity.
Proximity (Близость?)
Близость узла NUMA является очень важной характеристикой для балансировки IRQ. Часто шины PCI имеют разное расстояние до процессоров от разных узлов NUMA. Вы можете видеть схемы блоков материнских плат больших серверов - мосты PCI подключены к определенному узлу NUMA (пакет ЦП). Таким образом, путь от устройства PCI к нелокальному ЦП (ЦП от другого узла NUMA) не является прямым. Обработка IRQ на нелокальных процессорах снижает производительность. Например, обработка IRQ сети на нелокальном процессоре может вдвое снизить производительность и пропускную способность трафика.
На большинстве аппаратных платформ есть информация о близости устройств PCI. Балансировщик может получить эту информацию от sysfs. Но на некоторых платформах нет информации о близости или нет вообще. В этом случае для локального узла NUMA устанавливается значение -1, а маска локального ЦП включает в себя все ЦП системы. Это неоптимально.
BIRQ позволяет установить близость вручную, чтобы восстановить настройки системы. Используйте параметр командной строки «-x» или «–pxm», чтобы указать конфигурационный файл близости. Конфигурационный файл близости выглядит так:
Код: Выделить всё
0000: node 1
0000:08:00.0 node 0
0000:00:1c.6 cpumask ff
# it's comment
# empty strings are ignoredКод: Выделить всё
$ lspci -D<Domain>:<Bus>:<Device>.<Func>
•Domain - 4 символа. Пример «0000»
•Bus - 2 символа. Пример «08»
•Device - 2 символа. Пример «1с»
•Func - 1 символ. Пример «6». Обратите внимание на разделитель между (Device и Func) «.».
Файл конфигурации близости может содержать неполный PCI-адрес. В первой строке примера сказано, что все устройства PCI с адресом, начинающимся с «0000:» (т. е. адрес домена, равный «0000»), будут привязаны к узлу NUMA 1. Вторая строка дает команду birq связывать устройство PCI с адресом «0000: 08: 00.0 »к узлу NUMA 0. Третья строка указывает привязать PCI-устройство« 0000: 00: 1c.6 »к процессорам с номерами 0, 1, 2, 3, 4, 5, 6, 7.« ff » »- это маска процессора для привязки. Это позволяет связывать устройства PCI более конкретным способом, чем определение узла NUMA.
Если адрес устройства PCI совпадает с несколькими строками в файле конфигурации, будет использоваться более конкретная (более длинная) строка. Устройство PCI «0000: 08: 00.0» соответствует первой и второй строкам. Вторая строка будет использоваться, потому что «0000: 08: 00.0» более конкретно, чем «0000:».
Обратите внимание, что вам не нужен файл конфигурации близости, если ваша платформа показывает правильные значения для близости устройства PCI.
Вопросы к местным гуру. Для обсуждения так сказать:
- Насколько это все актуально, скажем, на домашнем или офисном компьютере? или это актуально только для высоконагруженных серверов?
- Не конфликтует ли этот балансировщик с планировщиками в ядре?
- Как его установить для тестов? только сборкой из исходников или есть уже собранные пакеты?
