Comments 16
Люто плюсую
COSTOP у вас возникнет в таком случае, только если на одном хосте работает несколько таких больших ВМ, и поэтому они поочередно ждут выполнения друг друга (точнее высвобождения нужного числа ядер). Если же у вас ВМ одна, то ничего не мешает сделать её больше одного физического CPU (да, понятно, что там возникнут задержки из-за NUMA, но они ровно так же возникнут и на физике). Тут скорее рекомендация несколько другая - не надо делать ВМ больше, чем её реально требуется (например, выдавая 36 ядер при том, что приклад реально потребляет, скажем, 12, в надежде, что "ну так мы точно узкого места в CPU сможем избежать") + не надо делать ВМ размером во весь хост, ибо на части ядер работает сам гипервизор и его ядерные процессы, а на другой части ядер обрабатывается ввод-вывод самой ВМ (vNIC, pvSCSI, etc).
Попробуйте повторить опыт с отключением гипертрединга в BIOS на гипервизоре. Раньше у 1С сервера была серьёзная такая просадка по производительности с включенным гипертредингом. Интересно, как оно сейчас?
Если рассматривать случай который описан в статье, дело было не в HyperThreading. Хотя да VMWare накладывает свои ограничения Hyperthreading and ESXi Hosts (vmware.com) Вообще в данном тесте проблемы вылезли больше на MS SQL сервере чем на 1С. Потому что 1С согласно документации 1С в многоядерной среде ведет себя более просто чем MS SQL
Hidden text
Следует иметь в виду, что поддержка NUMA в кластере серверов "1С:Предприятия" полноценно пока не реализована.
Сервер 1С не управляет распределением ресурсов по NUMA узлам, полностью полагаясь в этом на операционную систему, что не всегда даёт оптимальный результат.
Поэтому при работе на многопроцессорных системах (все современные многопроцессорные системы Intel и AMD имеют NUMA архитектуру), в зависимости от характера нагрузки, может наблюдаться неравномерная загрузка процессоров/ядер. В некоторых случаях может оказаться загружена только какая-то часть доступных ядер CPU, при этом другая часть будет простаивать. В таких случаях рекомендуется использовать лимит числа соединений на рабочий процесс, установленный из расчета:
ЧислоСоединенийНаПроцесс = РасчетноеМаксимальноеКоличествоСоединений/КоличествоNUMAНод.
При этом все равно возможна ситуация при которой будет перегружена только какая-то часть CPU (это можно можно увидеть в диспетчере задач 100% длительная 100% нагрузка на некоторые CPU при том, что остальные свободны). В таком случае лимит соединений на процесс следует уменьшать из расчета:
ЧислоСоединенийНаПроцесс = РасчетноеМаксимальноеКоличествоСоединений/(КоличествоNUMAНод * Коэффициент),
где коэффициент равен 2, и увеличивать его на 1 при каждой подстройке при наблюдении небалансированной нагрузки на NUMA нодах.
Да, это понятно. Просто имел дело с оригинальным поведением именно серверов 1С. Мы держали MS SQL в AlwaysOn на двух своих кластерах Hyper-V, а под сервера 1С специально выделили другой кластер на старых E5-2693 (v0) с отключённым HyperThreading. Только так получилось выжать максимум производительности.
А так да, всё написанное про оптимизацию MS SQL почти подходит и под случай, когда гипервизор не от VmWare. Плюс пришлось обратить пристальное внимание на тонкие настройки виртуальных свитчей и сетевых адаптеров.
Кому интересено какие еще есть варианты болевых точек на VMWare и подобных системах можете посмотреть статью Гилева Производительность «1С» в виртуальной машине | Gilev.ru | Ускоряем 1С:Предприятие . См раздел (Ошибки выбора облаков). Но надо понимать что разработчики виртуальных систем "улучшают" и дают "новые возможности" поэтому знание 101 способа снизить производительность в виртуальной среде, не избавляет от умения найти 102 способ который еще не знаете. Я старался акцентировать внимание именно на методах поиска причин в таких ситуациях
"болевые точки VMware" в 95% случаев — это отсутствие базовых знаний по работе с продуктом и отсутствие навыков чтения документации и Best Practices. Если прям очень-очень надо полностью исключить переподписку и все прочее связанное с виртуализацией (обычно не надо), то для получения 99%+ процентов производительности ВМ по CPU/RAM по сравнению с bare-metal достаточно нажать несколько кнопок в GUI, которые, по сути, выключают scheduler и переключение контекста (см. настройки Latency Sensitivity). Для тюнинга вывода-вывода делает еще несколько настроек (см. pvSCSI, HPP, LRO, InterruptThrottle, Coalescing), которые обычно описаны в документах под названием "Best Practices for XXX". Принципы работы гипервизора с ресурсами, а также многое другое, подробно объяснено и разжёвано в замечательной книге VMware Host Resources Deep Dive (которая доступна в том числе бесплатно вот тут - https://www.rubrik.com/resources/white-papers/19/host-resources-deep-dive-ebook)
Цитата из статьи
Пример подтверждения замедлений виртуализации: Первое с чего начинается описание преимуществ «контейнеров»: Контейнеры требуют значительно меньше ресурсов для своей работы чем виртуализация, что положительно сказывается на производительности и бюджете. Т.е. виртуализация требует больше ресурсов.
А потом ещё удивляются, почему админы не уважают 1Сников...
Мне например не очень понятно в чем проблема цитаты из статьи Гилева, но у него большой практический опыт ... В целом даже мне без знаний VMWare понятно что система на создание максимальной производительности не ориентирована, раз допускает неэффективные конфигурации и не ограничивает в этом администратора VMWare
Тоже самое можно сказать и про 1с, она тоже позволяет писать код который работает неэффективно.
Это потому что "1С не ориентирована на создание максимальной производительности".
Тут половина правды. Да 1С позволяет писать код который работает неэффективно, Но метаданные 1С изолируют разработчика от прямой работы с базой на уровне таблиц СУБД . В добавок метаданные 1С позволяют автоматически генерить рабочий интерфейс без кодирования. Т.е. по факту многие вещи которые разработчик может написать криво, изолированы от него и реализованы с достаточным уровнем оптимальности. Пример когда разработчик ставит галочку "создать индекс" на измерении на уровне СУБД создается несколько индексов достаточных для оптимальной работы.
WMWare наоборот предлагает решения которые заведомо снизят производительность, но конечно облегчат "оптимальное" распределение ресурсов
Хм, VmWare, MS Sql Server, в которые упорно запихивают 1С. В свете последних событий статья несколько неактуальна?
вот хорошая статьи про numa и параметр cores per socket https://www.nakivo.com/blog/the-number-of-cores-per-cpu-in-a-virtual-machine/ https://blogs.vmware.com/performance/2017/03/virtual-machine-vcpu-and-vnuma-rightsizing-rules-of-thumb.html ... А выводы как то мутно сделаны...
1С + MS SQL против Матрицы виртуализации