Что-то я видимо не понял смысл заголовка "Зачем нужно управление производительностью виртуальных машин"
1 задача звучит как "Хотим ограничивать доступный объем ресурсов " - на мой взгляд это типичная задача гипервизора, где есть "CPU Shared Pool" c переподпсикой, лимитами и "банкой с пауками" или "Dedicated CPU" - для солидных "дядей".
Эта задача решается множеством гипервизоров и мне странным слышится это от облачного провайдера... Наверное я чего-то не понял.
2 задача звучит как "Хотим приоритизировать процессы. " - вообще не относится к вирутальной машине. Это уже другой слой. И для решения этих задач весь мир использует уже упомянутые CGroup в оркестрации Docker, Kubernetes, OpenShift и т.п.
Как правило, кому не нужно быстро и качественно (кто не задумывается о длительности < 500ms) - выбирают VM с переподпиской и на него уже Kubernetes или т.п. Тем самым получая CPU паузы от гипервизора и CPU Throttling от CGRoup, но зато экономия на инфраструктуре.
ну а если можно помечтать :) Здорово бы было пошире посмотреть, от простейшего C кода, до gdb. Ближе к жизни как бы. ASM конечно хорошо, но мало где его "видно"
Было бы здорово увидеть итоговый, полный код файла args.s , например на GitHub. Человек со стороны как я, на простой "запятой" сможет споткнуться и ничего не получить.
И было бы особенно полезным посмотреть на исполнения из gdb, состояние стека, регистров или т.п.
Да, все верно понимаете. Про возможность получать steal time от VMware по аналогии с KVM не слышал, спасибо за наводку. Поизучаю.
Шумность облака по CPU я пробовал измерять "сажая" потоки на ядра, периодически включая и выключая их с замером разности (есть похожие проекты), но вот вроде бы в kernel 5.14 появился OSNOISE Tracer с "HW noise" счетчиком, но все руки не доходят поизучать, вернее доступов нет из-за вездесущих облаков :) Интересно как это коррелируется со steal time полученным от VMware... По идее, этот счетчик должен быть легко доступен без всяких дебагов ядра или т.п.
Очень интересный материал, про привязку к ядрам всяких JVM видел, а вот про особенности K8S нет. Спасибо.
Попробую усложнить задачку. Было бы очень интересно услышать Ваше мнение.
В большинстве случаев , которые я видел и не могу на них влиять, ваша K8S нода работает внутри VM от VMware или т.п. с share физическими ядрами из пула.
Доступа к гипервизору нет, и увидеть те же настоящие "off-cpu от Грегга" не получится, на мой взгляд. Вернее когда гипервизор не дал самой VM времени поработать CPU. Посадить служебные процессы гостевого kernel можно по такой же методике внутри VM, но они же приземлятся на vCPU и в любом случае будет мешанина из потоков всех виртуалок и самого гипервизора на уровне физ. CPU.
И как замерить шумность облачной среды не понятно имея доступ только во внутрь гостевой ОС (VM)
Очень интересный материал, про привязку к ядрам всяких JVM видел, а вот про особенности K8S нет. Спасибо.
Попробую усложнить задачку. Было бы очень интересно услышать Ваше мнение.
В большинстве случаев , которые я видел и не могу на них влиять, ваша K8S нода работает внутри VM от VMware или т.п. с share физическими ядрами из пула.
Доступа к гипервизору нет, и увидеть те же настоящие "off-cpu от Грегга" не получится, на мой взгляд. Вернее когда гипервизор не дал самой VM времени поработать CPU. Посадить служебные процессы гостевого kernel можно по такой же методике внутри VM, но они же приземлятся на vCPU и в любом случае будет мешанина из потоков всех виртуалок и самого гипервизора на уровне физ. CPU.
И как замерить шумность облачной среды не понятно имея доступ только во внутрь гостевой ОС (VM)
Что-то я видимо не понял смысл заголовка "Зачем нужно управление производительностью виртуальных машин"
1 задача звучит как "Хотим ограничивать доступный объем ресурсов " - на мой взгляд это типичная задача гипервизора, где есть "CPU Shared Pool" c переподпсикой, лимитами и "банкой с пауками" или "Dedicated CPU" - для солидных "дядей".
Эта задача решается множеством гипервизоров и мне странным слышится это от облачного провайдера... Наверное я чего-то не понял.
2 задача звучит как "Хотим приоритизировать процессы. " - вообще не относится к вирутальной машине. Это уже другой слой. И для решения этих задач весь мир использует уже упомянутые CGroup в оркестрации Docker, Kubernetes, OpenShift и т.п.
Как правило, кому не нужно быстро и качественно (кто не задумывается о длительности < 500ms) - выбирают VM с переподпиской и на него уже Kubernetes или т.п. Тем самым получая CPU паузы от гипервизора и CPU Throttling от CGRoup, но зато экономия на инфраструктуре.
ну а если можно помечтать :) Здорово бы было пошире посмотреть, от простейшего C кода, до gdb. Ближе к жизни как бы. ASM конечно хорошо, но мало где его "видно"
Спасибо за статью.
Было бы здорово увидеть итоговый, полный код файла args.s , например на GitHub. Человек со стороны как я, на простой "запятой" сможет споткнуться и ничего не получить.
И было бы особенно полезным посмотреть на исполнения из gdb, состояние стека, регистров или т.п.
Бишкек говорите... Киргизия... интересный тренд намечается :)
Да, все верно понимаете. Про возможность получать steal time от VMware по аналогии с KVM не слышал, спасибо за наводку. Поизучаю.
Шумность облака по CPU я пробовал измерять "сажая" потоки на ядра, периодически включая и выключая их с замером разности (есть похожие проекты), но вот вроде бы в kernel 5.14 появился OSNOISE Tracer с "HW noise" счетчиком, но все руки не доходят поизучать, вернее доступов нет из-за вездесущих облаков :) Интересно как это коррелируется со steal time полученным от VMware... По идее, этот счетчик должен быть легко доступен без всяких дебагов ядра или т.п.
Очень интересный материал, про привязку к ядрам всяких JVM видел, а вот про особенности K8S нет. Спасибо.
Попробую усложнить задачку. Было бы очень интересно услышать Ваше мнение.
В большинстве случаев , которые я видел и не могу на них влиять, ваша K8S нода работает внутри VM от VMware или т.п. с share физическими ядрами из пула.
Доступа к гипервизору нет, и увидеть те же настоящие "off-cpu от Грегга" не получится, на мой взгляд. Вернее когда гипервизор не дал самой VM времени поработать CPU. Посадить служебные процессы гостевого kernel можно по такой же методике внутри VM, но они же приземлятся на vCPU и в любом случае будет мешанина из потоков всех виртуалок и самого гипервизора на уровне физ. CPU.
И как замерить шумность облачной среды не понятно имея доступ только во внутрь гостевой ОС (VM)
Очень интересный материал, про привязку к ядрам всяких JVM видел, а вот про особенности K8S нет. Спасибо.
Попробую усложнить задачку. Было бы очень интересно услышать Ваше мнение.
В большинстве случаев , которые я видел и не могу на них влиять, ваша K8S нода работает внутри VM от VMware или т.п. с share физическими ядрами из пула.
Доступа к гипервизору нет, и увидеть те же настоящие "off-cpu от Грегга" не получится, на мой взгляд. Вернее когда гипервизор не дал самой VM времени поработать CPU. Посадить служебные процессы гостевого kernel можно по такой же методике внутри VM, но они же приземлятся на vCPU и в любом случае будет мешанина из потоков всех виртуалок и самого гипервизора на уровне физ. CPU.
И как замерить шумность облачной среды не понятно имея доступ только во внутрь гостевой ОС (VM)