processor:memory affinity


В этой теме 19 ответов, 3 участника, последнее обновление  Oleg 4 года/лет, 8 мес. назад.

  • Автор
    Сообщения
  • #17459

    Oleg
    Участник

    Здравствуйте!
    Может кто-то знает по опыту насколько нехороший core:memory affinity влияет на производительность?
    Например раздел shared-smt-4, uncapped, entitlement=4, VP=4. Работает Oracle.
    Скажем, первый, хороший, вариант:

    # lssrad -av
    REF1 SRAD MEM CPU
    0
    0 64000 0-15

    И второй, не очень хороший:

    REF1 SRAD MEM CPU
    0
    0 32000 0-15
    1 32000

    Какая может быть разница в производительности? 5%? 10? 20? Или вообще неощутимая?
    Или если, скажем, часть памяти вообще уедет в другой CEC или Book(если 795 машина)?

  • #17460

    Sever
    Участник

    Первый вариант лучше во всех отношениях.
    Про второй вариант…
    1. Во первых для партиции с процессорами из shared пула так быть не может. Подобную картину (кусок памяти без соответствующих ему какого либо числа процессоров из этой ноды) я видел только один раз и только для партиции с dedicated процессорами.
    2. Для варианта shared процессоры назначаются партиции «нежестко» и даже при выполнении DLPAR памяти из области другой ноды происходит динамическое их переназначение пропорционально объему, т.е. во втором случае каждому куску памяти должно быть назначено по два ядра.
    3. Нужно учитывать еще один фактор — folding процессоров. Эта зараза включена на power7 по умолчанию. С большой долей вероятности, в режиме назначения на два равных SRADа по два ядра в каждом, на каждой ноде будет фолдится по одному ядру и работа при слабой утилизации будет производится двумя ядрами с разных нод.

    В любом случае, второй вариант хуже. Насколько это отражается на реальной нагрузке сказать не могу. У меня нет такой информации.

  • #17461

    Oleg
    Участник

    1. ну почему же не может. Эти цифры я от фонаря конечно написал, но такую ситуацию, когда память выделяется из домена без ядер из того же домена, я видел не раз, не два и даже не десять, а много ))) Напр. виос загрузили первым, он забрал немного памяти, а потом какой-то раздел по ядрам умещается на том же одном чипе, а памяти не хватает. А другие ядра на других чипах уже заняты.

    2. Тут спорить не буду, у меня нет уверенности как именно гипервизор привязывает виртуальные процы к железным, может и не «жестко». Но, думаю, в любом случае он будет стараться соблюдать первоначальную привязку, чтобы не терять наработанных кешей.

    3. Эээ, тут тоже мне кажется, что наоборот. В такой ситуации выгоднее зафолдить ядра с одной ноды, чтобы оставить работающие поближе друг к другу. Если передиспатчивать нити, то лучше же на ядра или чипы, которые ближе. Я где-то видел картинку topas с 795 машины, где лпар был размазан по нескольким букам и нагрузка была небольшой. Так AIX работал исключительно на первой буке, а ядра в остальных отдыхали.

    Это ясно, что второй вариант хуже, но весь вопрос — насколько? В теории — да, время доступа near или far памяти больше. Но как это сказывается на производительности? Может вообще никто ничего не заметит? А разницу эту можно измерить в каких-то там микро- или наносекундах спец. тестами?
    Т.е. если иначе спросить, то: стоит ли следить за этим и вообще заморачиваться, чтобы lssrad красиво показывал?

  • #17462

    Oleg
    Участник

    Да, а в теории можно и так нарисовать, самый худший вариант, когда все ядра и вся память вообще в разных books:

    # lssrad -av
    REF1 SRAD MEM CPU
    0
    0 64000
    1
    0 0 0-15

  • #17463

    andrewk
    Участник

    sever, 1я ситуация реальна — подтверждаю, видел своими глазами на SPLPAR.

    oleg, если у Вас маленький LPAR смысла заморачиваться нет никакого. Если большой — то да, есть смысл. Выяснить наличие смысла можно только в performance тестах.

    В AIX 7.1 и AIX 6.1 TL8 идет ASO, который (сам не тестировал) по идее должен перемещать память работающего приложения поближе к процессорам.

  • #17464

    Sever
    Участник

    Вопрос задавался по конкретной партиции с характеристиками
    Например раздел shared-smt-4, uncapped, entitlement=4, VP=4. Работает Oracle.
    С упоминанием, что это 795я машина.

    Ответ и давался исходя из этих исходных данных. Повторяю еще раз. Система в shared партиции никогда не допустит ситуации наличия двух SRADов памяти одного объема и 4х процессоров только на одном из них.

    PS Второй Srad может быть без процессоров только в случае, когда он по объему мал относительно общего объема партиции и его вес не дает оснований системе переназначать ему хотя бы один вирт. процессор.

  • #17465

    Oleg
    Участник

    Спасибо всем за ответы.
    Наверное, вряд ли кто сможет сказать конкретно, насколько оно «стоит заморачиваться» и уж тем более цифры. Вероятно зависит от нагрузки и ее типа.
    Sever, это несуществующая партиция, а так, для примера с потолка. Цифры оттуда же, с потолка.
    Это так, чтоб более понятно о чем речь, я привел конкретные цифры для примера.
    И то, что память поровну указал — тоже случайно. А то, что отдельные куски памяти могут быть на SRAD, с которых не взято ядер — это часто бывает. Да, не половина конечно всей памяти, тут Вы правы — это вряд ли возможно на практике, а так, 1-2-5% от общей памяти то в одном домене, то в другом может быть без ядер на этом же SRAD. Ясно, что гипервизор старается избегать такого placement, но видно не всегда получается.

  • #17466

    Sever
    Участник

    У меня ответы базировались на практических результатах.
    Как раз есть партиция с аналогичными параметрами.
    740я машина с 10ю активациями
    Шаренная партиция с 4 процессорами — как в вашем вопросе
    Партиции отдано 50 % памяти сервера
    В терминах AIX партиция живет на двух одинаковых по объему доменах памяти. Каждый обслуживается двумя ядрами с соответствующих чипов.
    Балансировка нагрузки с моей точки зрения мягко говоря плохая. Лучше бы ее вообще не было.
    При фолдинге откусывается по одному Процессору с каждой ноды.

  • #17467

    Oleg
    Участник

    Но возможно это и есть наилучшая балансировка в вашей ситуации. Я полагаю, что если такой лпар запустить на «чистой» машине первым и если 50% памяти умещаются на один SRAD, то гипервизор и расположил бы этот лпар в этом одном SRAD. А если так не выходит, то тогда предпочтительнее сохранить баланс процессор:память и расположить его в разных SRAD, чем асимметрично, т.е. больше в одном SRAD и меньше в другом. Потому гипервизор и поделил поровну.
    Кстати, есть опции SPPL и lpar_placement для управления placement, но они, если не ошибаюсь, вроде только если есть больше 3 books и только для 795 машины. Хотя в последних микрокодах может и не только, но не уверен.

  • #17468

    Sever
    Участник

    Это чистая машина. У меня нет претензий к тому, как гипервизор поделил ресурсы.
    Но внутренний балансировщик ресурсов в ОС работает при таком раскладе катастрофически неправильно. Он безостановочно занимается переводом задач с ноды на ноду. Интенсивность его работы превышает нормальный уровень активности в тысячу раз. Единственный вариант отключить это безобразие это заставить гипервизор разместить партицию на одной ноде.

  • #17469

    Sever
    Участник

    К SPPL на 795 претензий нет. На большой машине все ресурсы отданы одной партиции. Все 16 нод задействованы относительно равномерно.

  • #17470

    Oleg
    Участник

    Sever, а как Вы определяете эту «тысячу раз»?
    Насколько я понял нодой Вы называете чип или сокет, между которыми переключаются нити?

  • #17471

    Sever
    Участник

    В power7 каждый чип это нода, в многоблочных системах ноды группируются в нодные группы.
    В ibm i есть возможность посмотреть статистику балансировщика ресурсов, который занимается переключением задач по нодам по своему внутреннему алгоритму.

    На «проблемной» системе из двух нод статистика работы за три недели выглядит так:

    [code]
    Count of tasks moved since 12/04/2012 12:55:05

    Task move counts for node group 00

    Moved Tasks ! To Node 0 ! To Node 1 ! Totals
    ——————————————————
    From Node 0 ! 0 ! 6910424 ! 6910424
    From Node 1 ! 6919289 ! 0 ! 6919289
    ——————————————————
    Totals ! 6919289 ! 6910424 ! 13829713 [/code]

    на «непроблемной» системе счетчики переключений за три месяца на несколько порядкрв ниже:

    [code] Count of tasks moved since 09/22/2012 12:38:04

    Task move counts for node group 00

    Moved Tasks ! To Node 0 ! Off-group ! Grp totals ! Totals
    ——————————————————————
    From Node 0 ! 0 ! 78090 ! 0 ! 78090
    Off-group ! 77006 ! ! ! 77006
    ——————————————————————
    Group totals ! 0 ! ! 0
    Totals ! 77006 ! 78090

    Task move counts for node group 1

    Moved Tasks ! To Node 1 ! To Node 2 ! Off-group ! Grp totals ! Totals
    ——————————————————————————
    From Node 1 ! 0 ! 16414 ! 36827 ! 16414 ! 53241
    From Node 2 ! 12782 ! 0 ! 40179 ! 12782 ! 52961
    Off-group ! 38130 ! 39960 ! ! ! 78090
    ——————————————————————————
    Group totals ! 12782 ! 16414 ! ! 29196
    Totals ! 50912 ! 56374 ! 77006

    Count of tasks moved across groups

    Moved Tasks ! To Group 0 ! To Group 1 ! Totals
    ———————————————————
    From Group 0 ! 0 ! 78090 ! 78090
    From Group 1 ! 77006 ! 29196 ! 106202
    ———————————————————
    Totals ! 77006 ! 107286 ! 184292

    [/code]

    На лицо более агрессивная работа балансировщика. Причем, эта агрессивность фиксируется на системах с самыми последними уровнями firmware и обновлениями операционной системы.
    У партиций, которые работают на ресурсах только одной ноды (чипе), межнодный балансировщик неактивен.

  • #17472

    Oleg
    Участник

    Ясно, спасибо. Я не специалист в ibm i, я спрашивал применительно к aix. Там, насколько я понимаю, нечто подобное покажет mpstat -d, в колонках S0rd-S5rd и S3hrd-S5hrd процент нитей, передиспатченых с другого lcpu или другого core или другого чипа, другой book или drawer и т.д.

    А есть ли ущерб производительности от частого переключения задач между нодами? Как он реально проявляется? И насколько?

  • #17473

    Sever
    Участник

    А есть ли ущерб производительности от частого переключения задач между нодами? Как он реально проявляется? И насколько?

    Изменение числа переключений не проблема, это следствие того, что в firmware и/или ОС внесены какие то изменения. Какие? — мне неизвестно. Может это не баг, а фича 😉

    Понятие потери производительности тут неприменимо, так как это невозможно ничем измерить.

  • #17478

    Oleg
    Участник

    Как же неприменимо? Очень даже применимо. А иначе зачем это вообще?
    Будь оно неприменимо, то не обращали бы внимания на lpar placement,
    не было бы никаких рекомендаций и утилит для его контроля и тюнинга.
    Ну выделил гипервизор как-то там ресурсы и ладно. При доступе не к home
    памяти увеличивается латентность, значит теоритически нить(задача) будет работать
    медленнее и производительность падать. И измерить очень даже можно,
    было бы время, желание и свободная power7 машина. Запустить одну и ту же
    задачу при разном расположении ядер и памяти. Думаю, было бы представление
    как и насколько оно влияет. 🙂

  • #17482

    Sever
    Участник

    Тема близости ресурсов имеет право на обсуждение, но надо иметь в виду, что данный фактор при анализе общей производительности системы нужно оценивать в последнюю очередь.
    Сначала устраните потери времени на IO, научите ваше ПО эффективно работать на большом числе процессоров, добейтесь того, что бы система устойчиво работала месяцами без аварий и утечек памяти. Это основные проблемы, которые имеют гораздо больший вес и которыми нужно занимаются при эксплуатации Power систем большинству конечных пользователей систем в коммерческой области.

  • #17485

    Oleg
    Участник

    Полностью согласен, близость ресурсов будет где-то в конце при исследовании. Конечно, IO и само ПО намного более существенно. Но хочется хотя бы примерно понимать и вклад в это дело core:memory affinity, потому и спросил.

  • #17506

    Sever
    Участник

    IBM добавила дополнительную опцию в PowerVM, которая поможет производить принудительную ребалансировку ресурсов памяти партиций при возникновении дисбаланса и при желании админа его устранить. Опция называется Dynamic Platform Optimizer (DPO). Опция автоматически доступна для всех новых систем 9117-MMD, 9179-MHD, 9119-FHB c 760ой версией firmware. Для 9119-FHB с предшествующими релизами прошивки DPO можно заказать отдельно и бесплатно (EB33). В этом случает для ее активации необходимо провести апгрейд firmware 795го сервера до требуемого уровня и ввести новый VET код, который сгенерируется по факту выполнения заказа.
    Особенности использования DPO и примеры приведены в 15 главе редбука, ссылка на который давалась совсем недавно http://aixportal.ru/forum/11—power/16698-ibm-powervm-virtualization-managing-and-monitoring.html#16698

  • #17549

    Oleg
    Участник

    Да, спасибо. Читал.

Для ответа в этой теме необходимо авторизоваться.