고객이 사용하는 환경을 그대로 유지하고 싶은 채 컴파일 속도를
증가 시키고 싶으면, 몇가지가 있을 수 있습니다.
1) 현재 컴파일 서버 만을 업그레이드 하는 경우
현재 썬에서 제공하는 X4600을 사용하면 용량이 두배정도 증가하니,
IO를 충분하게 유지한다는 가정하에서 소요 시간이 절반으로 줄겠죠.
2) 컴파일을 대행해주는 접속 노드 환경 구축
고객 노트북 -> 컴파일 클러스터 노드 -> 소스 화일 서버
같은 아키텍쳐를 유지함으로써 각 노드부하별 사용자들이 컴파일 노드로
원격접속한후 소스 화일 서버에서 공유된 화일 시스템을 마운트한 후 각 노드별로
컴파일하는 방법이 있습니다. 이렇게 하기 위해서는 사용자들이 각 서버의
노드의 사용율이 얼마나 되는 지를 임의 배분하거나, 스스로 판단해서 접속한 후
실행해야 하며, 사용자간 컴파일 의존관계를 가지고 있지 않아야 합니다.
이런 구조로 구성하려면, 저가의 접속 서버를 확장 구축해서 접속 서버들이 각각 컴파일 하도록 합니다. 소스는 공유 소스 서버에서 가져와서 컴파일한 후 소스 서버에 저장하도록 합니다.
윈도우즈 컴파일러가 분산 컴파일러(멀티 cpu에서 컴파일되는 것을 지원하는 컴파일러)
가 아니라면 노트북에서 컴파일이 3시간이라고 했으니, 서버가 비슷한 구조면
혁신적으로 빨라지기는 어렵습니다만(CPU를 하나만 죽어라 쓸테니) 접속 서버로
Dual core 1cpu server를 사용자의 1/4 정도 구축하고, 뒤에 X4600같은 화일 서버를 소스 서버로 구축하고, 기가비트로 서버간 접속을 구성하고, X4600은 스위치까지 4G trunking을 사용하길 추천합니다. 소스 화일 서버로 윈도우즈를 고집하지 않는 다면, Thumper에 삼바를 올리는 것도 아주 훌륭함.
장점은 구축하기 쉽다. 쓰기 편하다. 비용 적게 든다.
하지만, 컴파일 속도 개선은 컴파일 서버 노드의 CPU 성능을 벗어나지 못한다.
3) 컴파일을 대신해주는 컴퓨팅 노드 구축(Grid)
현재 사용하는 고객 환경과는 거리가 있는 것으로 보입니다. 이런 환경으로 구축하려면 Grid 환경과 그리드를 지원하는 소프트웨어(컴파일러)등을 사용해야 하는데, 윈도우즈 기반의 그리드는 제 소관 밖이어서 드릴 말이 별로 없습니다만 구성은 가능합니다.
현재 컴파일 속도를 배가하는게 가장 좋은 기술입니다만, 사용 환경과 컴파일러등에 영향을 많이 받습니다. 장기적으로는 이 환경을 구축하는 것이 바람직합니다만, 아직 windows 기반의 HPC 기술은 매우 초기 단계로 취약합니다. 그래도 관심이 있어할 수 있으므로 사이트 자료를 참고해서 제안하세요. 그리고, 우리가 제안하기엔 아주 취약합니다.
( http://www.microsoft.com/hpc ; microsoft 기술 자료임)
http://cmssrv.tc.cornell.edu/ctc/winhpc/ ; 코넬대학 자료임
4) Code Versioning System 사용
각 사용자들이 소스 서버의 소스를 각 사용자의 시스템으로 다운로드한 후 컴파일한 후 서버로 재 업로드하는 방법으로 적정 소스 관리 툴을 사용해야 합니다. 오픈 소스계열에서는 CVS가 가장 많이 사용됩니다. software 이름으로는 rcs 이고.. 커머셜 제품도 꽤 많이 있습니다.
이런 경우의 단점은 소스코드의 유출이 있을 수 있으며, 컴파일 속도가 노트북 성능을 넘어서 나올 수 없습니다. 노트북보다 빨라야 한다고 했으니, 이 방법은 바람직하지 않을 것으로 보임.
2006/08/30
초고속 컴파일 환경 구축 방안
작성자: 스마트라이프 시간: 16:48
피드 구독하기:
댓글 (Atom)
댓글 없음:
댓글 쓰기