Jump to content
Калькуляторы

junjunk2

Пользователи
  • Content Count

    77
  • Joined

  • Last visited

About junjunk2

  • Rank
    Абитуриент

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Переписал модуль, избавился от глобального spin_lock - теперь должно масштабироваться намного лучше. Если кто-то может потестировать - был бы признателен. Из известных проблем - при большом количестве одновременно начинающихся сессий ISGd.pl не успевает вычитывать всё из nelink сокета и из-за этого могут сыпаться ошибки ipt_ISG: Lost packet during sending data to listener (err=-11) а так же может не вычитываться весь список сессий. над этим работаю - хочу переписать демона с перла на что-то более быстрое PS. Если кто-то будет обновлять репо - делайте git pull --rebase потому что я иногда у себя делаю rebase. Баги и фиче-реквесты можно пулять в проект в гитхабе
  2. Репозиторий Поддерживаются версии ядра до 5.2 включительно (скорее всего и все более новые, просто не проверял) Восстановил либу для матчера - ее не было в репозитории предыдущего поста Планирую провести серьезную оптимизацию кода - если кому-то будет интересно.
  3. Из сервисов - 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.
  4. Логируем через ipt_NETFLOW. В принципе по нагрузке вообще не видно, если использовать только nat events
  5. Не поднимается LACP с другой стороны тогда, что в принципе логично. Нагрузочное тестирование показало, что трафика в пике получилось протянуть 12,2 Гбит на драйвере teaming против 12.0 Гбит на драйвере bonding, что в принципе можно считать погрешностью измерений. В итоге вернулись назад на bonding из-за того, что не получилось равномерно распределять трафик, всегда был какой-нить перекос по портам
  6. Есть. но что в таком случае делать со стороны свитча?
  7. И в дополнение - не очень хорошо ведет себя этот драйвер в плане нагрузки по сравнению с bonding. Xeon E3 3.5Ггц 9.5 Гбит/с -- teaming: 81% CPU, bonding 73% CPU при прочих равных условиях. Видимо, буду выводить из работы, пока не прооптимизируют балансера. Ну или чуть позже сам посмотрю алгоритм выбора интерфейса и сравню его с bonding. Хотя, как я понял из описания, алгоритм работы драйвера (LACP + HASH ALGO) загружаются в разделяемую память модуля team при создании интерфейса в качестве BPF подпрограммы... поэтому заоптимизировать это дело будет сложно.
  8. Собрал teaming, запустил в работу... Сильно-сильно расстроил момент один - поднять LACP получилось совсем не сразу. Пришлось играться с приоритетами, иначе со стороны свитча порт был suspended. И сейчас так и не смог добиться нормальной балансировки исходящего трафика - на 2х портах перекос 40:60 ... если убрать из алгоритма MAC адреса, то вообще идет только по одному каналу. l3 или l4 - не имеет значения
  9. Отличная идея, спасибо! Я совсем не заметил teaming драйвер, потому что использовал для основы CentOS 6, куда бинарно накатывал новые ядра и новые драйвера, а для этой версии нет пакета teamd. Сейчас пересобрал пакет для CentOS 6, завтра проведу тестирование и отпишусь по результатам.
  10. Вот так у меня: [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
  11. 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 для анонса белых сетей и резервирования маршрутов к абонентам...
  12. EMR 3.0 прошивка 3.0.4.14

    Сегодня зашел под другим браузером (FireFox 44.0) - всё отобразилось как надо. Видимо, глюк в web-части прошивки. До этого пользовался FireFox 42.0
  13. день добрый. После обновления до версии 3.0.4.14 появилась следующая проблема - невозможно настроить исходящие порты на плате MainGbe, в списке их нет, кнопки добавить/удалить/изменить не активны. Хотя в мониторинге они видны и с карты на них поток выходит. Подскажите, как можно исправить?
  14. 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 ... пока адекватных мыслей, из-за чего так, у меня нет... может кто-нить объяснить,что это такое? ;)
  15. John_obn Судя по графику это входящий в машину трафик. Соответственно он откуда-то взялся. Неплохо было бы найти источник, т.к. сам по себе он не мог организоваться. Ну либо это баг счетчиков ядра, что, как мне кажется, маловероятно. По поводу Virtualization Tech - я несколько постов назад в этой теме писал по этому поводу. У меня тоже было выключено VT-d и включена эта опция - оверхед был порядка 10-15%.