Dark_Angel Опубликовано 27 ноября, 2014 (изменено) · Жалоба Верно? IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.0.0/17 -j SNAT --to-source 93.157.x.1-93.157.x.126 --persistent Да. У старых ядер можно сказать: IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.0.0/17 -j SAME --to-source 93.157.x.1-93.157.x.126 Можно еще разбить если большой список на деревья и использовать цепочки, тогда пакет будет проходить минимальное количество веток и уходить куда надо. Тут кто-то писал, что это дает сомнительный прирост, зато усложняет диагностику. Изменено 27 ноября, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 27 ноября, 2014 · Жалоба -j SNAT --persistent работает только для случая, когда внешние адреса идут один одним блоком. А есть ли возможностьнечто подобное сделать, к примеру, для двух внешних адресов, находящихся в разных /24 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 27 ноября, 2014 (изменено) · Жалоба У таргета SAME есть ключ --nodst, который будет строить хеш только по сорцу. Это правда получится, как статическая адресация, т.к. человеку по хешу отдадут из пула реальник и он будет с ним сидеть до непонятно когда. Может кто-то попался в сорцах и знает когда происходит рехеш и происходит ли вообще? Ну или в составе хеша есть, например время? Изменено 27 ноября, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 27 ноября, 2014 · Жалоба Рехеша по времени нет, да и не нужен он Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 27 ноября, 2014 · Жалоба Тогда получается, что это та же статическая адресация, только без гемороя с правилами. Не круто же. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 27 ноября, 2014 · Жалоба Вечер добрый! Хотел тут провести эксперимент по производительности с фиксированной частотой прерываний, уменьшением tx очереди, убиранием intel_idle и последним драйвером ixgbe, но наткнулся на неприятность - драйвер с сайта интела не собирается на последнем ядре centos. соответственно пришлось взлетать на штатном драйвере centos 6.6 (ядро 2.6.32-504.1.3.el6.x86_64, драйвер 3.19.1-k), у которого нет параметра InterruptThrottleRate, то есть количество прерываний всегда динамическое. В итоге менее, чем за сутки: fdir_miss: 26236232961 tx_restart_queue: 3378084 rx_csum_offload_errors: 24315 rx_no_dma_resources: 1733158 В пике нагрузка выше - при 7.8 гбит/с - 62% (было <=60% при 8гбит/с), на несколько порядков увеличился показатель context switch (раньше был около 200, сейчас в среднем 10k). Завтра попробую всё-таки собрать драйверок, кстати, может у кого-нить уже есть патчик? Гугль не дает ответа, якобы тикеты открыты и в интеле, и в редхате, но решения нет. Если не получится - придется откатываться назад, либо уходить на 3.10 из elrepo. Скорее всего последнее, хочу посмотреть, как будет работать при отсутствии route cache, раз уж машинка невольно превратилась в тестовый стенд. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 28 ноября, 2014 (изменено) · Жалоба Ну здесь сюрприза нет: стоковый centos стабилен и стар. Но стабилен. Но стар. За то и любим. Даже не смотря на бэкпорты. Поэтому можно не стеснятся и грейдить ядро с драйвером ( это вообще обязательно ). И лучше самосборное ( если знаете как оптимизировать ). А то прилетит вам апдейт из репозитория и всё поломается. Изменено 28 ноября, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 29 ноября, 2014 (изменено) · Жалоба И вот случилась странность. Обновил ядро до 3.10.61 из elrepo, собрал под ним ixgbe 3.22.3, зафиксировал ITR на 32000 прерываний на порт (8000 на очередь), поставил intel_idle.max_cstate=0, processor.max_cstate=1. Route cache отсутствует, проверено. Результат - 6.75 гбит/с, нагрузка 57,5%. сравнил с предыдущими показателями (нашел максимально приближенный 6,65 гбит/с при 50,5% нагрузки) и расстроился. и всё так же растут ошибки: tx_restart_queue: 8103 rx_csum_offload_errors: 34163 rx_no_dma_resources: 1369835 Заметил, что context switches стоит на уровне 2000 в секунду (тогда как раньше было ~130) и очень сильно растет Rescheduling interrupts. И в top очень интересно распределяется процессорное время: 13 root 20 0 0 0 0 S 0.0 0.0 2:20.96 rcu_sched 14 root 20 0 0 0 0 S 0.0 0.0 1:49.89 rcuos/0 17 root 20 0 0 0 0 S 0.0 0.0 1:49.68 rcuos/3 16 root 20 0 0 0 0 S 0.0 0.0 1:49.63 rcuos/2 15 root 20 0 0 0 0 S 0.0 0.0 1:49.62 rcuos/1 31 root 20 0 0 0 0 S 0.0 0.0 0:55.31 ksoftirqd/3 3 root 20 0 0 0 0 R 0.0 0.0 0:54.14 ksoftirqd/0 21 root 20 0 0 0 0 S 0.0 0.0 0:53.96 ksoftirqd/1 26 root 20 0 0 0 0 S 0.0 0.0 0:51.77 ksoftirqd/2 Я вот не совсем уверен, что Read-Copy-Update нужен мне в системе, где точно не будет cpu hotplug, mem hotplug. Прав ли я и подскажите, как это убрать, желательно без пересборки ядра, а установкой параметров sysctl и загрузки. Или всё же придется вернуться на 2.6.32.431 и ждать новую версию ixgbe, которая будет собираться под 504м ядром для центоса Изменено 29 ноября, 2014 пользователем junjunk2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 1 декабря, 2014 · Жалоба Указанные ошибки драйвера не являются драйверо или ядро зависимыми же. Поэтому от апдейта ядра и драйвера не уйдут. Если конечно драйвер не багованый. В вашем случае не похоже. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 1 декабря, 2014 · Жалоба Я вот не совсем уверен, что Read-Copy-Update нужен мне в системе, где точно не будет cpu hotplug, mem hotplug. Прав ли я и подскажите, как это убрать, желательно без пересборки ядра, а установкой параметров sysctl и загрузки. Или всё же придется вернуться на 2.6.32.431 и ждать новую версию ixgbe, которая будет собираться под 504м ядром для центоса read-copy-update вообще-то не имеет специфического отношения к hotplug. Скорее к SMP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 1 декабря, 2014 · Жалоба Dark_Angel новую версию ждать, чтобы быть в треде centos с новыми ядрами. а вот по поводу ошибок - вопрос откуда они остался открытым. предположения, что из-за плавающего ITR и работающего intel_idle, не подтвердились. уменьшение ring для tx тоже не помогло. Осталось только поиграть с lowmem_reserve_ratio, чем и займусь в ближайшие 2 дня, но это возможно решит проблему с rx_no_dma_resources, а что тогда делать с tx_restart_queue? nuclearcat Если я правильно понял из описания, то процессы rcu_shed и rcuos/x вынесены были из ksoftirq для уменьшения latency ядра. Однако в тестах видно, что нагрузка реально увеличивается за счет бОльшего количества переключений контекста (ну возможно и еще из-за чего-то). Происходит это видимо из-за того, что процесс rcu_shed не прибит к ядру (если я правильно понимаю, то rcuos/x как раз выполняются каждый на своём ядре). Можно ли как-то заставить rcu_shed работать на одном ядре? И вообще, имеет ли смысл это вынесение в отдельные процессы, если нагрузка в итоге увеличивается? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 2 декабря, 2014 · Жалоба Наверное можно, taskset. А вообще, centos IMHO немного не та система, на которой можно выжимать все возможности из железа. Стабильная, универсальная, но не быстрая и не свежая. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 2 декабря, 2014 (изменено) · Жалоба Или всё же придется вернуться на 2.6.32.431 и ждать новую версию ixgbe, которая будет собираться под 504м ядром для центоса Зачем вам именно 3.22.3? Ставьте 3.21.2 да и всё. Всяко новее центосовского 3.19.1. Новой версии можно ждать пол года. Изменено 2 декабря, 2014 пользователем aabc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 2 декабря, 2014 · Жалоба nuclearcat прибивание rcu_shed к одному ядру не дало особого эффекта. прибивание rcuos/x к ядрам только ухудшило ситуацию. Вероятно, причина не в этом, или не только в этом. А вообще, centos IMHO немного не та система, на которой можно выжимать все возможности из железа. А какие варианты? Gentoo и полная самостоятельная сборка всего и вся? aabc я попробовал все версии до 3.17.3 - ни одна не собирается под 504м ядром центоса. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 2 декабря, 2014 · Жалоба прибивание rcu_shed к одному ядру не дало особого эффекта. прибивание rcuos/x к ядрам только ухудшило ситуацию. Вероятно, причина не в этом, или не только в этом. потому что это не про то. А какие варианты? Gentoo и полная самостоятельная сборка всего и вся? aabc я попробовал все версии до 3.17.3 - ни одна не собирается под 504м ядром центоса. я бы попробовал взять ядро >=3.15, из-за этого Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tamahome Опубликовано 2 декабря, 2014 · Жалоба junjunk2, а много ли собирать? Имхо лучше Gentoo нет ничего на роутерах/натах Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 2 декабря, 2014 · Жалоба я бы попробовал взять ядро >=3.15, из-за этого Ух как интересно. У меня была сначала мысль поставить 3.17 main line, но я потом отверг ее. Сейчас склонен к тому, чтобы по крайней мере попробовать. Если сейчас на тестовой железке всё взлетит, ночью переставлю и попробую. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 2 декабря, 2014 · Жалоба aabc я попробовал все версии до 3.17.3 - ни одна не собирается под 504м ядром центоса. Действительно. Просто у меня на 2.6.32-358.18.1.el6.x86_64 собралось. Можно откатить ядро до 2.6.32-358.18.1.el6.x86_64 тогда, ради драйвера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 2 декабря, 2014 · Жалоба aabc спасибо за помощь, ночью подправлю rx_ring и посмотрю, как будет работать. Соответственно установку ядра 3.17 придется отложить, хотя и не надолго. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 2 декабря, 2014 · Жалоба я бы попробовал взять ядро >=3.15, из-за этого Ух как интересно. У меня была сначала мысль поставить 3.17 main line, но я потом отверг ее. Сейчас склонен к тому, чтобы по крайней мере попробовать. Если сейчас на тестовой железке всё взлетит, ночью переставлю и попробую. вообще, я в netdev вижу в последнее время много интересных фиксов. Drop performance in "raw": 11.3Mpps Drop performance in "raw" with ipset: 8Mpps With RCU locking, the RW-lock is gone. Drop performance in "raw" with ipset with RCU-locking: 11.3Mpps Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 3 декабря, 2014 · Жалоба После легких танцев с бубном вокруг драйвера ixgbe, получилось-таки его собрать под ядро 3.17.4. Соответственно сегодня буду смотреть, как ведет себя машинка с увеличенной до 4096 очередью, а ночью взлетит новое ядро с новым модулем и завтра уже будем смотреть, насколько интересно стало с новым nf_conntrack. Вообще, появилась дикая идея сделать back-port nf_conntrack в ядро 2.6.х, т.к. пока что видно, что оно показывает более высокую производительность в конкретно этой задаче NAT. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 3 декабря, 2014 · Жалоба Имхо лучше Gentoo нет ничего на роутерах/натах На роутерах/натах лучше вообще специализированные дистры, работающие в памяти и грузящиеся с мелкого DOM/USB flash. Мы LEAF юзаем/пилим под себя к примеру... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 3 декабря, 2014 · Жалоба Имхо лучше Gentoo нет ничего на роутерах/натах На роутерах/натах лучше вообще специализированные дистры, работающие в памяти и грузящиеся с мелкого DOM/USB flash. Мы LEAF юзаем/пилим под себя к примеру... То есть для роутера/ната лучше старая 486тушка, а не современный 8ядерный комп с 10G интеловыми карточками? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tamahome Опубликовано 3 декабря, 2014 · Жалоба NiTr0, сейчас цена ssd пренебрежительно мала, не вижу никакого смысла экономить на этом. Никто не говорит что собирать на каждой копии, сделать образ для каждой железки, и копировать за несколько минут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 3 декабря, 2014 · Жалоба Имхо лучше Gentoo нет ничего на роутерах/натах На роутерах/натах лучше вообще специализированные дистры, работающие в памяти и грузящиеся с мелкого DOM/USB flash. Мы LEAF юзаем/пилим под себя к примеру... Хотя не спорю, если есть время и люди, которые способны напилить туда драйверов (из описания я так понял, для интелловских карточек есть только e1000e и igb более-менее свежие), то возможно и будет прирост... Но имхо - это еще гемморойнее, нежели Gentoo. И опять же боязно в продакшн ставить такой сборник... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
