RemComm
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору testerkk Возможно, да - это из-за путаницы в терминологии. Выделение большего количество ресурсов (CPU в частности) - да, это, безусловно, вредит из-за процессов, связанных с разпараллеливанием задач. Вся беда в том, что на таких ВМ, где выделено больше vCPU, чем реально надо - вдруг растет %RDY - таки паскудная штука, потому как рут кейс поймать не всегда удается, особенно, когда ВМ конфигурируется под требования установленного в ГОС софта, работающего не в полную нагрузку. Гиепрвизор не будет искать ядра для выделения ВМ, а будет искать ядра куда положить потоки этой самой ВМ. И если на ядрах есть пустые циклы - то это не составит проблемы. А если вот пустых циклов маловато - то тут мы и получим снижение resource delivery. Впрочем, у меня тоже есть реальный кейс на эту тему, где мне пришлось этот вопрос долго тереть с VMware TSE, и он даже был эскалирован на разработчиков, как баг - в последних версиях ESX этот вопрос уже не так актуален. Т.е. (как мне объяснил разработчик) выделение большего количества vCPU уже не приводит к столь печальным последствиям. Суть этого кейса в том, что в настоящее время ситуация такова, что практически все ОС (ГОС в нашем контексте) - многозадачные, где распараллеливание возможно уже, хотя бы, на уровне процессов, и даже при минимальной конфигурации и без нагрузки эти ОСи вполне одинаково работают как на 1 ядре, так и (скажем) на 4. Т.е., пока для контекстных переключений есть циклы - проблема не всплывет. Все плюшки с салом выплывают когда начинается конкуренция за ресурсы, которых не хватает - там не спасает ничего, кроме добавления камней. Благодарю за поправку . | Всего записей: 839 | Зарегистр. 30-09-2003 | Отправлено: 20:10 27-07-2018 | Исправлено: RemComm, 20:23 27-07-2018 |
|