Лучшее аппаратное/программное решение для параллельных решений?

Question

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

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

Я рассмотрел следующие возможные решения:

• Много отдельных строительных машин. Недостатки: много копий общего кода или работа с (медленным) общим диском. Больше систем для поддержания.
• Меньшее количество многопроцессорных машин (возможно, двух квадроциклов), с быстрым чередованием RAID-памяти. Недостатки: я не уверен, как он будет масштабироваться. Похоже, что объем будет узким местом, но я не знаю, насколько хорошо Linux обрабатывает SMP в наши дни.
• Аналогичная машина SMP, но с гипервизором или Solaris 10, работающим под управлением VMware. Является ли это глупо, или это обеспечит некоторые преимущества планирования? Недостатки: не затрагивает проблему узких мест хранения.

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

Answer 1

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

Однако, если вас в основном интересуют быстрые полные перестройки (например, ночные сборки), то вам может быть лучше rsyncing из исходного дерева для каждого ведомого устройства, или даже если каждое подчиненное подчинение проверяет свои собственные копировать из источника управления. CI-система, такая как Hudson, помогла бы управлять каждым из серверов ведомых построек.

Answer 2

Что касается программных решений, я могу порекомендовать Icecream. Он поддерживается SUSE и основывается на distcc.

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

Answer 3

Если ваши make-файлы достаточно полные и хорошо структурированные, флаг -j также может быть полезен в преодолении узких мест ввода-вывода, если в вашей машине (-ах) сборки достаточно памяти. Это позволяет параллельно запускать несколько независимых задач, чтобы ваши процессоры в идеале никогда не блокировали ожидание ввода-вывода. Как правило, я нашел хорошие результаты, разрешив несколько задач, чем у процессоров на машине.

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