Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
А как Relaxed Co-Scheduling вписывается в эту картину?
Насколько я понимаю теперь в ESXi нету ограничений на то что все vCPU/worlds одной VM должны выполняться в том же таймслоте?
Насколько я понимаю теперь в ESXi нету ограничений на то что все vCPU/worlds одной VM должны выполняться в том же таймслоте?
Relaxed Co-Scheduling в природе существует, но в данной статье осознанно не описан, дабы не путать читателей. Я опасался, что услышав про его существование, коллеги начнут уповать на него, и забудут про азы оптимизации конфигурации виртуальных машин.
Механизм Relaxed Co-Scheduling является помощником, позволяющим ВОЗМОЖНО получить дополнительные проценты производительности. Но его вклад в общую картину может быть многократно нивелирован изначально неправильной конфигурацией.
Механизм Relaxed Co-Scheduling является помощником, позволяющим ВОЗМОЖНО получить дополнительные проценты производительности. Но его вклад в общую картину может быть многократно нивелирован изначально неправильной конфигурацией.
И зря не стали описывать. Запугали людей страшилками про таймслоты, а верный механизм, использующийся системой, не описали.
Вышеописанная ситуация, когда машина ждёт, чтобы освободилось количество pCPU, соответствующее её количеству vCPU, подходит разве что под описание технологии Strict Co-Scheduling, которая имела место в ESX 2.x и то только при условии, что на всех vCPU синхронно исполняются какие-то процессы или многопоточное приложение. Даже в Strict Co-Scheduling, если из восьми процессоров задействовано только два, а остальные в Idle, то таймслоты получат только активные два.
Начиная с ESX 3.x и выше, с технологией Relaxed Co-Scheduling гипервизор вообще жонглирует ядрами вплоть до того, что два vCPU могут попеременно получать один и тот же pCPU. То есть, если между vCPU случится рассинхронизация, то заморозится в ожидании только самый активный процессор, а не вся ВМ. Напомню, что на дворе уже ESX 5.5.
Эта и другая информация есть в документе «The CPU scheduler in VMware vSphere 5.1» www.vmware.com/files/pdf/techpaper/VMware-vSphere-CPU-Sched-Perf.pdf
Хотя совет выдавать виртуальной машине минимально достаточный объём ресурсов всё ещё актуален. В первую очередь из-за NUMA. А также из-за задержек миграции, как между ВМ хостами так и vCPU между ядрами.
Ещё совет по конфигурированию виртуальных процессоров. Если ВМ конфигурируется с несколькими виртуальными процессорными ядрами в каждом виртуальном сокете, то число ядер в таком сокете должно быть равным или меньшим числу ядер в физическом сокете. Меньшим, причём, желательно делением на множитель. То есть, если в сокете 6 ядер, то в виртуальном сокете допустимо использовать 1, 2, 3, 6, но не 5 и не 8. А лучше вариант 1 сокет = 1 ядро, тогда гипервизор сам легко подстроится под NUMA.
Вышеописанная ситуация, когда машина ждёт, чтобы освободилось количество pCPU, соответствующее её количеству vCPU, подходит разве что под описание технологии Strict Co-Scheduling, которая имела место в ESX 2.x и то только при условии, что на всех vCPU синхронно исполняются какие-то процессы или многопоточное приложение. Даже в Strict Co-Scheduling, если из восьми процессоров задействовано только два, а остальные в Idle, то таймслоты получат только активные два.
Начиная с ESX 3.x и выше, с технологией Relaxed Co-Scheduling гипервизор вообще жонглирует ядрами вплоть до того, что два vCPU могут попеременно получать один и тот же pCPU. То есть, если между vCPU случится рассинхронизация, то заморозится в ожидании только самый активный процессор, а не вся ВМ. Напомню, что на дворе уже ESX 5.5.
Эта и другая информация есть в документе «The CPU scheduler in VMware vSphere 5.1» www.vmware.com/files/pdf/techpaper/VMware-vSphere-CPU-Sched-Perf.pdf
Хотя совет выдавать виртуальной машине минимально достаточный объём ресурсов всё ещё актуален. В первую очередь из-за NUMA. А также из-за задержек миграции, как между ВМ хостами так и vCPU между ядрами.
Ещё совет по конфигурированию виртуальных процессоров. Если ВМ конфигурируется с несколькими виртуальными процессорными ядрами в каждом виртуальном сокете, то число ядер в таком сокете должно быть равным или меньшим числу ядер в физическом сокете. Меньшим, причём, желательно делением на множитель. То есть, если в сокете 6 ядер, то в виртуальном сокете допустимо использовать 1, 2, 3, 6, но не 5 и не 8. А лучше вариант 1 сокет = 1 ядро, тогда гипервизор сам легко подстроится под NUMA.
Там не все так гладко, как вы описываете. Тогда можно было бы делать все виртуалки по 50 ядер и в ус не дуть. На практике все же лучше понимать причинно-следственные связи и не заставлять гипервизор выкручиваться, создавая ему изначально сложные условия. Как я уже говорил выше, Co-Scheduling скорее стоит воспринимать как дополнительную помощь в решении поставленной задачи, но никак не как основной механизм. У всего есть разумные пределы.
Бесспорно стоит понимать и оптимизировать.
Не так всё гладко, наверняка, но и не так ужасно, как может показаться (и, судя по комментариям, показалось некоторым) из вашей статьи.
Co-Scheduling это именно основной механизм. Ну или особенность работы основного механизма (CPU Scheduler).
Не так всё гладко, наверняка, но и не так ужасно, как может показаться (и, судя по комментариям, показалось некоторым) из вашей статьи.
Co-Scheduling это именно основной механизм. Ну или особенность работы основного механизма (CPU Scheduler).
Давайте я найду время и проведу тесты. Мне самому интересно получить данные в конкретных цифрах. Планирую создать несколько виртуальных машин, в каждой из которых будет запущет некий тест производительности процессора, однопоточный. То есть грузить будет 1 ядро у ВМ. Допустим, возьмем 10-ядерный процессор, 2*Xeon E5 2690v2, есть у меня такие в наличии. И сначала сделаем 20 машин с 1 ядром, прогоним на них параллельно тест, потом сделаем 20 машин по 1 виртуальному сокету и 10 ядер, протестируем. И затем сделаем 20 машин, по 2 виртуальных сокета, и по 20 ядер каждая.
Полагаю, что результат теста даст четкое понимание эффективности работы технологии Co-Scheduling. Если особой разницы в результатах не увидим, значит технология реально работает. А если увидим, значит её эффективность не ахти.
Заодно результаты можно будет в статью добавить. Тогда и про Co-Scheduling напишу. Спасибо за идею :)
Полагаю, что результат теста даст четкое понимание эффективности работы технологии Co-Scheduling. Если особой разницы в результатах не увидим, значит технология реально работает. А если увидим, значит её эффективность не ахти.
Заодно результаты можно будет в статью добавить. Тогда и про Co-Scheduling напишу. Спасибо за идею :)
Хм; тот факт, что шедулер мапит физические ядра на виртуальные исключительно _целиком_, многое объясняет, почему на VMWare всё так тормозит обычно :))
У нас на курсах по vSphere преподаватель советовал отключать Hyperthreading.
Странный совет. У меня преподаватель (Мошков, учебный центр НР, Москва), не рекомендовал отключать. Как я уже писал выше, бонус от Hyperthreading может достигать 75%!!! Но это идеальный случай. В основном этот показатель держится в пределах 15...30%
В официальном мануале «Performance Best Practices for VMware vSphere #.#» (как минимум начиная с версии «5.0»), рекомендуют ВКЛЮЧАТЬ HT, если он поддерживается. В этом же мануале описывают причины, по которым это целесообразно сделать (в объяснении как раз речь про NUMA).
PS: Спасибо автору за статью. В прочитанной мною различной документации по ESXi и его оптимизации, объяснения про «таймслоты» нигде не встречал. И спасибо за наводку на книжку «Михеева».
PS: Спасибо автору за статью. В прочитанной мною различной документации по ESXi и его оптимизации, объяснения про «таймслоты» нигде не встречал. И спасибо за наводку на книжку «Михеева».
Internal testing shows that the recent generation of HT processors displays a higher performance gain from utilizing both logical processors. This means that the potential performance loss by letting some hyper-threads idle for a fairness reason becomes non trivial. This observation encourages a more aggressive use of partial cores in load balancing. A whole core is still preferred to a partial core as a migration destination; but if there is no whole core, a partial core is more likely to be chosen. This has been accomplished by two policy changes in vSphere 5.x.
Внутренние тесты (VMware) показали, что HT-процессоры показывают большую производительность от использования обоих логических ядер. Это значит, что потенциальные потери производительности от ожидающих потоков можно считать несущественными. Это наблюдение привело к более агрессивной политике использования «частичных ядер» при балансировке нагрузки в VMware 5.x.
Внутренние тесты (VMware) показали, что HT-процессоры показывают большую производительность от использования обоих логических ядер. Это значит, что потенциальные потери производительности от ожидающих потоков можно считать несущественными. Это наблюдение привело к более агрессивной политике использования «частичных ядер» при балансировке нагрузки в VMware 5.x.
Да уж. Почерпнул так почерпнул. Если можете, напишите еще статей на эту тему. Наверняка это не все про ВМ.
Поставил бы +1, кармы не хватает
Поставил бы +1, кармы не хватает
Спасибо за статью!
Как начинающий был удивлён таким азам.
Пойду переделаю свой сервер для жолтой программы.
22 отдам гостю и 2 останеться для его служебных ядер. Итого 1 таймслот и всё — правильно? (Больше гостей на хосте нет).
Как начинающий был удивлён таким азам.
Пойду переделаю свой сервер для жолтой программы.
22 отдам гостю и 2 останеться для его служебных ядер. Итого 1 таймслот и всё — правильно? (Больше гостей на хосте нет).
А вам очень нужно одну большую ВМ создать? Если так, то я бы сделать именно так, как вы написали. Ну, и количество виртуальных сокетов в конкретно вашем случае можно дать равным количеству физических сокетов (для NUMA). Если есть возможность разнести ваше приложение на несколько меньших ВМ — это был бы лучший выход.
Производители серверов любят включать в BIOS по умолчанию эмуляцию NUMA. То есть сервер представляется операционной системе как НЕ NUMA устройство, и vSphere не может использовать свою оптимизацию для управления данной технологией. В документации по vSphere рекомендуется отключать (Disable) данную опцию в BIOS, это позволяет vSphere самостоятельно разбираться с вопросом.
А можно поподробнее узнать, где именно это в документации написано. Вот тут например про заблуждение и пишет автор. habrahabr.ru/post/263777
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизация работы виртуальной инфраструктуры на базе VMWare vSphere