NUMA и что про него знает vSphere?

    Я думаю, многие уже успели заглянуть и прочитать эту статью на английском в моем блоге, но для тех кому все таки комфортней читать на родном языке, нежели иностранном (как сказали бы на dirty.ru – на анти-монгольском), я перевожу очередную свою статью.

    Вы уже наверняка знаете, что NUMA это неравномерный доступ к памяти. В настоящий момент эта технология представлена в процессорах Intel Nehalem и AMD Opteron. Честно говоря, я, как практикующий по большей части сетевик, всегда был уверен, что все процессоры равномерно борются за доступ к памяти между собой, однако в случае с NUMA процессорами мое представление сильно устарело.

    image

    Приблизительно так это выглядело до появления нового поколения процессеров.

    В новой же архитектуре каждый процессорный сокет имеет прямой доступ только к определенным слотам памяти и образует NUMA узел. То есть при 4 процессорах и 64 Гбайт памяти у вас будет 4 NUMA узла, каждый с 16 Гбайт памяти.

    image

    Насколько я понял, новый подход к распределению доступа к памяти был изобретен в силу того, что современные сервера настолько напичканы процессорами и памятью, что становится технологически и экономически невыгодно обеспечивать доступ к памяти через единственную общую шину. Что в свою очередь может вести к соперничеству за полосу пропускания между процессорами, ну и к более низкой масштабируемости производительности самих серверов. Новый подход привносит 2 новых понятия – Локальная память и Удаленная память. В то время как к локальной памяти процессор обращается напрямую, то к Удаленной памяти ему приходится обращаться старым дедовским методом, через общую шину, что означает более высокую задержку. Это также означает, что для эффективного использования новой архитектуры наша ОС понимать, что она работает на NUMA узле и правильно управлять своими проложениями/процессами, иначе ОС просто рискует оказаться в ситуации, когда приложение исполняется на процессоре одного узла, в то время как его (приложения) адресное пространство памяти располагается на другом узле. Быстрый поиск показал, что NUMA архитектура поддерживается Майкрософт начиная с Windows 2003 и Vmware – как минимум с ESX Server 2.

    Не уверен, что в GUI как то можно увидеть данные NUMA узла, но определенно это можно посмотреть в esxtop.

    image

    Итак, тут мы можем наблюдать, что в нашем сервере 2 NUMA узла, и что в каждом их них 48 Гбайт памяти. Вот этот документ говорит, что первое значение означает количество локальной памяти в NUMA узле, а второе, в скобочках – количество свободной памяти. Однако, пару раз на своих продакшн серверах я наблюдал второе значение выше, чем первое, и никакого объяснения этому найти не смог.
    Итак, как только ESX сервер обнаруживает, что он работает на сервере с NUMA архитектурой, он незамедлительно включает NUMA планировщик, который в свою очередь заботится о виртуальных машинах и о том, чтобы все vCPU каждой машины находились в пределах одного NUMA узла. В предыдущих версиях ESX (до 4.1) для эффективной работы на NUMA системах максимальное количество vCPU виртуальной машины всегда ограничивалось количеством ядер на одном процессоре. Иначе NUMA планировщик просто игнорировал эту ВМ и vCPU равномерно распределялись поверх всех доступных ядер. Однако в ESX 4.1 была представлена новая технология, называемая Wide VM. Она позволяет нам назначать в ВМ большее количество vCPU, чем ядер на процессоре. Согласно Vmware документу планировщик разбивает нашу «широкую виртуальную машину» на несколько NUMA клиентов и затем уже каждый NUMA клиент обрабатывается по стандартной схеме, в пределах одного NUMA узла. Однако, память все таки будет разрозненной между выбранными NUMA узлами этой Wide VM, на которых работают vCPU виртуальной машины. Это происходит потому, что предсказать к какому участку памяти обратится тот или иной vCPU NUMA клиент практически невозможно. Несмотря на это, Wide VM все равно предоставляют существенно улучшенный механизм доступа к памяти по сравнению со стандартным «размазыванием» виртуальной машины поверх всех NUMA узлов.

    Еще одна замечательная особенность NUMA планировщика это то, что он не только решает где расположить виртуальную машину при ее запуске, но и постоянно следит за ее соотношением локальной и удаленной памяти. И если это значение уходит ниже порога (по неподтвержденной инфо – 80%), то планировщик начинает мигрировать ВМ в другой NUMA узел. Более того ESX будет контролировать скорость миграции чтобы избежать излишней загруженности общей шины, через которую общаются все NUMA узлы.

    Стоит также отметить, что при установке в памяти сервер вы должны уставновить память в правильные слоты, т.к. за распределение памяти между NUMA узлами отвечает не NUMA планировщик, а именно физическая архитектура сервера.
    Ну и напоследок, немного полезной информации, которую вы можете подчерпнуть из esxtop.

    image

    Краткое описание значений:
    NHN Номер NUMA узла
    NMIG Количество миграций виртуальной машины между NUMA узлами
    NMREM Количество удаленной памяти, используемой ВМ
    NLMEM Количество локальной памяти, используемой ВМ
    N&L Процентное соотношение между локальной и удаленной памятью
    GST_ND(X) Количество выделенной памяти для ВМ на узле X
    OVD_ND(X) Количество памяти потраченной на накладные расходы на узле X

    Хотелось бы отметить, что как обычно вся эта статья всего лишь компиляция того, что мне показалось интересным из прочитанного за последнее время в блогах таких товарищей как Frank Denneman и Duncan Epping, а также официальных документов Vmware.
    Поделиться публикацией
    Комментарии 11
      0
      Я правильно понимаю: если на сервере 8 ядер и 8 гб. оперативы, то например при 4 vCPU на двух VM лучше не отдавать одной VM более 4 гб. памяти, а то и менее, ведь ESXi тоже хочется оперативки? Они ведь попадают в один numa узел только в таком случае?
        +1
        Если у вас 2 физических CPU с 4 ядрами на каждом, то все верно.

        Правда мне сейчас пришла в голову мысль маловероятная, но все же. в vSphere по умолчанию есть каждый vcpu равен одному ядру. То есть 8 vcpu будут равны восьми cores. В то же время есть возможность изменять эту пропорцию, например, когда у вас по ОС лицензии ограничено количество поддерживаемых cpu. То есть в нашем случае можно будет изменить значение cpuid.coresPerSocket и сделать его равным 4. Тогда ваша VM будет видеть 2 vCPU и каждый будет с 4 cores. Ну и пусть тогда распределение между NUMA узлами происходит на уровне Guest OS.
        Но сие возможно как минимум при трех условиях:
        1. 4 vCores каждого vCPU вашей VM всегда будут исполняться на одном и том же физическом CPU. То есть 100% соответствие между виртуальными CPU/Cores и физическими.
        2. Guest OS будет знать про NUMA архитектуру
        3. Все это не будет вступать в конфликт с логикой NUMA scheduler

        Итого — идея достаточно дикая и как все это проверить на практике я не знаю.
          0
          На ESXi 4.1 и вин сервер 2003 прокатит?
            0
            чисто теоретически да, при всех 3 работающих условиях, но мне все равно не ясно как в той же 2003 увидеть NUMA статистику.
              0
              3-й пункт можно поподробнее. Спасибо.
        0
        Я имел в виду, что если мы хотим, чтобы NUMA scheduling происходил внутри ОС, а не внутри ESXi, то на уровне ESXi нам надо отключить NUMA Scheduler для этой VM, иначе у нас будут работать два NUMA Scheduler которые вполне возможно будут конфликтовать.

        но мне кажется слишком много всяких «если».
          0
          А насколько падает производительность для Wide VM и имеет ли смысл городить ради этого огород?
            0
            Коллеги, я не замерял производительность, да и сложно вывести какую то общую цифру, которая наверняка будет зависеть от ОС, приложения, количества ВМ на хосте, количества NUMA узлов, и т.д.
            к тому же те инструменты используемые Vmware для замера производительности виртуальных машин стоят денег.

            Но сама vmware дает следующую информацию «Performance benefit depends on the workload and configuration. Internal studies based on SPECjbb, a server Java workload, show up
            to 7% performance improvement.» — смотреть тут.

            Но Wide VM работает по умолчанию и не требует городить огород. просто вопрос коллеги Didjeru спровоцировал меня на достаточно нелепую идею
            +1
            Коллеги, пожалуйста, аргументируйте минусы. Опыта в написании статей у меня почти нет и поэтому я всегда рад критике, которая помогает мне доносить материал более доступно.
              +1
              Скорость работы WideVM в теории может упасть очень значительно — до 30%, но с выходом 4.1 VMware оптмизацию NUMA планировщика, чтобы уменьшить это значение. Теперь ESX 4.1 знает, что у него есть Wide VM, и старается по максимум её оптимизировать. VMware сообщает, что это 11-17% (реальных) по сравнению с 4.0.
              Тут много нюансов, и всё же я бы рекомендовал стараться создавать ВМку не выходящую за пределы NUMA.
                +1
                в VMware KB есть статья, описывающая ситуацию, при которой после миграции ВМ между серверами ESX NUMA может отрицательно влиять на производительность — kb.vmware.com/kb/2000740
                сам не сталкивался, но может кому пригодится.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое