Jump to content

Кто что думает про RPS/RFS в новом ядре linux?

ThreeDHead
 Share

Recommended Posts

Jugernault

Jugernault

Posted
Posted
Новость вот http://www.opennet.ru/opennews/art.shtml?num=27497

 

Для меня, прям таки знаковые изменения. До этого думал, что кроме Интела с многоочередными сетевыми, это ни кого не интересует.

хм... опять pppoe краями обошли?
ThreeDHead

ThreeDHead

Posted
  • Author
Posted

В чем же заключается не совсем?

В моем случае это шлюзы L3<=>PPPoE, причем последнее - клиентские соединения на BRAS. Но и не это главное. Вообще сетевых задач достаточно много, и каждая из них заставляет распределить сетевую нагрузку на максимально возможное число ядер, что не всегда удается с помощью железа.

ThreeDHead

ThreeDHead

Posted
  • Author
Posted

Ну пока никто ничего про RPS/RFS не думает, поделюсь своими испытаниями.

Собрал ванильное ядро.

На каждый интерфейс и каждую очередь появился псевдо-файл /sys/class/net/ethX/queues/rx-N/rps_cpus

 

В синтетических тестах показывает конкретно загрузку указанного ядра.

Тест 1, на сервере (переносим нагрузку на CPU15):
# echo 00008000 > /sys/class/net/eth0/queues/rx-0/rps_cpus
# iperf -s -p 555

На клиенте:
# iperf -c 192.168.0.1 -p 555 -t 30

При этом загрузка CPU15 ~7%


Тест 2, на сервере (переносим нагрузку на CPU14 + CPU15):
# echo 0000с000 > /sys/class/net/eth0/queues/rx-0/rps_cpus
# iperf -s -p 555

На клиенте:
# iperf -c 192.168.0.1 -p 555 -t 30

При этом загрузка CPU15 ~7%

Повторяем 2-й тест, но указываем 2 потока для клиента iperf:
# iperf -c 192.168.0.1 -p 555 -t 30 -P 2

При этом загрузка CPU14 ~3,5% CPU15 ~3,5%

nuclearcat

nuclearcat

Posted
Posted

IMHO блокировки iptables и неоптимизированные правила имеют слишком большой негативный эффект, RPS врядли это сильно поправит.

Скоро буду проводить тесты на реальном траффике, посмотрим...

ThreeDHead

ThreeDHead

Posted
  • Author
Posted

Запустил на малом боевом сервере (всего ~300 PPPoE соединений).

Каждый PPP-сетевой интерфейс тоже имеет свой псевдо-файл /sys/class/net/pppX/queues/rx-0/rps_cpus, в него записываем маску, и загрузка переходит на указанные ядра.

Вывод: RPS на PPPoE работает, на маршрутизации тоже.

ThreeDHead

ThreeDHead

Posted
  • Author
Posted
Сравнительные показатели производительности в студию ! :-)
Не знаю насколько смогу дать прям сравнительные показатели, но пока могу поделиться субъективными.

Боевой сервер, ~3000 ppp-интерфейсов, сетевая intel/igb, по 4 очереди на прием/4 на передачу. Загружена только первая очередь по приему и первая по передаче. К 12-ти часам дня эти ядра в полку, полная паника, аут.

Для того чтобы всё работало, добавляем еще сетевую с двумя интерфейсами, конфигурируем по одной очереди на прием и одной на передачу, получаем 3 интерфейса, 6 ядер задействуем - полёт нормальный.

 

А теперь новый вариант - одна сетевая, по одной очереди на прием и передачу + RSP на все оставшиеся ядра, итого - очень некислый рост производительности и загрузка _всех_ без исключения ядер. Это пока тоже теория, т.к. в бою на больших серверах не проверял еще ;)

Ivan_83

Ivan_83

Posted
Posted

загрузка _всех_ без исключения ядер.

Загрузка может быть как раз от того что контексты потоков переключаются или от особенностей синхронизации.

Умник

Умник

Posted
Posted

Ivan_83, если при этом одно ядро было загружено скажем на 60%, а теперь каждое из четырех ядер загружено на 30%, то можно считать что это неплохой результат.

 

ThreeDHead

ThreeDHead

Posted
  • Author
Posted

Ivan_83, если при этом одно ядро было загружено скажем на 60%, а теперь каждое из четырех ядер загружено на 30%, то можно считать что это неплохой результат.

Если 4 ядра загружены на 30%, то загрузка одного ядра должна была быть 4х30=120%, чего при равном трафике и ппс - быть не может. Но это я не к тому что всё плохо, а как раз таки наоборот :) Если ядро в полку до паники в системе, включаем RPS, и все продолжает работать как ни в чем не бывало, распределяя нагрузку по указанным ядрам.

Умник

Умник

Posted
Posted
Если 4 ядра загружены на 30%, то загрузка одного ядра должна была быть 4х30=120%, чего при равном трафике и ппс - быть не может
Хорошо, если бы это было правдой, но это не так. :) Ivan_83 как раз об этом и написал. Здесь еще можно говорить о false sharing-е (http://en.wikipedia.org/wiki/False_sharing) - явлении, которое убивает все преимущества кеша процессора в SMP системе, когда у каждого процессора (не важно что там, физический процессор или ядро) свой кеш (не shared).

 

NiTr0

NiTr0

Posted
Posted (edited)

Итак, поэкспериментировал у себя. Тазик - pptp сервер с accel-pptp, кол-во сессий - около 100 (конечные клиенты общаются через 4 магистральных роутера - на 3 из них много клиентов, на 4-м - чуток), проц - атлон 3600+ (самое слабое 2-ядерное, что было в хозяйстве, да еще и с раздельным и мелким кешем), сетевуха - Yukon2 (). Результаты ниже:

 

Изначально:

CPU0: 0.0% usr 0.1% sys 0.0% nic 73.7% idle 0.0% io 0.0% irq 27.0% sirq

CPU1: 0.0% usr 0.1% sys 0.0% nic 99.6% idle 0.0% io 0.0% irq 0.1% sirq

После echo 00000003 >/sys/class/net/eth0/queues/rx-0/rps_cpus:

CPU0: 0.1% usr 0.1% sys 0.0% nic 81.4% idle 0.0% io 0.0% irq 18.9% sirq

CPU1: 0.0% usr 0.0% sys 0.0% nic 88.8% idle 0.0% io 0.0% irq 11.1% sirq

После for i in `ls /sys/class/net`; do echo 00000003 >/sys/class/net/$i/queues/rx-0/rps_cpus; done:

CPU0: 0.3% usr 0.9% sys 0.0% nic 80.6% idle 0.0% io 0.0% irq 17.9% sirq

CPU1: 0.3% usr 1.5% sys 0.0% nic 85.9% idle 0.0% io 0.0% irq 12.0% sirq

После echo 00000000 >/sys/class/net/eth0/queues/rx-0/rps_cpus:

CPU0: 0.0% usr 0.1% sys 0.0% nic 77.2% idle 0.0% io 0.0% irq 22.5% sirq

CPU1: 0.0% usr 0.1% sys 0.0% nic 93.6% idle 0.0% io 0.0% irq 6.1% sirq

Значения прыгают естессно, выбраны были примерно средние; ошибка +- 1-2% softirq.

Т.е. фактически - некоторый оверхед распараллеливания имеется, но не такой уж и большой. Наиболее эффективным является включение RPS на eth0, включение его на всех ppp интерфейсах при этом практически ничего не меняет; а включение его исключительно на ppp - дает только незначительное распараллеливание (отчего-то).

С вланами еще не экспериментировал - переведу продакшн сервера на 2.6.35, тогда и посмотрю. Хотя - на тех машинах оно не сильно заметно будет (недавно на квадкоры феномы проапгрейдил).

 

При указании маски 02 (неважно, для eth0 или для всех) - нагрузка весьма занятно распределяется:

CPU0: 0.1% usr 0.5% sys 0.0% nic 90.8% idle 0.0% io 0.0% irq 8.3% sirq

CPU1: 0.1% usr 0.0% sys 0.0% nic 75.9% idle 0.0% io 0.0% irq 23.8% sirq

Интересно, что же включено в нагрузку на eth0 - неужто столько отжирает обслуживание самой сетевой карты?

 

Включение RFS с таблицей на 64к записей на eth0 - заметного улучшения не дало (что в принципе и ожидалось)

 

P.S. Теперь придется думать - как бы автоматизировать включение RPS на том дистре, что крутится на серверах (LEAF, debian-based с древним инитом из эпохи 2.2 ядер если не ошибаюсь).

Edited by NiTr0
  • 1 month later...
alex_001

alex_001

Posted
Posted

Интересно как оно согласуется с irq affinity? По умолчанию ведь стоит FF - прерывания раскидываются по ядрам. Наскольно я понимаю сначала надо привязывать прерывания к ядрам , а после этого раскидывать через RPS softirq ?

Nallien

Nallien

Posted
Posted

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

  • 4 weeks later...
heap

heap

Posted
Posted (edited)

Занимательно. На сервере встроенные Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet на драйвере bnx2 - тут видно:

# ls -1 /sys/class/net/eth0/queues/
rx-0
rx-1
rx-2
rx-3
rx-4
rx-5
rx-6
rx-7

И не встроенные Intel Corporation 82571EB Gigabit Ethernet Controller на драйвере e1000e, однако:

# ls -1 /sys/class/net/eth2/queues/
rx-0

 

Есть мысли, почему для bnx2 появилось количество очередей = количеству процессорных ядер, а для интеля нет?

Edited by heap
heap

heap

Posted
Posted
а должно было появиться?

Уже дочитался, что не должно. Написано примерно так "Для поддерживающих аппаратно очереди - появятся очереди". А для неподдерживаемых появится очередь как раз rx-0.

Откуда возникают вопросы:

1. Таки кто-то заметил оптимизацию от этого RPS, там где очереди не появились?

2. Почему, если указанный бродком с драйвером bnx2 умеет очереди, они раньше не появлялись ни в каком виде, в том время как 10Г бродком с драйвером bnx2x появлялся в /proc/interrupts в виде интераптов на заданное количество очередей?

telecom

telecom

Posted
Posted

Будьте любезны, пожалуйста, по подробнее про 10G бродком....

Я то же такой хочу))))

 

а должно было появиться?

Уже дочитался, что не должно. Написано примерно так "Для поддерживающих аппаратно очереди - появятся очереди". А для неподдерживаемых появится очередь как раз rx-0.

Откуда возникают вопросы:

1. Таки кто-то заметил оптимизацию от этого RPS, там где очереди не появились?

2. Почему, если указанный бродком с драйвером bnx2 умеет очереди, они раньше не появлялись ни в каком виде, в том время как 10Г бродком с драйвером bnx2x появлялся в /proc/interrupts в виде интераптов на заданное количество очередей?

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.