Вопросы Теги

ЦП хоста не масштабирует частоту, когда гостю KVM нужен он

Если mkfs.xfs не установлен, затем Вы пропустили этот шаг в статье:

sudo apt-get install -y xfsprogs

Вы записали:

на моем экземпляре я должен был использовать/dev/xvdh и не/dev/sdh

Да, это - путь, который присоединил объемы, и эфемерное устройство хранения данных обнаруживаются на современных версиях Ubuntu на EC2. Статья немного устарела с названием устройства, но я все еще делаю все остальное, как описано в нем.

Раскрытие: Я написал ту статью.

8
01.12.2019, 15:59
3 ответа

Я нашел решение благодаря подсказке данным Nils и хорошей статьей.

Настройка ondemand ЦП регулятор DVFS

У ondemand регулятора есть ряд параметров для управления, когда он ударяет динамическое частотное масштабирование (или DVFS для динамического напряжения и частотного масштабирования). Те параметры расположены под sysfs деревом: /sys/devices/system/cpu/cpufreq/ondemand/

Одно из этого параметры up_threshold то, которые как имя предлагают, является порогом (единица является % ЦП, я не имею, узнают хотя, если это на базовые или объединенные ядра), выше которого ondemand регулятор вталкивает и начинает изменять динамично частоту.

Изменить его на 50% (например), с помощью sudo просто:
sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"

Если Вы - корень, еще более простая команда возможна:
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

Примечание: те изменения будут потеряны после следующей перезагрузки хоста. Необходимо добавить их к конфигурационному файлу, который читается во время начальной загрузки, как /etc/init.d/rc.local на Ubuntu.

Я узнал, что мой гость, VM, хотя используя много ЦП (80-140%) на хосте распределял нагрузку на оба ядра, таким образом, не одноядерный был выше 95%, таким образом ЦП, к моему раздражению, оставался в 800 МГц. Теперь с вышеупомянутым патчем, ЦП динамично изменяет его частота на ядро намного быстрее, которое удовлетворяет лучше моим потребностям, 50% кажется лучшим порогом для моего гостевого использования, Ваш пробег может варьироваться.

Дополнительно, проверьте, используете ли Вы HPET

Возможно, что некоторые применимые, которые неправильно реализуют таймеры, могли бы быть затронуты DVFS. Это может быть проблемой на хосте и/или гостевой среде, хотя хост может иметь некоторый замысловатый алгоритм, чтобы попытаться минимизировать это. Однако современный ЦП имеет более новый TSC (Счетчик Метки времени), которые независимы от текущей частоты ЦП/ядра, это: постоянный (constant_tsc), инвариант (invariant_tsc) или безостановочный (nonstop_tsc), см. эту статью Chromium о пересинхронизации TSC для получения дополнительной информации о каждом. Таким образом, если Ваш ЦП оборудован одним из этого TSC, Вы не должны вызывать HPET. Чтобы проверить, поддерживает ли Ваш хост ЦП их, используйте подобную команду (измените grep параметр на соответствующую функцию CPU, здесь мы тестируем на постоянный TSC):

$ grep constant_tsc /proc/cpuinfo

Если у Вас нет одного из этого современного TSC, Вы должны также:

  1. Активный HPET, это описано здесь после;
  2. Не используют ЦП DVFS, если у Вас есть какие-либо приложения в VM, которые полагаются на точную синхронизацию, которая является той, рекомендуемой Red Hat.

Безопасное решение состоит в том, чтобы включить таймеры HPET (см. ниже для получения дополнительной информации), они медленнее для запросов, чем TSC (TSC находятся в ЦП, по сравнению с HPET находятся в материнской плате), и возможно не имеет точный (HPET> 10 МГц; TSC часто макс. тактовая частота ЦП), но они намного более надежны особенно в конфигурации DVFS, где каждое ядро могло иметь различную частоту. Linux достаточно умен для использования наилучшего имеющегося таймера, он будет полагаться сначала на TSC, но, если найдено слишком ненадежный, он будет использовать HPET один. Эта работа, хорошая на хосте (чистый металл) системы, но из-за не вся информация, правильно экспортируемая гипервизором, это - больше проблемы для гостя VM для обнаружения плохого поведения TSC. Прием должен затем вызвать для использования HPET в госте, хотя Вам был бы нужен гипервизор для предоставления доступа к этому источнику часов доступным для гостей!

Ниже Вас может найти, как настроить и/или включить HPET на Linux и FreeBSD.

Linux конфигурация HPET

HPET или таймер события высокой точности, является аппаратным таймером, который можно найти в большей части товарного ПК с 2005. Этот таймер может использоваться эффективно современной ОС (ядро Linux поддерживает его с тех пор 2.6, стабильная поддержка на FreeBSD с тех пор последний 9.x, но было представлено в 6,3) предоставлять последовательную синхронизацию неизменно управлению питанием процессора. Это позволяет создавать также более легкие реализации планировщика галочки меньше.

В основном HPET похож на защитное ограждение, которое, даже если хост имеет DVFS активный, будут менее затронуты хост и гостевые события синхронизации.

Существует хорошая статья от IBM относительно включения HPET, это объясняет, как проверить, какой аппаратный таймер Ваше ядро использует, и которые доступны. Я предоставляю здесь краткий обзор:

Проверка доступного аппаратного таймера (таймеров):
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Проверка текущего активного таймера:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

Более простой способ вызвать использование HPET, если Вы имеете его в наличии, состоит в том, чтобы изменить Ваш загрузчик, чтобы попросить включать его (начиная с ядра 2.6.16). Эта конфигурация является иждивенцем распределения, поэтому обратитесь к своей собственной документации распределения для установки ее правильно. Необходимо включить hpet=enable или clocksource=hpet на строке начальной загрузки ядра (это снова зависит от версии ядра или распределения, я не нашел когерентной информации).
Это удостоверяется, что гость использует таймер HPET.

Примечание: на моем ядре 3.5, Linux кажется погрузке автоматически hpet таймером.

Гость FreeBSD конфигурация HPET

На FreeBSD можно проверить, какие таймеры доступны путем выполнения:
sysctl kern.timecounter.choice

В настоящее время выбираемый таймер может быть проверен с:
sysctl kern.timecounter.hardware

FreeBSD 9.1, кажется, автоматически предпочитает HPET по другому поставщику таймера.

Todo: как вызвать HPET на FreeBSD.

Гипервизор экспорт HPET

KVM, кажется, экспортирует HPET автоматически, когда хост имеет поддержку его. Однако для гостя Linux они предпочтут другие автоматически экспортируемые часы, которые являются kvm-тактовыми (паравиртуализированная версия хоста TSC). Некоторые люди сообщают о проблеме с предпочтительными часами, Ваш пробег может варьироваться. Если Вы хотите вызвать HPET в госте, обратитесь к вышеупомянутому разделу.

VirtualBox не экспортирует часы HPET в гостя по умолчанию, и нет никакой опции сделать так в GUI. Необходимо использовать командную строку и удостовериться, что VM выключается. команда:

./VBoxManage modifyvm "VM NAME" --hpet on

Если гость продолжает выбирать другой источник, чем HPET после вышеупомянутого изменения, обратитесь к вышеупомянутому разделу, как вынудить ядро использовать часы HPET в качестве источника.

10
27.01.2020, 20:10
  • 1
    является там реальным приложением для этого, или это - просто одноразовый прием? –  ewwhite 10.02.2013, 13:52
  • 2
    @ewwhite, что Вы подразумеваете под одноразовым приемом? Открытие состоит в том, что DVFS (динамическое напряжение и частотное масштабирование) на самом деле работает с KVM и хостом Linux. Загрузка ЦП процесса 80-140% была, вероятно, распределена на обоих ядрах равномерно, таким образом, никакое ядро не достигало 95%-го порога по умолчанию, который приведет к частотному масштабированию. Ничего не изменяя, если я действительно создаю единственный процесс потока, который использует 100% одного ядра в VM, затем многократное масштабирование ударяют, таким образом, я просто не видел его. Что касается реального приложения DVFS, это об экономии электроэнергии и уменьшенной температуры. –  Huygens 10.02.2013, 18:37
  • 3
    @ewwhite Вы имеете в виду, "является там приложением, которое настраивает это значение для меня?" Я думаю, что ответ нет. Иначе кто-то уже вставил бы разумное значение по умолчанию. 95 определенно не разумно здесь. –  Michael Hampton 10.02.2013, 20:12
  • 4
    Нет, есть ли приложение (причина) хотеть использовать это в виртуализированной установке? –  ewwhite 10.02.2013, 20:15
  • 5
    Причина: Я не хочу, чтобы ЦП работал в полной скорости по нескольким причинам: потребляемая мощность выше, температура выше, носите быстрее, FAN вращаются быстрее (больше питания и более быстрого износа), требует более крупной батареи UPS. –  Huygens 10.02.2013, 22:11

Это не гость, который инициировал высококлассное - хост должен сделать это. Таким образом, необходимо понизиться согласно пороговому уровню на хосте.

4
27.01.2020, 20:10
  • 1
    Интересный, Вы, оказалось бы, знали бы, как сделать это? –  Huygens 09.02.2013, 23:02
  • 2
    @Huygens Обычно это сделано через своего рода cpufrequency-демона. Существует файл конфигурации для того демона, где Вы можете изменить его поведение и/уменьшать масштаб оцениваете. Не уверенный, где точно это расположено в Ubuntu. –  Nils 09.02.2013, 23:13
  • 3
    Вы решили его, по умолчанию (на Ubuntu, по крайней мере), порог составляет 95%, я не уверен, ли это на ЦП все же. Путем опущения его на 50% у меня есть ожидаемое поведение! На Ubuntu Вы сделали бы это как это: sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold" Источник: ivanlam.info/blog/2012/04/26 / … –  Huygens 09.02.2013, 23:36
  • 4
    @Huygens у меня была эта проблема на CentOS - там файл конфигурации для cpuspeed расположен в/etc/sysconfig/cpuspeed для внесения такого изменения постоянным. В моем случае у меня был VBox-VM со всего одним (физически двухъядерным) ЦП. Я должен был понизить уровень к 45% для получения высококлассного эффекта в VM. –  Nils 17.02.2013, 22:45

на хосте kvm CPU похож на процесс. Масштабирующийся механизм не следит за процессами, только полным потреблением ресурсов ЦП.

и это - обычно лучшая практика для отключения масштабирования/регулировки/и т.д. CPU при выполнении VMs

2
27.01.2020, 20:10
  • 1
    Странно, когда я действительно возглавляю на хосте I, видят, что полное потребление ресурсов ЦП составляет приблизительно 80-130%, (btw все использованные kvm и процессами ksm), но не частотное масштабирование. Когда я выполняю другие процессы, которые используют центральные процессоры, ondemand регулятор быстро умирает! Единственная разница, которую я принимаю, - то, что процесс kvm использует некоторую технологию виртуализации (AMD svm в моем случае), который мог сделать это, регулятор хоста не реагирует. И гостю не удается запросить базовый hw масштабироваться, я предполагаю, хотя на чистом металле он работал. –  Huygens 09.02.2013, 10:58
  • 2
    Вы могли обратиться к детализации статьи, почему частотное масштабирование не является лучшей практикой при выполнении VMs? Мне любопытно понять почему. Red Hat, кажется, поддерживает это, видит главу 6.2.4 (была проблема в более раннем выпуске, чем RHEL 5.3), access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux / … –  Huygens 09.02.2013, 10:59
  • 3
    , я не имею никаких статей удобными, но думаю о том, что виртуализация для, и как он работает. Вы планируете использовать недостаточно использованную машину путем загрузки его VMs. VMs должен быть стабильным и предсказуемым. Вы думаете ЦП, которому настройки по частоте под VMs помогут с этим? И говоря о лучшей практике, человечность, поскольку хост virt не является хорошей идеей, по моему опыту –  dyasny 09.02.2013, 17:55
  • 4
    Можно переместить VMs между другим хостом, иногда отличающимся по частоте. Вещью, которая должна быть устойчивой в этом случае, являются функции, выставленные ЦП от хоста, так, чтобы, если SSE4 выставляется и Ваше приложение использовало его, после того как Вы мигрируете на ЦП, который не поддерживает его, Ваш VM не отказывает. Так частотное масштабирование, которое является большим фактором в смягчении потребляемой мощности, не должна быть проблема. Я погуглил его и не нашел статьи, упомянув это. –  Huygens 09.02.2013, 18:23
  • 5
    Что касается распределения, я упомянул Ubuntu как проблематичную, потому что это. И на SF и на других сайтах, я продолжаю видеть, что люди сообщают, что KVM связал проблемы, которые мне никогда не удается воспроизвести на Fedora или RHEL. Не стесняйтесь не соглашаться, я не продолжаю в flamewar здесь. –  dyasny 09.02.2013, 22:10

Теги

Похожие вопросы