2009-06-12 7 views
3

우리는 리눅스 기반의 빌드 시스템을 가지고 있습니다. 빌드 시스템은 여러 가지 임베디드 타겟 (서로 다른 드라이버와 피쳐 세트 사용 가능)으로 구성되어 있으며 각각 하나의 다른 메인 소스 트리로 구성됩니다.병렬 하드웨어를위한 최상의 하드웨어/소프트웨어 솔루션은 무엇입니까?

우리의 make 기반 시스템을보다 다중 처리하기 쉬운 것으로 변환하는 대신,이 모든 대상에 대해 빌드를 동시에 실행하는 가장 좋은 방법을 찾고 싶습니다. 내가 잘 모르는 부분은 최상의 성능을 얻는 방법입니다. 개별 빌드 기계의

  • 많은 :

    나는 다음과 같은 해결 방법을 생각했습니다. 단점 : 공유 코드의 사본이 많거나 (느린) 공유 드라이브에서 작업 중입니다. 더 많은 시스템을 유지 관리해야합니다.

  • 빠른 스트라이프 RAID 로컬 스토리지가있는 멀티 프로세서 시스템 (이중 쿼드 코어)의 수가 적습니다. 단점 : 어떻게 확장 될지 확신 할 수 없습니다. 볼륨이 병목 현상이 될 것 같지만 요즘 리눅스가 SMP를 얼마나 잘 처리하는지 잘 모르겠습니다.
  • 비슷한 SMP 머신이지만 VMware를 실행하는 하이퍼 바이저 또는 Solaris 10이 있습니다. 이 바보 같은가, 아니면 일부 일정 혜택을 제공합니까? 단점 : 저장소 병목 문제를 해결하지 못합니다.

나는이 가능성을 시험해보고 실험하려고하지만, 나는 무엇인가 놓친 지 확인하려고했다. 감사!

+0

질문이 serverfault.com에 더 적합합니다. – Copas

+0

그래, 인프라 문제에 관한 질문이기 때문에 확실하지는 않지만 프로그래머가 알기를 원하는 주제에 대해서. 저기서해볼 게. 감사. –

+0

빌드 시스템 측면은 확실히 프로그래밍 도메인에 있지만 실제 컴퓨터 설정은 아마도 Serverfault.com에 속할 것입니다. – JesperE

답변

0

빠른 증분 성능에 관심이 있다면 재 작성해야하는 파일을 계산하는 데 드는 비용이 실제 컴파일 시간보다 우위를 점하게되며 이로 인해 시스템 간의 효율적인 I/O 요구가 높아집니다.

그러나 예를 들어 야간 빌드와 같은 빠른 전체 재 작성에 관심이있는 경우 소스 트리를 각 빌드 슬레이브로 rsyncing하는 것이 더 좋을 수도 있고 각 빌드 슬레이브가 자체 빌드를 체크 아웃하는 것이 더 나을 수도 있습니다 소스 컨트롤에서 복사. Hudson과 같은 CI 시스템은 각 슬레이브 빌드 서버를 관리하는 데 도움이됩니다.

+0

답해 주셔서 감사합니다. 우리의 문제는 빌드 및 릴리스 관점에서 두 번째입니다. 소스의 크기는 모든 빌드에 대해 복사하기가 다소 어렵지만 빠른 네트워크에서는 가능합니다. 우리는 Hudson을 사용 해왔고 (AnthillPro와 같은 다른 빌드 시스템을보고 있습니다), 우리는 빌드 팜을 가장 효과적으로 확장하는 방법을 알고 있습니다. –

+0

확실히 serverfault.com에 대한 질문입니다. – JesperE

1

소프트웨어 솔루션에 관한 한 Icecream을 추천 할 수 있습니다. SUSE가 관리하고 distcc를 기반으로합니다.

우리는 당신이 설명하는 것과 비슷한 빌드 요구 사항을 가진 이전 회사에서이를 성공적으로 사용했습니다.

0

makefile이 충분히 완성되고 잘 구조화 된 경우 빌드 머신에 충분한 메모리가있는 경우 플래그가 I/O 병목 현상을 극복하는 데 유용 할 수 있습니다. 이렇게하면 여러 독립 작업을 병렬로 실행할 수 있으므로 CPU가 I/O 대기를 차단하지 않는 것이 이상적입니다. 일반적으로 컴퓨터에있는 것보다 여러 가지 작업을 허용하여 좋은 결과를 얻었습니다.

현재 메이크 파일에 적합하지 않거나 make와 완전히 다른 것으로 건너 뛰고 싶지 않은지 확실하지 않습니다.