Vcpu что это в компьютере

Обновлено: 07.07.2024

В связи с наличием на наших серверах виртуальной платформы патчей, закрывающих процессорные уязвимости Meltdown\Spectre, изменения конфигурации, рекомендованные Vmware, ограничивают количество виртуальных ядер, которые может использовать гостевая виртуальная машина. Применительно к большинству существующих физических серверов это ограничение – 20 vCPU для одной виртуальной машины.

Просим руководствоваться данным значением при развертывании ВМ.

Разница между ядрами и нитями

Важно понимать разницу между потоком обработки и ядром процессора. Процессоры будут иметь установленное количество ядер, которые обрабатывают выполнение программ. Но даже очень интенсивные задачи не используют 100% ЦП все время; Программы часто должны ожидать чтения памяти из кэша L3, ОЗУ и дисков и часто засыпают, ожидая поступления данных. В течение этого времени ядро ЦП неактивно.

Решение этой проблемы называется «гиперпоточность» или «одновременная многопоточность». Вместо того, чтобы запускать один набор задач за один раз, ЦП может обрабатывать несколько потоков. В настоящее время почти каждый высокопроизводительный процессор от Intel или AMD поддерживает два потока на ядро.

В зависимости от приложения, гиперпоточность может дать теоретическое ускорение на 100%, если оба потока ожидают чтения памяти и не конфликтуют друг с другом. В большинстве случаев гиперпоточность дает увеличение скорости примерно на 30% по сравнению с отсутствием гиперпоточности. Однако в некоторых случаях, когда два потока закреплены на 100% и работают на одном и том же ядре, это может вызвать замедление, поскольку они сражаются за ресурсы ЦП.

Что делает vCPU?

vCPU примерно сопоставимы с одним потоком обработки, но это не совсем справедливое сравнение.

Скажем, вы арендуете c5.large экземпляр от AWS с 2 виртуальными ЦП. Ваше приложение будет работать вместе со многими другими на одном большом сервере. Вы можете арендовать весь сервер с AWS Bare Metal экземпляр, который дает вам прямой доступ к процессору. Если вы арендуете что-то меньшее, чем это, ваш доступ управляется через AWS Nitro,

Скорость обработки vCPU будет больше зависеть от реального оборудования, на котором он работает. Большинство серверных процессоров будут Intel Xeons, поскольку они составляют большую часть рынка. Серверы нижнего уровня могут работать на более старом оборудовании, которое немного устарело по современным стандартам. В экземплярах AWS T3a используются процессоры AMD EPYC с большим количеством ядер, они работают немного медленнее, но стоят дешевле из-за того, что аппаратное обеспечение значительно дешевле на ядро.

Бустабильные экземпляры

Экземпляры AWS T2 и T3 являются «пакетными», которые больше подходят для приложений, которые не должны работать на 100% все время.

Например, t3.micro Экземпляр имеет 2 виртуальных ЦП, но его базовая скорость составляет 10% от нормального виртуального ЦП. На самом деле, t3.micro на самом деле имеет только 0,2 vCPU, что на самом деле, как Google Cloud Platform рекламирует их f1-micro экземпляры,

Но t3.micro в целом не на 90% медленнее; он может превышать базовую скорость в течение коротких периодов времени, очень похоже на то, как работает турбо частота на обычном компьютере. За исключением того, что ограничивающим фактором здесь являются не термики, а то, сколько вы готовы заплатить.

За каждый час работы экземпляра ниже базовой скорости вы накапливаете кредиты ЦП, которые используются для взрыва экземпляра за одну минуту. t3.micro В частности, экземпляр накапливает 6 кредитов ЦП в час, что он работает ниже базовой скорости. Но когда требуется вычислительная мощность, кредиты ЦП расходуются на работу, превышающую базовую скорость.

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

10.02.2020

Hyper-V, KVM, VMWare, Windows 10, Виртуализация

комментария 2

При создании виртуальных машин на различных гипервизорах (VMWare, KVM, Hyper-V и т.д.) вы можете обратить внимание, что иногда виртуальная машина может не видеть все выделенные ей виртуальные ядра (vCPU). В нашем случае виртуальной машине на KVM были выделены 8 vCPU, на нее установлена Windows 10. Однако Windows определяла эти ядра как отдельные процессоры, из которых можно использовать только 2 vCPU.

Виртуальная машина Windows 10 не видит все ядра

Если открыть диспетчер устройств Windows, можно убедится, что все выделенные ядра видны в качестве 8 отдельных виртуальных процессоров типа QEMU Virtual CPU version 2,5.

При этом в свойствах Windows 10 (Computer -> Properties) и в Task Manage видно, что на компьютере доступны только 2 процессора QEMU Virtual CPU.

То есть сколько бы вы не добавили виртуальных ядер, Windows 10 все равно сможет использовать только два. При этом соседний виртуальный сервер с Window Server 2016 на этом же гипервизоре видит все 16 выделенных ему vCPU.

Количество поддерживаемых процессоров в Windows 10

Проблема заключается в том, что в десктопных редакциях Windows (Windows 10/8.1/7) есть ограничение на максимальное количество физических процессоров (сокетов), которое компьютер может использовать:

Windows 10 Home – 1 CPU
Windows 10 Professional – 2 CPU
Windows 10 Workstation – до 4 CPU
Windows Server 2016 – до 64 CPU

Однако это ограничение не распространяется на ядра. Т.е. для повышения производительности вы можете использовать процессор с большим количеством ядер. Большинство гипервизоров умеют предоставлять vCPU в виде процессоров, процессорных ядер или даже потоков. Т.е. вместо 8 виртуальных CPU вы можете предоставить vCPU в виде 2 сокетов по 4 ядра в каждом. Рассмотрим, как в различных системах виртуализации выделить виртуальные процессоры в виде ядер и как это связать с архитектурой NUMA, использующейся в современных процессорах.

Управление виртуальными ядрами и vCPU в KVM

В моей виртуальной машине KVM c Windows 10, все назначенные виртуальные ядра считаются отдельными процессорами.

Выключите виртуальную машину:

Особенности управления ВМ в KVM из консоли сервера с помощью virsh.

Выведите текущую XML конфигурацию виртуальной машины KVM:

Нам интересен блок с описанием процессоров:

Как видим, у нас указано просто 8 vCPU. Изменим конфигурацию:

И после </features> добавим:

Также в свойства системы теперь стал отображаться физический процессор хоста Intel(R) Xeon(R) Silver 4114 CPU, а не виртуальный.

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

Настройка виртуальных процессоров и количества ядер в VMWare

Вы можете изменить способ презентации vCPU для виртуальной машины VMWare из интерфейса vSphere Client.

Выключите ВМ и откройте ее настройки;
Разверните секцию CPU;
Изменим конфигурацию ВМ так, чтобы гостевая ОС видела 2 процессора по 4 ядра. Измените значение Cores per Socket на 4. Это означает, что гостевая ОС будет видеть два четырех –ядерных процессора (2 сокета по 4 ядра);
Сохраните изменения и запустите ВМ.

Архитектура NUMA и виртуальные vCPU

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

При назначении ядер на сокете учитывайте наличие NUMA архитектуры (используется в большинстве современных CPU). Не рекомендуется назначать вашей ВМ количество ядер на сокет (и общее количество vCPU) больше, чем доступно ядер на вашем физическом сокете/процессоре (ноде NUMA). При размещении на одной физической ноде NUMA, виртуальная машина сможет использовать быструю локальную RAM, доступную на конкретной ноде NUMA. Иначе для выполнения операции процессам придется ждать ответа от другой ноды NUMA (что несколько более долго).

Если вы назначаете для ВМ два отдельных виртуальных сокета, то гипервизор может их запускать на разных нодах NUMA. Что не лучшим образом скажется на производительности ВМ.

Если количество требуемых vCPU превышает количество ядер на 1 физическом сокете (ноде NUMA), нужно создать несколько виртуальных сокетов (процессоров) с необходимым количество ядер. Также не желательно использовать нечетное количество процессоров (лучше добавить 1 vCPU)

Это позволит сохранить производительность виртуальной машины.

Требуемое количество vCPU	Количество виртуальных сокетов в настройках ВМ	Количество ядер на виртуальном процессоре в настройках ВМ
1	1	1
……
10	1	10
11	Не оптимально
12	2	6
……
20	2	10

Например, ВМ с Microsoft SQL Server 2016 Enterprise Edition 16 vCPU в конфигурации 8 сокетов по 2 ядра будет работать хуже, чем в конфигурации 2 сокета по 8 ядер.

Также не забывайте, что некоторые приложения лицензируются по физическим сокетам (так было в старых версиях SQL Server). Иногда вам просто выгоднее лицензировать один многоядерный процессор, чем несколько процессоров с меньшим количеством ядер.

Если вы администрируете виртуальную инфраструктуру на базе VMware vSphere (или любого другого стека технологий), то наверняка часто слышите от пользователей жалобы: «Виртуальная машина работает медленно!». В этом цикле статей разберу метрики производительности и расскажу, что и почему «тормозит» и как сделать так, чтобы не «тормозило».

Буду рассматривать следующие аспекты производительности виртуальных машин:

Для анализа производительности нам понадобятся:

Немного теории

В ESXi за работу каждого vCPU (ядра виртуальной машины) отвечает отдельный процесс – world в терминологии VMware. Также есть служебные процессы, но с точки зрения анализа производительности ВМ они менее интересны.

Процесс в ESXi может находиться в одном из четырех состояний:

Run – процесс выполняет какую-то полезную работу.
Wait – процесс не выполняет никакой работы (idle) либо ждет ввода/вывода.
Costop – состояние, которое возникает в многоядерных виртуальных машинах. Оно возникает, когда планировщик CPU гипервизора (ESXi CPU Scheduler) не может запланировать одновременное исполнение на физических ядрах сервера всех активных ядер виртуальной машины. В физическом мире все ядра процессора работают параллельно, гостевая ОС внутри ВМ рассчитывает на аналогичное поведение, поэтому гипервизору приходится замедлять ядра ВМ, у которых есть возможность закончить такт быстрее. В современных версиях ESXi планировщик CPU использует механизм, который называется relaxed co-scheduling: гипервизор считает разрыв между самым «быстрым» и самым “медленным" ядром виртуальной машины (skew). Если разрыв превышает определенный порог, «быстрое» ядро переходит в состояние costop. Если ядра ВМ проводят много времени в этом состоянии, это может вызвать проблемы с производительностью.
Ready – процесс переходит в данное состояние, когда у гипервизора нет возможности выделить ресурсы для его исполнения. Высокие значения ready могут вызвать проблемы с производительностью ВМ.

Основные счетчики производительности CPU виртуальной машины

CPU Usage, %. Показывает процент использования CPU за заданный период.

Как анализировать? Если ВМ стабильно использует CPU на 90% или есть пики до 100%, то у нас проблемы. Проблемы могут выражаться не только в «медленной» работе приложения внутри ВМ, но и в недоступности ВМ по сети. Если система мониторинга показывает, что ВМ периодически отваливается, обратите внимание на пики на графике CPU Usage.

Есть стандартный Аlarm, который показывает загрузку CPU виртуальной машины:

Что делать? Если у ВМ постоянно зашкаливает CPU Usage, то можно задуматься об увеличении количества vCPU (к сожалению, это не всегда помогает) или переносе ВМ на сервер с более производительными процессорами.

CPU Usage in Mhz

В графиках на vCenter Usage в % можно посмотреть только по всей виртуальной машине, графиков по отдельным ядрам нет (в Esxtop значения в % по ядрам есть). По каждому ядру можно посмотреть Usage in MHz.

Как анализировать? Бывает, что приложение не оптимизировано под многоядерную архитектуру: использует на 100% только одно ядро, а остальные простаивают без нагрузки. Например, при дефолтных настройках бэкапа MS SQL запускает процесс только на одном ядре. В итоге резервное копирование тормозит не из-за медленной скорости дисков (именно на это изначально пожаловался пользователь), а из-за того, что не справляется процессор. Проблема была решена изменением параметров: резервное копирование стало запускаться параллельно в несколько файлов (соответственно, в несколько процессов).

Пример неравномерной нагрузки ядер.

Также бывает ситуация (как на графике выше), когда ядра нагружены неравномерно и на некоторых из них есть пики в 100%. Как и при загрузке только одного ядра, alarm по CPU Usage не сработает (он по всей ВМ), но проблемы с производительностью будут.

Что делать? Если ПО в виртуальной машине нагружает ядра неравномерно (использует только одно ядро или часть ядер), нет смысла увеличивать их количество. В таком случае лучше переместить ВМ на сервер с более производительными процессорами.

Также можно попробовать проверить настройки энергопотребления в BIOS сервера. Многие администраторы включают в BIOS режим High Performance и тем самым отключают технологии энергосбережения C-states и P-states. В современных процессорах Intel используется технология Turbo Boost, которая увеличивает частоту отдельных ядер процессора за счет других ядер. Но она работает только при включенных технологиях энергосбережения. Если мы их отключаем, то процессор не может уменьшить энергопотребление ядер, которые не нагружены.

VMware рекомендует не отключать технологии энергосбережения на серверах, а выбирать режимы, которые максимально отдают управление энергопотреблением гипервизору. При этом в настройках энергопотребления гипервизора нужно выбрать High Performance.

Если у вас в инфраструктуре отдельные ВМ (или ядра ВМ) требуют повышенную частоту CPU, корректная настройка энергопотребления может значительно улучшить их производительность.

CPU Ready (Readiness)

Если ядро ВМ (vCPU) находится в состоянии Ready, оно не выполняет полезную работу. Такое состояние возникает, когда гипервизор не находит свободное физическое ядро, на которое можно назначить процесс vCPU виртуальной машины.

Как анализировать? Обычно если ядра виртуальной машины находятся в состоянии Ready больше 10% времени, то вы заметите проблемы с производительностью. Проще говоря, больше 10% времени ВМ ждет доступности физических ресурсов.

В vCenter можно посмотреть 2 счетчика, связанных с CPU Ready:

Значения счетчика Ready можно посмотреть также в исторической перспективе. Это полезно для установления закономерностей и для более глубокого анализа проблемы. Например, если у виртуальной машины начинаются проблемы с производительностью в какое-то определенное время, можно сопоставить интервалы повешенного значения CPU Ready с общей нагрузкой на сервер, где данная ВМ работает, и принять меры по снижению нагрузки (если DRS не справился).

Ready в отличие от Readiness показывается не в процентах, а миллисекундах. Это счетчик типа Summation, то есть он показывает, сколько времени за период измерения ядро ВМ находилось в состоянии Ready. Перевести данное значение в проценты можно по несложной формуле:

(CPU ready summation value / (chart default update interval in seconds * 1000)) * 100 = CPU ready %

Например, для ВМ на графике ниже пиковое значение Ready на всю виртуальную машину получится следующим:

При подсчете значения Ready в процентах стоит обращать внимание на два момента:

Значение Ready по всей ВМ – это сумма Ready по ядрам.
Интервал измерения. Для Real-time – это 20 секунд, а, например, на дневных графиках – это 300 секунд.

Рассчитаем Ready на основе данных из графика ниже. (324474/(20*1000))*100 = 1622% на всю ВМ. Если смотреть по ядрам получится уже не так страшно: 1622/64 = 25% на ядро. В данном случае обнаружить подвох довольно просто: значение Ready нереалистичное. Но если речь идет о 10–20% на всю ВМ с несколькими ядрами, то по каждому ядру значение может быть в пределах нормы.

Что делать? Высокое значение Ready говорит о том, что серверу не хватает ресурсов процессора для нормальной работы виртуальных машин. В такой ситуации остается только уменьшить переподписку по процессору (vCPU:pCPU). Очевидно, этого можно добиться, уменьшив параметры существующих ВМ или путем миграции части ВМ на другие серверы.

Co-stop

Как анализировать? Данный счетчик также имеет тип Summation и переводится в проценты аналогично Ready:

(CPU co-stop summation value / (chart default update interval in seconds * 1000)) * 100 = CPU co-stop %

Здесь также нужно обращать внимание на количество ядер на ВМ и на интервал измерения.
В состоянии сostop ядро не выполняет полезную работу. При правильном подборе размера ВМ и нормальной нагрузке на сервер счетчик со-stop должен быть близок к нулю.

В данном случае нагрузка явно ненормальная:)

Также co-stop вырастет, если для активных ядер одной ВМ используются треды на одном физическом ядре сервера со включенным hyper-treading. Такая ситуация может возникнуть, например, если у ВМ больше ядер, чем физически есть на сервере, где она работает, или если для ВМ включена настройка «preferHT». Про эту настройку можно прочитать здесь.

Чтобы избежать проблем с производительностью ВМ из-за высокого сo-stop, выбирайте размер ВМ в соответствии с рекомендациями производителя ПО, которое работает на этой ВМ, и с возможностями физического сервера, где работает ВМ.

Не добавляйте ядра про запас, это может вызвать проблемы с производительностью не только самой ВМ, но и ее соседей по серверу.

Другие полезные метрики CPU

Run – сколько времени (мс) за период измерения vCPU находился в состоянии RUN, то есть собственно выполнял полезную работу.

Idle – сколько времени (мс) за период измерения vCPU находился в состоянии бездействия. Высокие значения Idle – это не проблема, просто vCPU было «нечего делать».

Wait – сколько времени (мс) за период измерения vCPU находился в состоянии Wait. Так как в данный счетчик включается IDLE, высокие значения Wait также не говорят о наличии проблемы. А вот если при высоком Wait IDLE низкий, значит ВМ ждала завершения операций ввода/вывода, а это, в свою очередь, может говорить о наличии проблемы с производительностью жесткого диска или каких-либо виртуальных устройств ВМ.

Max limited – сколько времени (мс) за период измерения vCPU находился в состоянии Ready из-за установленного лимита по ресурсам. Если производительность необъяснимо низкая, то полезно проверить значение данного счетчика и лимит по CPU в настройках ВМ. У ВМ действительно могут оказаться выставлены лимиты, о которых вы не знаете. Например, так происходит, когда ВМ была склонирована из шаблона, на котором был установлен лимит по CPU.

Swap wait – сколько времени за период измерения vCPU ждал операции с VMkernel Swap. Если значения данного счетчика выше нуля, то у ВМ точно есть проблемы с производительностью. Подробнее про SWAP поговорим в статье про счетчики оперативной памяти.

ESXTOP

Если счетчики производительности в vCenter хороши для анализа исторических данных, то оперативный анализ проблемы лучше производить в ESXTOP. Здесь все значения представлены в готовом виде (не нужно ничего переводить), а минимальный период измерения 2 секунды.
Экран ESXTOP по CPU вызывается клавишей «c» и выглядит следующим образом:

Для удобства можно оставить только процессы виртуальных машин, нажав Shift-V.
Чтобы посмотреть метрики по отдельным ядрам ВМ, нажмите «e» и вбейте GID интересующей ВМ (30919 на скриншоте ниже):

Кратко пройдусь по столбцам, которые представлены по умолчанию. Дополнительные столбцы можно добавить, нажав «f».

NWLD (Number of Worlds) – количество процессов в группе. Чтобы раскрыть группу и увидеть метрики для каждого процесса (например, для каждого ядра многоядерной ВМ), нажмите “e”. Если в группе больше одного процесса, то значения метрик для группы равны сумме метрик для отдельных процессов.

%USED – сколько циклов CPU сервера использует процесс или группа процессов.

%RUN – сколько времени за период измерения процесс находился в состоянии RUN, т.е. выполнял полезную работу. Отличается от %USED тем, что не учитывает hyper-threading, frequency scaling и время, затраченное на системные задачи (%SYS).

%SYS – время, затраченное на системные задачи, например: обработку прерываний, ввода/вывода, работу сети и пр. Значение может быть высоким, если на ВМ большой ввод/вывод.

%OVRLP – сколько времени физическое ядро, на котором выполняется процесс ВМ, потратило на задачи других процессов.

Данные метрики соотносятся между собой следующим образом:

%USED = %RUN + %SYS — %OVRLP.

Обычно метрика %USED является более информативной.

%WAIT – сколько времени за период измерения процесс находился в состоянии Wait. Включает IDLE.

%IDLE – сколько времени за период измерения процесс находился в состоянии IDLE.

%SWPWT – сколько времени за период измерения vCPU ждал операции с VMkernel Swap.

%VMWAIT – сколько времени за период измерения vCPU находилось в состояния ожидания события (обычно ввода/вывода). Аналогичного счетчика нет в vCenter. Высокие значения говорят о проблемах с вводом/выводом на ВМ.

%WAIT = %VMWAIT + %IDLE + %SWPWT.

Если ВМ не использует VMkernel Swap, то при анализе проблем с производительностью целесообразно смотреть на %VMWAIT, так как данная метрика не учитывает время, когда ВМ ничего не делала (%IDLE).

%RDY – сколько времени за период измерения процесс находился в состоянии Ready.

%CSTP – сколько времени за период измерения процесс находился в состоянии сostop.

%MLMTD – сколько времени за период измерения vCPU находился в состоянии Ready из-за установленного лимита по ресурсам.

%WAIT + %RDY + %CSTP + %RUN = 100% – ядро ВМ все время находится в каком-то из этих четырех состояний.

CPU на гипервизоре

В vCenter есть также счетчики производительности CPU для гипервизора, но они не представляют из себя ничего интересного – это просто сумма счетчиков по всем ВМ на сервере.
Удобнее всего смотреть состояние CPU на сервере на вкладке Summary:

Для сервера, как и для виртуальной машины, есть стандартный Alarm:

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

В ESXTOP данные о загрузке CPU сервера представлены в верхней части экрана. Помимо стандартного CPU load, который малоинформативен для гипервизоров, есть еще три метрики:

CORE UTIL(%) – загрузка ядра физического сервера. Данный счетчик показывает, сколько времени за период измерения ядро выполняло работу.

PCPU UTIL(%) – если включен hyper-threading, то на каждое физическое ядро приходится два потока (PCPU). Данная метрика показывает, сколько времени каждый поток выполнял работу.

PCPU USED(%) – то же, что PCPU UTIL(%), но учитывает frequency scaling (либо снижение частоты ядра в целях энергосбережения, либо повышение частоты ядра за счет технологии Turbo Boost) и hyper-threading.

PCPU_USED% = PCPU_UTIL% * эффективную частоту ядра / номинальную частоту ядра.

На этом скриншоте для некоторых ядер из-за работы Turbo Boost’а значение USED больше 100%, так как частота ядра выше номинальной.

Пара слов о том, как учитывается hyper-threading. Если процессы исполняются 100% времени на обоих потоках физического ядра сервера, при этом ядро работает на номинальной частоте, то:

CORE UTIL для ядра будет 100%,
PCPU UTIL для обоих потоков будет 100%,
PCPU USED для обоих потоков будет 50%.

В ESXTOP также есть экран с параметрами энергопотребления CPU сервера. Здесь можно посмотреть, используются ли сервером технологии энергосбережения: C-states и P-states. Вызывается клавишей «p»:

Стандартные проблемы производительности CPU

Напоследок пробегусь по типичным причинам возникновения проблем с производительностью CPU ВМ и дам короткие советы их решению:

Не хватает тактовой частоты ядра. Если нет возможности перевести ВМ на более производительные ядра, можно попробовать изменить настройки энергопотребления, чтобы Turbo Boost работал эффективнее.

Неправильный сайзинг ВМ (слишком много/мало ядер). Если поставить мало ядер, будет высокая загрузка CPU ВМ. Если много, словите высокий co-stop.

Неправильная NUMA-топология на больших ВМ. NUMA-топология, которую видит ВМ (vNUMA), должна соответствовать NUMA-топологии сервера (pNUMA). Про диагностику и возможные варианты решения данной проблемы написано, например, в книге «VMware vSphere 6.5 Host Resources Deep Dive». Если не хотите углубляться и у вас нет лицензионных ограничений по ОС, установленной на ВМ, делайте на ВМ много виртуальных сокетов по одному ядру. Много не потеряете :)

На этом про CPU у меня все. Задавайте вопросы. В следующей части расскажу про оперативную память.

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

Некоторые рабочие нагрузки баз данных, например SQL Server или Oracle, требуют большого объема памяти, хранилища и пропускной способности ввода-вывода, но не требуют наличия большого количества ядер. Многие рабочие нагрузки баз данных не нагружают процессор. Azure предлагает определенные размеры виртуальных машин, в которых вы можете ограничить количество виртуальных ЦП, чтобы снизить затраты на лицензирование программного обеспечения, сохранив при этом те же ресурсы памяти, хранилища и пропускную способность ввода-вывода.

Число виртуальных ЦП можно ограничить вдвое или вчетверо от исходного размера виртуальной машины. В названии новых размеров виртуальных машин содержится суффикс, указывающий число активных виртуальных ЦП, что позволяет упростить процесс их определения.

Например, текущая виртуальная машина размера Standard_GS5 оснащена 32 виртуальными ЦП, 448 ГБ ОЗУ, 64 дисками (до 256 ТБ) и поддерживает 80 000 операций ввода-вывода в секунду или пропускную способностью ввода-вывода 2 ГБ/с. Новые виртуальные машины размера Standard_GS5-16 и Standard_GS5-8 оснащены 16 и 8 активными виртуальными ЦП соответственно. Остальные характеристики такие же, как у виртуальной машины Standard_GS5.

Цена за лицензии на виртуальные машины SQL Server или Oracle взымается в зависимости от нового количества виртуальных ЦП. Это же правило должно применяться и к цене за остальные продукты. Это позволяет на 50–75 % увеличить соотношение характеристик виртуальной машины с активными (подлежащими оплате) ЦП. Эти новые размеры виртуальных машин позволяют использовать одну память, хранилище и полосу пропускания ввода-вывода для рабочих нагрузок клиентов, вместе с тем оптимизируя стоимость лицензий на программное обеспечение. Сейчас затраты на вычисление, в том числе лицензирование операционной системы, остаются прежними. Дополнительные сведения см. в записи блога Announcing new Azure VM sizes for more cost-effective database workloads (Объявление новых размеров виртуальных машин Azure для более экономичных рабочих нагрузок базы данных).

Остальные размеры

Дальнейшие действия

Узнайте больше о том, как с помощью единиц вычислений Azure (ACU) сравнить производительность вычислений для различных номеров SKU Azure.

Читайте также: