Серьезное узкое место в многопоточной памяти после достижения определенного количества ядер

Мы впервые тестируем наше программное обеспечение на машине с> 12 ядер для масштабируемости, и мы сталкиваемся с неприятным падением производительности после добавления 12-го потока. Потратив на это пару дней, мы не понимаем, что попробовать дальше.

Тестовая система представляет собой двойной Opteron 6174 (2x12 ядер) с 16 ГБ памяти, Windows Server 2008 R2.

В основном, производительность достигает пика. от 10 до 12 потоков, затем падает с обрыва и вскоре выполняет работу примерно с той же скоростью, что и с 4 потоками. Спад довольно крутой и к 16-20 потокам достигает дна по пропускной способности. Мы протестировали как один процесс, выполняющий несколько потоков, так и несколько процессов, выполняющих один поток - результаты практически одинаковы. Обработка довольно интенсивна для памяти и требует некоторой дисковой нагрузки.

Мы вполне уверены, что это узкое место в памяти, но мы этого не делаем. Не верю, что это проблема с кешем. Доказательства таковы:

• Использование ЦП продолжает расти с 50 до 100% при масштабировании с 12 до 24 потоков. Если бы у нас были проблемы с синхронизацией / взаимоблокировкой, мы ожидали бы, что загрузка ЦП превысит до 100%.
• Тестирование при копировании большого количества файлов в фоновом режиме очень мало повлияло на скорость обработки. Мы думаем, что это исключает дисковый ввод-вывод как узкое место.
• Плата за фиксацию составляет всего около 4 ГБ, поэтому мы должны быть значительно ниже порога, при котором подкачка станет проблемой.
• Лучшие данные получаются при использовании Инструмент AMD CodeAnalyst. CodeAnalyst показывает, что ядро ​​Windows переходит от 6% времени процессора с 12 потоками к 80-90% времени процессора при использовании 24 потоков. Подавляющее большинство этого времени тратится на функции ExAcquireResourceSharedLite (50%) и KeAcquireInStackQueuedSpinLockAtDpcLevel (46%). Вот основные моменты изменения коэффициента ядра при переходе от работы с 12 потоками к работе с 24:
  
  Инструкции: 5.56 (раз больше)
  Тактовые циклы: 10,39
  Операции с памятью: 4,58
  Коэффициент промахов кэша: 0,25 (фактический коэффициент промахов кэша равен 0,1, в 4 раза меньше, чем с 12 потоками)
  Средняя задержка промаха кеша: 8,92
  Общая задержка промаха кеша: 6,69
  Конфликт загрузки банка памяти: 11.32
  Конфликт магазина банка памяти: 2,73
  Переадресовано Mem: 7.42
  

Мы думали, что это может быть доказательством проблемы, описанной в этой статье , однако мы обнаружили, что привязка каждого рабочего потока / процесса к определенному ядру вообще не улучшает результаты ( если уж на то пошло, производительность стала немного хуже)

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