Различия в планировании потоков Linux на многоядерных системах? - PullRequest
6 голосов
/ 24 мая 2011

У нас есть несколько чувствительных к времени ожидания программ типа конвейера, которые имеют ощутимое снижение производительности при запуске на одном ядре Linux по сравнению с другим. В частности, мы видим лучшую производительность с ядром 2.6.9 CentOS 4.x (RHEL4) и худшую производительность с ядром 2.6.18 из CentOS 5.x (RHEL5).

Под "конвейерной" программой я подразумеваю ту, которая имеет несколько потоков. Несколько потоков работают с общими данными. Между каждым потоком есть очередь. Таким образом, поток A получает данные, отправляет данные в Qab, поток B извлекает данные из Qab, выполняет некоторую обработку, затем передает данные в Qbc, поток C извлекает данные из Qbc и т. Д. Исходные данные поступают из сети (сгенерированной третьей стороной).

Мы в основном измеряем время с момента получения данных до момента, когда последний поток выполняет свою задачу. В нашем приложении мы видим увеличение от 20 до 50 микросекунд при переходе с CentOS 4 на CentOS 5.

Я использовал несколько методов профилирования нашего приложения и определил, что дополнительная задержка в CentOS 5 возникает из-за операций с очередями (в частности, выталкивания).

Тем не менее, я могу улучшить производительность в CentOS 5 (до уровня CentOS 4), используя набор задач для привязки программы к подмножеству доступных ядер.

Так что мне кажется, что между CentOS 4 и 5 произошли некоторые изменения (предположительно в ядре), из-за которых потоки планировались по-другому (и это различие неоптимально для нашего приложения).

Хотя я могу «решить» эту проблему с помощью набора задач (или в коде через sched_setaffinity ()), я предпочитаю не делать этого. Я надеюсь, что есть какое-то настраиваемое ядро ​​(или, может быть, набор настроек), чьи значения по умолчанию были изменены между версиями.

У кого-нибудь есть опыт с этим? Возможно, еще несколько областей для расследования?

Обновление: В данном конкретном случае проблема была решена путем обновления BIOS от поставщика сервера (Dell). Я вырвал свои волосы довольно долго на этом. Пока я не вернулся к основам и не проверил обновления BIOS моего поставщика. Подозрительно, в одном из обновлений сказано что-то вроде «улучшить производительность в режиме максимальной производительности». После того, как я обновил BIOS, CentOS 5 стал быстрее - вообще говоря, но особенно в моих тестах очереди и реальных производственных работах.

Ответы [ 2 ]

1 голос
/ 25 мая 2011

Планировщик Linux был интенсивной областью изменений и споров на протяжении многих лет.Возможно, вы захотите попробовать новейшее ядро ​​и попробовать.Да, возможно, вам придется скомпилировать его самостоятельно - это будет хорошо для вас.Вы также можете (если у вас более новое ядро) захотеть поместить различные процессы в разные контейнеры, а все остальное - в дополнительный и посмотреть, поможет ли это.

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

1 голос
/ 24 мая 2011

Хм ... если время, затрачиваемое на операцию pop () из очереди производителя-потребителя, существенно влияет на общую производительность вашего приложения, я бы предположил, что структура ваших потоков / workFlow не оптимальна, где-то . Если не будет большого количества конфликтов в очередях, я был бы удивлен, если бы какая-либо push / pop очередь ПК на любой современной ОС заняла бы больше чем µS или около того, даже если очередь использует блокировки ядра в классической 'Computer Science 117 - Как создать ограниченную очередь ПК с использованием трех семафоров.

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

...