Перейти к содержимому
Калькуляторы

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Jugernault, http://patchwork.ozlabs.org/patch/48490/

 

Но есть подозрение, что в патче нет надобности. Так что лучше сначала попробовать ванильное ядро.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Не совсем, но типа-того.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну пока никто ничего про 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%

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Транзитному траффику - бесполезно, для pppoe вроде как тоже бесполезно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

nuclearcat, почему? RFS - да, не поможет транзитному трафику. А RPS - еще как. Например, в случае развесистых правил iptables.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

>RPS на PPPoE работает

Сравнительные показатели производительности в студию ! :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Итак, поэкспериментировал у себя. Тазик - 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 ядер если не ошибаюсь).

Изменено пользователем NiTr0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну и есть тут кто нибудь кому RSP на PPPoE Bras-е выигрыш по производительности дал?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Занимательно. На сервере встроенные 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 появилось количество очередей = количеству процессорных ядер, а для интеля нет?

Изменено пользователем heap

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Будьте любезны, пожалуйста, по подробнее про 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.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

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