ThreeDHead Опубликовано 2 августа, 2010 · Жалоба Новость вот http://www.opennet.ru/opennews/art.shtml?num=27497 Для меня, прям таки знаковые изменения. До этого думал, что кроме Интела с многоочередными сетевыми, это ни кого не интересует. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 2 августа, 2010 · Жалоба Новость вот http://www.opennet.ru/opennews/art.shtml?num=27497 Для меня, прям таки знаковые изменения. До этого думал, что кроме Интела с многоочередными сетевыми, это ни кого не интересует. хм... опять pppoe краями обошли? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 2 августа, 2010 · Жалоба Jugernault, http://patchwork.ozlabs.org/patch/48490/ Но есть подозрение, что в патче нет надобности. Так что лучше сначала попробовать ванильное ядро. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 2 августа, 2010 · Жалоба хм... опять pppoe краями обошли? Не совсем, но типа-того. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 2 августа, 2010 · Жалоба В чем же заключается не совсем? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 3 августа, 2010 · Жалоба В чем же заключается не совсем? В моем случае это шлюзы L3<=>PPPoE, причем последнее - клиентские соединения на BRAS. Но и не это главное. Вообще сетевых задач достаточно много, и каждая из них заставляет распределить сетевую нагрузку на максимально возможное число ядер, что не всегда удается с помощью железа. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 6 августа, 2010 · Жалоба Ну пока никто ничего про 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% Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 6 августа, 2010 · Жалоба Транзитному траффику - бесполезно, для pppoe вроде как тоже бесполезно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 6 августа, 2010 · Жалоба nuclearcat, почему? RFS - да, не поможет транзитному трафику. А RPS - еще как. Например, в случае развесистых правил iptables. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 6 августа, 2010 · Жалоба IMHO блокировки iptables и неоптимизированные правила имеют слишком большой негативный эффект, RPS врядли это сильно поправит. Скоро буду проводить тесты на реальном траффике, посмотрим... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 10 августа, 2010 · Жалоба Запустил на малом боевом сервере (всего ~300 PPPoE соединений). Каждый PPP-сетевой интерфейс тоже имеет свой псевдо-файл /sys/class/net/pppX/queues/rx-0/rps_cpus, в него записываем маску, и загрузка переходит на указанные ядра. Вывод: RPS на PPPoE работает, на маршрутизации тоже. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 10 августа, 2010 · Жалоба >RPS на PPPoE работает Сравнительные показатели производительности в студию ! :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 10 августа, 2010 · Жалоба Сравнительные показатели производительности в студию ! :-)Не знаю насколько смогу дать прям сравнительные показатели, но пока могу поделиться субъективными.Боевой сервер, ~3000 ppp-интерфейсов, сетевая intel/igb, по 4 очереди на прием/4 на передачу. Загружена только первая очередь по приему и первая по передаче. К 12-ти часам дня эти ядра в полку, полная паника, аут. Для того чтобы всё работало, добавляем еще сетевую с двумя интерфейсами, конфигурируем по одной очереди на прием и одной на передачу, получаем 3 интерфейса, 6 ядер задействуем - полёт нормальный. А теперь новый вариант - одна сетевая, по одной очереди на прием и передачу + RSP на все оставшиеся ядра, итого - очень некислый рост производительности и загрузка _всех_ без исключения ядер. Это пока тоже теория, т.к. в бою на больших серверах не проверял еще ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 17 августа, 2010 · Жалоба загрузка _всех_ без исключения ядер. Загрузка может быть как раз от того что контексты потоков переключаются или от особенностей синхронизации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 17 августа, 2010 · Жалоба Ivan_83, если при этом одно ядро было загружено скажем на 60%, а теперь каждое из четырех ядер загружено на 30%, то можно считать что это неплохой результат. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 17 августа, 2010 · Жалоба Ivan_83, если при этом одно ядро было загружено скажем на 60%, а теперь каждое из четырех ядер загружено на 30%, то можно считать что это неплохой результат. Если 4 ядра загружены на 30%, то загрузка одного ядра должна была быть 4х30=120%, чего при равном трафике и ппс - быть не может. Но это я не к тому что всё плохо, а как раз таки наоборот :) Если ядро в полку до паники в системе, включаем RPS, и все продолжает работать как ни в чем не бывало, распределяя нагрузку по указанным ядрам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 17 августа, 2010 · Жалоба Если 4 ядра загружены на 30%, то загрузка одного ядра должна была быть 4х30=120%, чего при равном трафике и ппс - быть не можетХорошо, если бы это было правдой, но это не так. :) Ivan_83 как раз об этом и написал. Здесь еще можно говорить о false sharing-е (http://en.wikipedia.org/wiki/False_sharing) - явлении, которое убивает все преимущества кеша процессора в SMP системе, когда у каждого процессора (не важно что там, физический процессор или ядро) свой кеш (не shared). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 17 августа, 2010 (изменено) · Жалоба Итак, поэкспериментировал у себя. Тазик - 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% sirqCPU1: 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% sirqCPU1: 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% sirqCPU1: 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% sirqCPU1: 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% sirqCPU1: 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 ядер если не ошибаюсь). Изменено 17 августа, 2010 пользователем NiTr0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 1 октября, 2010 · Жалоба Ну и есть тут кто нибудь кому RSP на PPPoE Bras-е выигрыш по производительности дал? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alex_001 Опубликовано 6 октября, 2010 · Жалоба Интересно как оно согласуется с irq affinity? По умолчанию ведь стоит FF - прерывания раскидываются по ядрам. Наскольно я понимаю сначала надо привязывать прерывания к ядрам , а после этого раскидывать через RPS softirq ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nallien Опубликовано 12 октября, 2010 · Жалоба кто-то еще тестирует? интересны результаты. сами недавно переехали на 2.6.35 - честно говоря улучшений не видно... даже наоборот. но подозреваю исключительно от того что основные ресурсы жрут на машине не сетевые процессы, а юзер и кернел левел приложения. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 8 ноября, 2010 (изменено) · Жалоба Занимательно. На сервере встроенные 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 появилось количество очередей = количеству процессорных ядер, а для интеля нет? Изменено 8 ноября, 2010 пользователем heap Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 8 ноября, 2010 · Жалоба а должно было появиться? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 8 ноября, 2010 · Жалоба а должно было появиться? Уже дочитался, что не должно. Написано примерно так "Для поддерживающих аппаратно очереди - появятся очереди". А для неподдерживаемых появится очередь как раз rx-0. Откуда возникают вопросы: 1. Таки кто-то заметил оптимизацию от этого RPS, там где очереди не появились? 2. Почему, если указанный бродком с драйвером bnx2 умеет очереди, они раньше не появлялись ни в каком виде, в том время как 10Г бродком с драйвером bnx2x появлялся в /proc/interrupts в виде интераптов на заданное количество очередей? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 8 ноября, 2010 · Жалоба Будьте любезны, пожалуйста, по подробнее про 10G бродком.... Я то же такой хочу)))) а должно было появиться? Уже дочитался, что не должно. Написано примерно так "Для поддерживающих аппаратно очереди - появятся очереди". А для неподдерживаемых появится очередь как раз rx-0. Откуда возникают вопросы: 1. Таки кто-то заметил оптимизацию от этого RPS, там где очереди не появились? 2. Почему, если указанный бродком с драйвером bnx2 умеет очереди, они раньше не появлялись ни в каком виде, в том время как 10Г бродком с драйвером bnx2x появлялся в /proc/interrupts в виде интераптов на заданное количество очередей? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...