Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Форум
    RouterOS
    Проблема с производительностью Mikrotik CHR

    Проблема с производительностью Mikrotik CHR

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Проблема с производительностью Mikrotik CHR, RouterOS
     
    ia2130
    Guest
    #1
    0
    28.08.2018 16:47:00
    У меня есть маршрутизатор Mikrotik CHR 6.42.7 на гипервизоре ESXi 6.0 u3 с лицензией P10, который подключён к нескольким подсетям. Все мои виртуальные машины используют адаптер VMXNET3 с пропускной способностью 10 Гбит/с, скорость между хостами в одной подсети (сети) составляет 4–5 Гбит/с, но я заметил, что при передаче трафика между подсетями скорость падает и становится около 2 Гбит/с.

    У меня довольно простая конфигурация Mikrotik:

    /interface ethernet  
    set [ find default-name=ether2 ] mtu=1500
    set [ find default-name=ether3 ] mtu=1500

    /ip address  
    add address=10.10.10.1/24 interface=ether2 network=10.10.10.0  
    add address=10.10.11.1/24 interface=ether3 network=10.10.11.0  

    Для замера скорости я использую iperf. И я не понимаю, почему так происходит, помогите, пожалуйста.
     
     
     
    shiyiqiang08
    Guest
    #2
    0
    11.12.2018 11:27:00
    Ты используешь virtio-net для своей виртуальной машины? Это может снизить нагрузку на процессор.
     
     
     
    TimRSA
    Guest
    #3
    0
    11.12.2018 12:58:00
    Я не вижу этой настройки, ты уверен, что она доступна в ESXi 6.0.0?
     
     
     
    TimRSA
    Guest
    #4
    0
    11.12.2018 09:42:00
    Привет, ребята, я новичок на этом форуме. Хотел узнать, у кого-нибудь улучшилась производительность после отключения гиперпотоков? Чтобы это сделать, мне придется остановить работу роутеров в продакшене. У нас есть роутер cloud core с 9 ядрами, который обрабатывает в 5 раз больше трафика, при этом загрузка ЦП достигает 40-50% в пиковые моменты. У меня есть 2 CHR-роутера с 8 ядрами на процессоре Xeon 2.6 ГГц, которые пропускают около 15 Мбит/с трафика на каждом интерфейсе (WAN и LAN), а загрузка CPU держится на уровне 15-25%. Мне кажется, это довольно много для такой конфигурации. Все эти машины – виртуальные, работают на ESXi 6.0.0. Также я использую VMXNET3, лицензия P1, и мне не нужно больше 1 Гбит/с. Правила файрвола минимальные – сбрасываем некорректные подключения и всё, что не совпадает с моими 11 разрешающими правилами. Нет NAT и Mangle правил. Очень хочу найти решение этой проблемы, буду благодарен за любые советы. Прикрепил пару скриншотов ниже.
     
     
     
    shiyiqiang08
    Guest
    #5
    0
    11.12.2018 13:05:00
    Я не уверен, но ты можешь проверить это онлайн. Я использую Virtualbox, и когда применяю virto-net, нагрузка на процессор уменьшается на 20%. Это технология виртуализации. Обычно виртуальные машины имеют такую функцию, которая значительно улучшает производительность сети и снижает нагрузку на CPU.
     
     
     
    TimRSA
    Guest
    #6
    0
    11.12.2018 13:53:00
    Спасибо, я попробую найти способ это сделать. Видел пост про настройку на ESXi — там рассказывается, как разрешить tx и rx использовать несколько процессоров, что помогает с очередями ввода-вывода. Ещё собираюсь провести тест пропускной способности между двумя CHR, хочу понять, откуда идёт нагрузка. Не думаю, что проблема на стороне фаервола, но попробую включить fast track и отключить Conntrack, чтобы снизить нагрузку.
     
     
     
    TomjNorthIdaho
    Guest
    #7
    0
    11.12.2018 16:01:00
    Re: Я тут подумал, у кого-нибудь улучшилась производительность после отключения гиперпоточности? ДА — очень даже. К тому же, на вашем физическом сервере-гипервизоре (у меня VMware ESXi) есть ещё пару приёмов, чтобы повысить пропускную способность.

    Настройте гипервизор на использование delayed_ack = 1 (вместо стандартного delayed_ack = 0).  
    Увеличьте размер сетевых буферов гипервизора — это помогает поднять пропускную способность.  
    Если используете NFS, отключите sync и поставьте delayed_ack = 1 на NFS-сервере.  

    Всегда оставляйте у гипервизора свободную нераспределённую оперативную память и как минимум один свободный CPU. Это даст ресурс для служебных задач гипервизора — снимков, копирования или перемещения хранилищ.  

    По возможности используйте 10-гигабитные физические сетевые карты.  
    По возможности используйте паравиртуализированные устройства (например, vmxnet-3).  

    И на физическом, и на виртуальных машинах отключайте и удаляйте максимально возможное количество устройств. Нужно минимизировать прерывания и освободить ресурсы.  

    North Idaho  
    Tom Jones
     
     
     
    TomjNorthIdaho
    Guest
    #8
    0
    11.12.2018 16:04:00
    Отключите гиперпоточность на физическом компьютере в BIOS.
     
     
     
    TimRSA
    Guest
    #9
    0
    12.12.2018 06:36:00
    Спасибо за обратную связь, попробую сделать так. Вчера вечером проверял пропускную способность между двумя роутерами, с LAN-интерфейса на LAN-интерфейс — получил чуть меньше 1 Гбит/сек в обе стороны, что приемлемо, при этом загрузка процессора была меньше 10%, что сбивает с толку. Пока не совсем понятно, в чем проблема — в фаерволе или в маршрутизации пакетов между двумя интерфейсами на разных подсетях. Буду дальше разбираться и поделюсь результатами. Ещё раз спасибо!
     
     
     
    TimRSA
    Guest
    #10
    0
    12.12.2018 08:55:00
    Небольшое обновление: я пока не менял настройки BIOS, однако мы используем эти маршрутизаторы для межсоединения с поставщиками голосовой связи. Я заметил, что включена опция SIP direct media. Раньше у меня уже были проблемы с этой настройкой, как думаешь, может ли она вызывать нагрузку? Мы пропускаем через эти маршрутизаторы только SIP-трафик.
     
     
     
    Cha0s
    Guest
    #11
    0
    20.01.2019 12:53:00
    Это (VoIP) объясняет высокий показатель пакетов при низкой пропускной способности, который я видел на твоих скриншотах. Если ты не используешь NAT, то помощник SIP direct media не нужен (и, насколько я понимаю, он даже не участвует в пересланном трафике без NAT). Кроме того, отслеживание соединений в целом при большом количестве соединений и/или высокой скорости пакетов может привести к высокой нагрузке. Если можешь, отключи его полностью, или если не нужно отслеживать VoIP-трафик, настрой правила no-track в Raw-таблице специально для этого трафика.

    Тест пропускной способности может показать высокие цифры при низком использовании CPU, потому что он использует всего несколько соединений и большие пакеты. А вот 14 тысяч пакетов в секунду в VoIP — это явно много одновременных звонков/соединений, а это гораздо тяжелее для отслеживания соединений.
     
     
     
    Paternot
    Guest
    #12
    0
    21.01.2019 00:59:00
    Это официальная рекомендация Intel, если используется виртуализация. HyperThreading в этом случае приносит больше вреда, чем пользы.
     
     
     
    sebastia
    Guest
    #13
    0
    21.01.2019 09:11:00
    Разве это не в основном из-за безопасности (Meltdown и тому подобное)?
     
     
     
    Paternot
    Guest
    #14
    0
    21.01.2019 10:11:00
    Нет. Это намного раньше того времени. Речь идет о производительности: для этого типа нагрузки лучше без HyperThreading.
     
     
     
    TomjNorthIdaho
    Guest
    #15
    0
    22.01.2019 17:10:00
    Зачем отключать hyper-threading? Hyper-Threading — это трюк процессора, позволяющий одному ядру работать будто два ядра. Немного технической информации о Hyper-Threading:

    Что реально происходит, когда Hyper-Threading включён:
    Программно настроенный прерывание SMI (System Management Interrupt) делает следующее:
    А) Останавливает процессор,
    В) Снимает стек (копирует содержимое регистров процессора во временную память),
    С) Затем помещает в стек (копирует содержимое другой временной памяти обратно в регистры процессора),
    D) Позволяет процессору продолжить работу,
    Е) Через несколько тактов происходит ещё одно SMI, которое повторяет процесс POP и PUSH стека, а потом восстанавливает исходные данные процессора.

    Этот цикл постоянно повторяется, создавая иллюзию, что одно ядро — это два. Есть две большие проблемы с Hyper-Threading:

    1. Hyper-Threading тратит тактовые циклы процессора на обработку SMI, которые могли бы использоваться для выполнения программ, если Hyper-Threading выключен.
    2. Hyper-Threading активно расходует встроенную кеш-память процессора и часто вызывает кеш-промахи (cache MISSes).

    Кеш-промах заставляет процессор замедляться до скорости доступа к оперативной памяти вместо быстрой встроенной кеш-памяти.

    Для более быстрой работы CHR на системе с Hyper-Визором (например, VMware ESXi):

    - Отключите Hyper-Threading,
    - Используйте физические 10-гигабитные сетевые карты (с 10-гигабитными коммутаторами),
    - Используйте паравиртуальные устройства (оптимизированные драйверы HyperVisor, такие как сетевые интерфейсы VMXNET-3 и, по возможности, также контроллеры SCSI “VMware Paravirtual”),
    - Удалите все ненужные устройства (например, CD-приводы, последовательные порты, дисководы для гибких дисков и т.п.),
    - Не перегружайте виртуальные машины физическими CPU и памятью,
    - Старайтесь оставить как минимум один свободный CPU,
    - По возможности перемещайте неважные виртуальные машины с невысокими требованиями к скорости на более медленные системы с Hyper-Визором, чтобы ядро вашей основной системы оставалось быстрым.
     
     
     
    Pirlet
    Guest
    #16
    0
    23.01.2019 11:18:00
    Привет, хочу вклиниться в эту ветку, потому что у нас такая же проблема. Не хочу захватывать тему, но, возможно, это даст больше информации о проблеме и поможет точнее определить причину.

    Наша конфигурация такая:  
    Сервер Tyan: GT62F-B8026 с прошивкой R3.00  
    Процессоры: AMD EPYC 7551P 32-ядерный  
    Гипервизор: VMware ESXi, 6.5.0, 7967591  
    Сетевые карты: Mellanox MT27630 (ConnectX-4 LX)  
    Хранилище: Full Flash Dorado 5000v3

    Следующее было протестировано и применено:  
    - SMT отключен  
    - Включена паравиртуализация  
    - Включён отложенный ACK на HBA  
    - Наследование отключено и ручное включение  
    - CPU — 8 сокетов с 1 ядром для этого тестового устройства  
    - Хранилище подключено через IDE  
    - VMXNet3 адаптер с включённым DirectIO

    Вот результат теста на собственном BTest:  
    (Это единственная ВМ, которая работает на этом хосте во время теста)  
    И нагрузка на CPU стабильна на уровне 12%
     
     
     
    TomjNorthIdaho
    Guest
    #17
    0
    23.01.2019 16:31:00
    Pirlet, к сведению — предполагаю, что у тебя запущен Mikrotik CHR (64-битный ROS). Внимание — мне кажется, что в твоей конфигурации не нужна «SCSI controller 0». Если я прав, то CHR вообще не поддерживает драйверы SCSI, а виртуальный жёсткий диск CHR на самом деле IDE. Удалив контроллер SCSI, ты освободишь немного ресурсов и как минимум прерывание. Вот моя конфигурация на моём CHR, который является одним из моих BGP-маршрутизаторов:
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры