Запуск приложения на двух узлах с Windows Server с NUMA

Question

У меня был интересный звонок с клиентом сегодня. У нас есть приложение, которое планирует другие приложения, и обычно у нас нет никаких проблем с серверами с конфигурацией NUMA с количеством узлов от 2 до 4.

Во время разговора мы запустили два приложения, сильно загружающих ЦП, и оба были распределены по узлу 0, поэтому на всей машине было только 50% использования. Как только мы изменили второй экземпляр приложения на другой узел, мы использовали все ядра (половина в одном приложении, половина в другом). Казалось невозможным выделить приложение для всех ядер.

Теперь единственное различие между этой машиной и той, которую я привык использовать, состоит в том, что диспетчер задач Windows перечислял узлы в выпадающем списке вместо длинного списка отдельных ядер, поэтому Microsoft знает, что это за ограничение, но это сложная проблема для исследования в Интернете.

Ясно, что нам нужно развивать сходство узлов NUMA, но сейчас я пытаюсь понять проблему. Что может привести к тому, что один стиль машины NUMA позволит приложениям прозрачно использовать оба узла, и что сейчас вызывает такое поведение?

Я вижу, что эта архитектура отлично работает для многих небольших приложений, но мы обычно запускаем монолитные со многими потоками.

Сервер, с которым я борюсь, - это HP Proliant DL388Gen9 с двумя процессорами Intel Xeon E5-2690V3.

Мысли о том, что вызывает это?

Answer 1

Процесс может быть назначен только одному узлу NUMA. Это короткий ответ. Вы не можете заставить один экземпляр работать более чем на одном узле NUMA. И это имеет смысл, учитывая цель NUMA, а также вторичную цель - разрешить> 64 ядра ЦП в ОС, которая использует 64-битные битовые маски соответствия ЦП.

Answer 2

Я не эксперт в этом вопросе, но я согласен с моим мнением.

Ясно, что нам нужно развивать сходство узлов NUMA, но сейчас я пытаюсь понять проблему. Что может привести к тому, что один стиль машины NUMA позволит приложениям прозрачно использовать оба узла, и что сейчас вызывает такое поведение?

Я знаю, что Windows вычисляет "расстояние до узла", оценивая количество времени, которое требуется различным узлам NUMA для взаимодействия друг с другом. Я не знаю, основаны ли его задержки или пропускная способность (или, возможно, оба), но это важно знать.

Современные машины, такие как Skylake-Server, могут иметь "кластеризацию SubNuma", где разные части одного и того же чипа сообщаются как разные узлы NUMA. Однако разница между узлами в одном чипе составляет ~ 10 наносекунд. В то время как другой сокет может иметь ~ 200 наносекунд.

Пример: два Xeon Gold (20 ядер на процессор) с кластеризацией не-NUMA будут выглядеть как 4-кратные узлы NUMA для Windows. 2 узла NUMA на чип, представляющие "левые" 10 ядер и "правые" 10 ядер на каждой половине чипа. 3 контроллера памяти слева, 3 контроллера памяти справа. Но все 20-ядерные могут общаться с контроллером памяти в ~ 80 наносекунд или около того. Они могут просто общаться с "более близким" контроллером памяти за 70 наносекунд. Разница почти незаметная, поэтому Windows, вероятно, предпочитает перемещать потоки между этими двумя узлами NUMA.

Я предполагаю, что в соответствии с настройками по умолчанию вашей установки Windows решила, что одно "расстояние до узла" было достаточно коротким, чтобы перемещать потоки, в то время как при другой настройке расстояния памяти были достаточно большими, чтобы настройки Windows по умолчанию предпочитали сохранять потоки в узле NUMA.

---

Это не единственная моя теория. Моя вторая теория - что-то странное происходит с "Процессорными группами". Группы процессоров - это грязный хак совместимости Win32 API, потому что маски Affinity CPU были ограничены 64-битными из соображений производительности. Следовательно, 64-логическое ядро является максимальным значением по умолчанию для Windows.

Вы можете получить доступ к более чем 64 логическим ядрам через API группы процессоров. https://msdn.microsoft.com/en-us/library/windows/desktop/dd405503(v=vs.85).aspx

Вкратце: если ваши процессы находятся в отдельных "группах процессоров", вы будете программистом, чтобы изменить программу для поддержки групп процессоров.

Я лично не проводил много испытаний с этим материалом. Но, надеюсь, это полезная информация для вас.