Советы по оптимизации производительности виртуальной машины

Советы

Вернуться в Базу знаний

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

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

Данные рекомендации основаны на рекомендациях команды производительности VMware (VMware's performance team) и их изложении в профильном блоге.

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

Рекомендация предоставляется исходя из возможности работы ВМ на сервере с двумя сокетами и 20 физическими ядрами (40 логических) и 384 ГБ оперативной памяти.
​Рекомендацией вендора является использование максимально возможного количества ядер и оперативной памяти в пределах одного процессора. При превышении размеров памяти или количества физических ядер рекомендуется поддерживать количество vCPU строго чётным и разносить на количество сокетов не превышающих количество физических.

Физический процессор Потребность в vCPU Потребность в памяти Конфигурация ВМ Кол-во vNUMA узлов
2 сокета
10 физических ядер/сокет
40 логических ядер

384 ГБ RAM
192 ГБ/сокет
Сокетов Ядер/сокет
1 <192 ГБ 1 1 1
2 <192 ГБ 1 2 1
3 <192 ГБ 1 3 1
4 <192 ГБ 1 4 1
5 <192 ГБ 1 5 1
6 <192 ГБ 1 6 1
7 <192 ГБ 1 7 1
8 <192 ГБ 1 8 1
9 <192 ГБ 1 9 1
10 <192 ГБ 1 10 1
11 <192 ГБ Не оптимально с точки зрения производительности
12 <192 ГБ 2 6 2
13 <192 ГБ Не оптимально с точки зрения производительности
14 <192 ГБ 2 7 2
15 <192 ГБ Не оптимально с точки зрения производительности
16 <192 ГБ 2 8 2
17 <192 ГБ Не оптимально с точки зрения производительности
18 <192 ГБ 2 9 2
19 <192 ГБ Не оптимально с точки зрения производительности
20 <192 ГБ 2 10 2


При потребностях в количестве оперативной памяти для ВМ превышающем 192 Гб рекомендуется использовать память с двух узлов vNUMA:

Физический процессор Потребность в vCPU Потребность в памяти Конфигурация ВМ Кол-во vNUMA узлов
2 сокета
10 физических ядер/сокет
40 логических ядер

384 ГБ RAM
192 ГБ/сокет
Сокетов Ядер/сокет
1 >192 ГБ Не оптимально с точки зрения производительности
2 >192 ГБ 2 1 2
3 >192 ГБ Не оптимально с точки зрения производительности
4 >192 ГБ 2 2 2
5 >192 ГБ Не оптимально с точки зрения производительности
6 >192 ГБ 2 3 2
7 >192 ГБ Не оптимально с точки зрения производительности
8 >192 ГБ 2 4 2
9 >192 ГБ Не оптимально с точки зрения производительности
10 >192 ГБ 2 5 2
11 >192 ГБ Не оптимально с точки зрения производительности
12 >192 ГБ 2 6 2
13 >192 ГБ Не оптимально с точки зрения производительности
14 >192 ГБ 2 7 2
15 >192 ГБ Не оптимально с точки зрения производительности
16 >192 ГБ 2 8 2
17 >192 ГБ Не оптимально с точки зрения производительности
18 >192 ГБ 2 9 2
19 >192 ГБ Не оптимально с точки зрения производительности
20 >192 ГБ 2 10 2


При использовании ВМ в рамках кластера 1С максимальным значением является 12 ядер/сокет и 256 Гб оперативной памяти/сокет.

Использование возможностей “Hot Add” не рекомендуется для продуктивных нагрузок и применимо только для выяснения практического потолка потребности ВМ в вычислительных мощностях (количество vCPU, объём оперативной памяти) без остановки процесса тестирования. Связано это с исключением из работы механизма vNUMA, некорректным распределением виртуальных ядер (vCPU) между  физическими процессорами (pCPU) и на переход к доступу к физической оперативной памяти (pRAM) с механизма NUMA на UMA (Unified Memory Access), что негативно отражается на скорости работы виртуальной оперативной памяти (vRAM).

Рекомендации по оптимизации дисковой подсистемы
 

Отделяйте продуктивные данные от данных операционной системы и выносите их на отдельный виртуальный диск. Это обеспечит

  • Больший параллелизм в работе гостевой операционной системы
  • Возможность создания резервных копий с отличающейся частотой
  • Возможность переключения диска между ВМ с использованием механизма Independent Disk

Для большего распределения нагрузки рекомендуется использовать выделенные SCSI контроллеры.

Рекомендации по оптимизации сетевой подсистемы
 

Использовать VMXNet3.
Если разворачивается аплаинс из ova/ovf, допустимо использование E1000E по требованию вендора аплаинса.

Рекомендации по оптимизации гостевой операционной системы
 

Для ВМ с большим объёмом вычислительных ресурсов (vCPU, vRAM) необходимо проверить корректность работы NUMA с помощью Coreinfo. При корректном распределении гостевая ОС в ВМ с 12 vCPU должна показывать следующее:

Использовать актуальные версии операционных систем. Старые ОС могут переставать поддерживаться вендором или работать некорректно.

Необходимо держать в актуальном состоянии VMware Tools для получения наибольшей производительности от паравиртуальных устройств, корректного использования памяти и возможности кастомизации через интерфейс vCloud Director.

Для Linux рекомендуется использовать open-vm-tools, так как это даст возможность работы через профильные репозитории.

Для HTML5
 

 

Заголовок формы
Настоящим в соответствии с Федеральным законом № 152-ФЗ «О персональных данных» от 27.07.2006, отправляя данную форму, вы подтверждаете свое согласие на обработку персональных данных. Мы, ЗАО «СофтЛайн Интернейшнл» и аффилированные к нему лица, гарантируем конфиденциальность получаемой нами информации. Обработка персональных данных осуществляется в целях эффективного исполнения заказов, договоров и пр. в соответствии с «Политикой конфиденциальности персональных данных».