Ограничения ресурсов Linux для каждого процесса - глубокая загадка Red Hat

Question

У меня есть собственная многопоточная программа на C, которая плавно масштабируется по скорости с количеством ядер ЦП. Я могу запустить ее с потоками 1, 2, 3 и т. Д. И получить линейное ускорение.6-ядерный процессор на коробке с Ubuntu Linux.

У меня была возможность запустить программу на очень мощном Sunfire x4450 с 4 четырехъядерными процессорами Xeon, работающими под управлением Red Hat Enterprise Linux.Я с нетерпением ожидал увидеть, как быстро 16 ядер смогут запускать мою программу с 16 потоками ... Но она работает с той же скоростью, что и ДВА потока!

Много потянув и отладив позже, я вижу, что моя программана самом деле создает все потоки, они действительно работают одновременно, но сами потоки работают медленнее, чем должны быть.2 потока работают примерно в 1,7 раза быстрее, чем 1, но 3, 4, 8, 10, 16 потоков - всего 1,9 раза!Я вижу, что все потоки запущены (не остановлены или не спят), они просто медленные.

Чтобы проверить, не было ли ТС, я запустил ШЕСТНАДЦАТЬ копий своихпрограммировать самостоятельно, одновременно.Все они бежали на полной скорости.Там действительно 16 ядер, и они действительно работают на полной скорости, и там действительно достаточно оперативной памяти (фактически эта машина имеет 64 ГБ, и я использую только 1 ГБ на процесс).

Итак, мой вопрос, есть лиОбъяснение ОПЕРАЦИОННОЙ СИСТЕМЫ, возможно, некоторый лимит ресурсов для каждого процесса, который автоматически сокращает планирование потоков, чтобы не допустить зависания машины одним процессом.

Подсказки:

1. Моя программа не имеет доступа к диску или сети.Процессор ограничен.Его скорость линейно масштабируется на одном процессоре в Ubuntu Linux с hexacore i7 для 1-6 потоков.6 потоков - это 6-кратное ускорение.
2. Моя программа никогда не запускается быстрее, чем 2-кратное ускорение на этом 16-ядерном корпусе Sunfire Xeon для любого количества потоков от 2 до 16.
3. Запуск 16 копий моей программы однопоточный работает отлично, все 16 работают одновременно на полной скорости.
4. top показывает 1600% выделенных процессоров./ proc / cpuinfo показывает все 16 ядер, работающих на полной частоте 2,9 ГГц (не на частоте холостого хода низкой частоты 1,6 ГГц)
5. Там 48 ГБ ОЗУ свободно, он не обменивается.Что происходит?Есть ли какая-то политика ограничения процессорного времени?Как я мог измерить это, если так?Чем еще можно объяснить такое поведение?

   Спасибо за ваши идеи, чтобы решить эту проблему, Великую Тайну Замедления Xeon 2010 года!

Answer 1

Проведите некоторое исследование rlimit - вполне возможно, что в действии оболочки / пользователя, с которым вы работаете, установлены ограничения по RH-default или admin-set.

Answer 2

Мое первоначальное предположение - узкие места в общей памяти. Исходя из того, что вы говорите, ваша производительность практически не изменилась после двух процессоров. Сначала вы обвиняете Redhat, но мне было бы интересно посмотреть, что произойдет, если вы установите Ubuntu на том же оборудовании. Конечно, я предполагаю, что вы используете 64-битные ядра SMP в обоих тестах.

Вероятно, не возможно, что материнская плата достигнет максимума при использовании 2 процессоров. У вас есть другая машина с несколькими ядрами, которая обеспечивает лучшую производительность. Включена ли у вас гиперпоточность на новой машине? (и как этот ответ сравнивается со старой машиной?). Вы случайно не работаете в виртуализированной среде?

В целом, ваши доказательства указывают на смехотворно медленное узкое место где-то. Как вы сказали, вы не привязаны к вводу / выводу, так что уходит процессор и память. Либо что-то не так с оборудованием, либо что-то не так с оборудованием. Протестируйте одно, изменив другое, и вы быстро сузите свои возможности.

Answer 3

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

Это означает, что архитектура памяти начинает работать, и это будет существеннобыстрее, когда у вас есть 6 ядер на одном куске кремния, чем когда вы координируете между 4 отдельными процессорами.В частности, в случае единственного ЦП, скорее всего, вообще не требуется попадание в основную память для операций блокировки - все, вероятно, обрабатывается на уровне кэша L3, что позволяет ЦП продолжать работу, пока данные сбрасываются в основную память в фоновом режиме..

Хотя я ожидаю, что ОП потерял интерес к этому вопросу по прошествии всего этого времени (или может даже больше не иметь доступа к аппаратному обеспечению), один из способов проверить это - посмотреть, не увеличится ли масштаб до4 потока улучшаются, если привязка процесса настроена так, чтобы привязать его к одному физическому процессору.Еще лучше было бы профилировать само приложение, чтобы увидеть, на что оно тратит свое время. По мере того, как вы меняете архитектуру и увеличиваете количество ядер, все сложнее и сложнее угадать, где находятся узкие места, поэтому вам действительно нужно начинать измерять вещи.напрямую, как в этом примере: http://postgresql.1045698.n5.nabble.com/Sun-Donated-a-Sun-Fire-T2000-to-the-PostgreSQL-community-td2057445.html