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

junjunk2

Пользователи
  • Публикации

    75
  • Зарегистрирован

  • Посещение

О junjunk2

  • Звание
    Абитуриент
  1. Linux NAT

    Из сервисов - NAT, ipt_NETFLOW nat events, немного правил в ipset. От Xeon E3-1270v3 отказались в пользу Xeon E5-1650 v2. Сеть на машинах - Intel X520 - 2 порта в LACP, драйвер bonding На Е3 пиковые значения - 12Гбит/с 1.5Mpps, при этом все ядра в 100% нагрузки и начинаются дропы на интерфейсах. На Е5 получилось утилизировать оба порта практически в полку, по графикам 19.5 Гбит/с, 2.2Mpps загрузка 96-98% на всех ядрах, редкие незначительные дропы, но есть увеличение Latency, связанное с упиранием портов в полку по трафику. Ядро Linux 4.1.23, немного подтюнено, драйвер 4.3.15, DCA работает, Flow Director отключен, LRO выпилен на этапе сборки, UDP хэшинг по портам включен, Flow control выключен Эффективность двухпроцессороной системы под сомнением, т.к. контроллер PCI-Ex сейчас находится на процессоре, соответственно при использовании одной карты получается кросс-NUMA передача трафика и не самая эффективня обработка. Если действительно не будет хватать процессора, то лучше рассмотреть вариант с большим количеством ядер в одном package.
  2. Linux NAT

    Логируем через ipt_NETFLOW. В принципе по нагрузке вообще не видно, если использовать только nat events
  3. Linux NAT

    Не поднимается LACP с другой стороны тогда, что в принципе логично. Нагрузочное тестирование показало, что трафика в пике получилось протянуть 12,2 Гбит на драйвере teaming против 12.0 Гбит на драйвере bonding, что в принципе можно считать погрешностью измерений. В итоге вернулись назад на bonding из-за того, что не получилось равномерно распределять трафик, всегда был какой-нить перекос по портам
  4. Linux NAT

    Есть. но что в таком случае делать со стороны свитча?
  5. Linux NAT

    И в дополнение - не очень хорошо ведет себя этот драйвер в плане нагрузки по сравнению с bonding. Xeon E3 3.5Ггц 9.5 Гбит/с -- teaming: 81% CPU, bonding 73% CPU при прочих равных условиях. Видимо, буду выводить из работы, пока не прооптимизируют балансера. Ну или чуть позже сам посмотрю алгоритм выбора интерфейса и сравню его с bonding. Хотя, как я понял из описания, алгоритм работы драйвера (LACP + HASH ALGO) загружаются в разделяемую память модуля team при создании интерфейса в качестве BPF подпрограммы... поэтому заоптимизировать это дело будет сложно.
  6. Linux NAT

    Собрал teaming, запустил в работу... Сильно-сильно расстроил момент один - поднять LACP получилось совсем не сразу. Пришлось играться с приоритетами, иначе со стороны свитча порт был suspended. И сейчас так и не смог добиться нормальной балансировки исходящего трафика - на 2х портах перекос 40:60 ... если убрать из алгоритма MAC адреса, то вообще идет только по одному каналу. l3 или l4 - не имеет значения
  7. Linux NAT

    Отличная идея, спасибо! Я совсем не заметил teaming драйвер, потому что использовал для основы CentOS 6, куда бинарно накатывал новые ядра и новые драйвера, а для этой версии нет пакета teamd. Сейчас пересобрал пакет для CentOS 6, завтра проведу тестирование и отпишусь по результатам.
  8. Linux NAT

    Вот так у меня: [root@nat4 ~]# cat /proc/cmdline ro root=UUID=9e64fd75-d90b-48d2-b307-ffa216732fd6 LANG=en_US.UTF-8 rd_NO_LUKS rd_MD_UUID=12b89c06:102410f9:aef705e9:c174a513 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=ru rd_NO_LVM rd_NO_DM rhgb quiet intel_idle.max_cstate=0 processor.max_cstate=1
  9. Linux NAT

    nuclearcat покопался. irq_entries_start действительно вообще не функция, а массив векторов прерываний. почему этот символ всплывает в perf - пока не понятно. в развернутом виде выглядит вот так: - 2.43% 2.43% [kernel] [k] irq_entries_start - irq_entries_start - 84.51% arch_cpu_idle cpuidle_idle_call cpu_idle_loop вообще не ясно, к чему бы это... Так же выяснил, что при довольно большой нагрузке появляется _raw_spin_lock который в sch_direct_xmit -> _dev_queue_xmit -> _bond_queue_xmit, соответственно драйвер бондинга активно использует spinlock, что есть крайне нехорошо... вот теперь думаю, как мне избавиться от бондинга, зарулив трафик в два разных интерфейса и при этом еще оставив bgp для анонса белых сетей и резервирования маршрутов к абонентам...
  10. EMR 3.0 прошивка 3.0.4.14

    Сегодня зашел под другим браузером (FireFox 44.0) - всё отобразилось как надо. Видимо, глюк в web-части прошивки. До этого пользовался FireFox 42.0
  11. EMR 3.0 прошивка 3.0.4.14

    день добрый. После обновления до версии 3.0.4.14 появилась следующая проблема - невозможно настроить исходящие порты на плате MainGbe, в списке их нет, кнопки добавить/удалить/изменить не активны. Хотя в мониторинге они видны и с карты на них поток выходит. Подскажите, как можно исправить?
  12. Linux NAT

    nuclearcat Нашел платформу под Е3, в которой карта работает вот так: DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset- MaxPayload 256 bytes, MaxReadReq 512 bytes Перепрофилировал ;) запустил с нагрузкой для сравнения - выигрыша относительно тех, у кого MaxPayload 128 bytes, никакого. Однако, на этой платформе при большой нагрузке в perf top появляется irq_entries_start, как на Е5 ... пока адекватных мыслей, из-за чего так, у меня нет... может кто-нить объяснить,что это такое? ;)
  13. Linux NAT

    John_obn Судя по графику это входящий в машину трафик. Соответственно он откуда-то взялся. Неплохо было бы найти источник, т.к. сам по себе он не мог организоваться. Ну либо это баг счетчиков ядра, что, как мне кажется, маловероятно. По поводу Virtualization Tech - я несколько постов назад в этой теме писал по этому поводу. У меня тоже было выключено VT-d и включена эта опция - оверхед был порядка 10-15%.
  14. Linux NAT

    John_obn на интерфейсе p1p4 хорошо видно увеличение трафика и явно аномальное увеличение conntrack прям перед падением у меня аналогично было, кроме увеличения conntrack, т.к. трафик дропался
  15. Linux NAT

    John_obn очень интересное поведение. причем интересно оно тем, что у меня произошло тоже самое минут на 10-15 раньше, чем на ваших графиках. Так же спонтанно поднялся трафик где-то на 2Гбит/с, 0.3Mpps и один NAT сервер пропал. Правда, в логи он не успел ничего записать, поэтому не могу сказать, на чем упал. Но подозрение на пакеты с флагом фрагментов есть и обоснованное. Патч, представленный по ссылке, применен и в 4.1.16, именно эта версия у меня стоит на "упавшем" серваке. Однако, после этого были еще патчи, частично возвращающие функционал и исправляющие еще один race condition и memory leak. Попробую сделать back port для 4.1.16 и применить у себя