Проблема с загрузкой процессора CHR на 100% при использовании Xeon процессора с тактовой частотой 27 ГГц.

Вы пробовали выставить Latency Sensitivity: High в настройках виртуальной машины?

Автору оригинального сообщения — вы пробовали отключать Hyper-Threading? Для справки: Hyper-Threading — это встроенная функция многих новых процессоров Intel, представляющая собой полу-программную, полу-прошивочную, полу-аппаратную особенность, которая заставляет один процессор вести себя как будто их два. Если у вас многоядерный процессор, Hyper-Threading увеличивает количество видимых ядер вдвое.

Hyper-Threading использует внутренние прерывания процессора по времени, которые работают так:
#1 запускается Виртуальный процессор №1 из 2;
#2 через мгновение останавливается Виртуальный процессор №1;
#3 содержимое регистров процессора, используемых Виртуальным процессором №1, копируется в первую область памяти (попытка стека);
#4 содержимое второй области памяти копируется в регистры процессора для Виртуального процессора №2 (запись в стек);
#5 запускается Виртуальный процессор №2;
#6 через мгновение он останавливается;
#7 содержимое регистров Виртуального процессора №2 копируется во вторую область памяти (попытка стека);
#8 содержимое первой области памяти копируется обратно в регистры для Виртуального процессора №1 (запись в стек);
#9 переход к шагу №1 и цикл повторяется.

Проблема в том, что оба Виртуальных процессора вместе имеют суммарную производительность чуть меньше, чем обычный процессор без Hyper-Threading. Почему? Потому что процессор постоянно выполняет операции Pop и Push стека, что отнимает время, которое могло бы быть использовано на полезные вычисления.

Встроенный кэш процессора постоянно переобучается и переписывается, так как кэшируемая память теперь делится между двумя виртуальными процессорами. В процессоре без Hyper-Threading вероятность успешного попадания в кэш (Cache Hit) выше. А кэш работает на скорости процессора. При попадании в кэш процессор работает на полной скорости, а при промахе (Cache Miss) он замедляется до скорости памяти (с учётом возможных задержек).

Итого, чем больше попаданий в кэш, тем быстрее работает система. Если объём используемой операционной системой памяти или программ небольшой, можно приблизиться к 100-процентному попаданию в кэш, что значительно ускорит работу.

У Hyper-Threading есть свои плюсы и минусы. Если правильно подобрать железо и софт, система без Hyper-Threading может работать заметно быстрее.

В качестве информации: одна из причин, почему я предпочитаю современные процессоры Xeon с большим объёмом кэша:
А — более медленный Xeon с большим кэшем позволяет достигать почти 100% попаданий в кэш и работать почти всегда на максимальной тактовой частоте;
Б — более быстрый Xeon с маленьким кэшом часто сталкивается с промахами, в результате чего процессор работает со скоростью памяти плюс задержки, что снижает производительность.

В общем, когда выбираю компоненты для мощного компа, я всегда предпочитаю Xeon с максимальным кэшем, а уже потом обращаю внимание на тактовую частоту.

Том Джонс из Северного Айдахо

Помимо всего перечисленного, что я здесь написал... Если ваш CHR работает на гипервизоре (то есть на чем-то вроде VMware ESXi), есть несколько дополнительных фишек, которые можно использовать:

На физическом сервере удалите все ненужные устройства (CDROM, последовательные порты, параллельные порты, дисководы и т.д.).  
В BIOS на физическом сервере отключите все ненужные устройства (CDROM, последовательные порты, параллельные порты, дисководы и т.д.).  
В BIOS на физическом сервере переключите все настройки на производительность вместо стандартных режимов энергосбережения.  
На физическом сервере по возможности старайтесь, чтобы два устройства не использовали одинаковый прерывающий сигнал CPU. Например, если две сетевые карты используют один и тот же прерыватель, операционная система хоста тратит время, пытаясь определить, какое устройство требует внимания, и это снижает производительность процессора для выполнения других задач.  
В гипервизоре физического сервера переведите все виртуальные диски всех виртуальных машин в формат THIN.  
В гипервизоре физического сервера отключите логирование.  
По возможности используйте два физических сервера: один для важных и быстрых виртуальных задач, а второй — для всех прочих менее приоритетных гостевых операционных систем.  

Также...  
На виртуальной машине удалите все ненужные виртуальные устройства (CDROM, последовательные порты, параллельные порты, дисководы и т.д.).  
В виртуальном BIOS отключите все ненужные устройства (CDROM, последовательные порты, параллельные порты, дисководы и т.д.).  
По возможности используйте паравиртуальные устройства (драйверы устройств). Паравиртуальные устройства — это виртуальные устройства с драйверами, оптимизированными для более быстрой и эффективной работы в среде гипервизора. Например, в VMware ESXi такими устройствами являются сетевые карты “VMXNET-3” и контроллеры SCSI “VMware Paravirtual”.  
Если у вас есть 10-ядерный процессор Xeon (с отключённым Hyper-Threading), количество CPU, выделяемых всем гостевым операционным системам, должно быть не более 9. Избегайте перегрузки CPU и памяти. Перегрузка CPU и памяти заставляет физический гипервизор начинать свопинг.

Дорогой Том, да, я знал про настройку виртуалки, на самом деле мы использовали специализированную сетевую карту высокого класса, но всё равно без толку. Одна из моих задач загружает CPU хоста на 100% при 2G, но ситуация не меняется: с каждым разом к системе подключается больше пользователей, а передача данных не превышает 2G.

Ещё заметил одну проблему: приходит сообщение, что пакет 1522 не может быть отправлен через MTU больше 1500 на моём хосте, так как CHR L2 равен 0, а Mikrotik отключил возможность редактирования в этом разделе. Не понимаю, почему они не установили MTU на 10G L2 выше 10G синхронного интерфейса, а просто зашили 0 — это совсем непредсказуемо.

Я пробовал btest с тремя CCR и спокойно получал 3G по UDP, но при нагрузке пользователей всё ухудшается, как я уже говорил выше.

Это довольно интересно. Мне удалось добиться скорости выше 8 Гбит/с при маршрутизации между виртуальным CHR, запущенным на одном VMware ESXi сервере, и виртуальным x86 ROS, размещённым на совершенно другом VMware ESXi сервере — при этом два других виртуальных x86 сервера выполняли btest, где сессии btest маршрутизировались на уровне третьего слоя.

VMware ESXi сервер №1 — btest сервер (подключён через 10-гигабитный Ethernet к серверу №2)  
VMware ESXi сервер №2 — CHR маршрутизирует ненатированную LAN с сервера 1 на сервер 4 (через сервер 2)  
VMware ESXi сервер №3 — x86 ROS маршрутизирует ненатированную LAN с сервера 4 на сервер 1 (через сервер 2)  
VMware ESXi сервер №4 — x86 ROS система выполняет btest на x86 ROS на сервере №1

Всё подключено по 10-гигабитной сети.  
Все x86 ROS и CHR системы размещены на четырёх разных физических серверах VMware ESXi.  
Без NAT, без фаерволлов.  
Сессии btest маршрутизировались с сервера №4 на сервер №1 (никаких btest сессий в одной сети — так что маршрутизация была обязательной).

Мне удалось удерживать устойчивую скорость передачи UDP выше 8 Гбит/с.

North Idaho  
Tom Jones

Дорогой Том/эксперты, возможно, вы достигли такой пропускной способности на трафике L3 с помощью Btest, у меня тоже получается примерно 3G и более с нашими тремя CCR в роли клиента и CHR в роли сервера. Но в реальной эксплуатации CHR меня очень разочаровал при работе с туннельным трафиком. Я уже тестировал PPTP и PPPoE, как говорил раньше, CHR теряет пакеты и при использовании PCQ, и при Dynamic Simple Queue. Я проверил программное обеспечение гипервизора, там на основном интерфейсе ни одного сбоя пакетов не наблюдается — проверял на Esxi HOST. К тому же я использую сервер HP серии G8 с двумя восьмиядерными процессорами.