Запуск приложения на двух узлах с Windows Server с NUMA
У меня был интересный звонок с клиентом сегодня. У нас есть приложение, которое планирует другие приложения, и обычно у нас нет никаких проблем с серверами с конфигурацией NUMA с количеством узлов от 2 до 4.
Во время разговора мы запустили два приложения, сильно загружающих ЦП, и оба были распределены по узлу 0, поэтому на всей машине было только 50% использования. Как только мы изменили второй экземпляр приложения на другой узел, мы использовали все ядра (половина в одном приложении, половина в другом). Казалось невозможным выделить приложение для всех ядер.
Теперь единственное различие между этой машиной и теми, которые я привык использовать, состоит в том, что диспетчер задач Windows перечислял узлы в раскрывающемся списке вместо длинного списка отдельных ядер, поэтому Microsoft знает, что это за ограничение, но это сложная проблема для исследования в Интернете.
Ясно, что нам нужно развивать сходство узлов NUMA, но сейчас я пытаюсь понять проблему. Что может привести к тому, что один стиль машины NUMA позволит приложениям прозрачно использовать оба узла, и что сейчас вызывает такое поведение?
Я вижу, что эта архитектура отлично работает для многих небольших приложений, но мы обычно запускаем монолитные со многими потоками.
Сервер, с которым я борюсь, - это HP Proliant DL388Gen9 с двумя процессорами Intel Xeon E5-2690V3.
Мысли о том, что вызывает это?
2 ответа
Процесс может быть назначен только одному узлу NUMA. Это короткий ответ. Вы не можете заставить один экземпляр работать более чем на одном узле NUMA. И это имеет смысл, учитывая цель NUMA, а также вторичную цель - разрешить>64 ядра ЦП в ОС, которая использует 64-битные битовые маски соответствия ЦП.
Я не эксперт в этом вопросе, но я согласен с моим мнением.
Ясно, что нам нужно развивать сходство узлов NUMA, но сейчас я пытаюсь понять проблему. Что может привести к тому, что один стиль машины NUMA позволит приложениям прозрачно использовать оба узла, и что сейчас вызывает такое поведение?
Я знаю, что Windows вычисляет "расстояние до узла", оценивая количество времени, которое требуется различным узлам NUMA для связи друг с другом. Я не знаю, основаны ли его задержки или пропускная способность (или, возможно, оба), но это важно знать.
Современные машины, такие как Skylake-Server, могут иметь "кластеризацию SubNuma", где разные части одного и того же чипа сообщаются как разные узлы NUMA. Однако разница между узлами в одном чипе составляет ~ 10 наносекунд. В то время как другой сокет может иметь ~ 200 наносекунд.
Пример: два Xeon Golds (20 ядер на процессор) с кластеризацией не-NUMA будут выглядеть как 4-кратные узлы NUMA для Windows. 2 узла NUMA на чип, представляющие "левые" 10 ядер и "правые" 10 ядер на каждой половине чипа. 3 контроллера памяти слева, 3 контроллера памяти справа. Но все 20-ядерные могут общаться с контроллером памяти за ~ 80 наносекунд или около того. Они могут просто общаться с "более близким" контроллером памяти за 70 наносекунд. Разница почти незаметная, поэтому Windows, вероятно, предпочитает перемещать потоки между этими двумя узлами NUMA.
Я предполагаю, что в соответствии с настройками по умолчанию вашей установки Windows решила, что одно "расстояние до узла" было достаточно коротким, чтобы перемещать потоки, в то время как при другой настройке расстояния памяти были достаточно большими, чтобы настройки Windows по умолчанию предпочитали сохранять потоки в узле NUMA.
Это не единственная моя теория. Моя вторая теория - что-то странное происходит с "процессорами". Группы процессоров - это грязный хак совместимости Win32 API, потому что маски CPU Affinity были ограничены 64-битными по соображениям производительности. Следовательно, 64-логическое ядро является максимальным значением по умолчанию для Windows.
Вы можете получить доступ к более чем 64 логическим ядрам через API группы процессоров. https://msdn.microsoft.com/en-us/library/windows/desktop/dd405503(v=vs.85).aspx
Вкратце: если ваши процессы находятся в отдельных "группах процессоров", вы будете программистом, чтобы изменить программу для поддержки групп процессоров.
Я лично не проводил много испытаний с этим материалом. Но, надеюсь, это полезная информация для вас.