Sun Grid Engine

Sun Grid Engine이라고 Sun에서 만든 일종의 scheduler가 있다. 단일 task를 submit하면 시스템 부하를 봐가며 투하하는 그런 daemon이라고 볼 수 있다. 그러니까 network으로 여러 대의 장비가 물려있고 single thread로 돌아가는 job을 설정만 바꿔가며 많이 돌려야 한다고 치면, 이 daemon에다가 그 job을 실행해달라고 한 개씩 접수시키면 sge라는 계정이 만들어져 있고 이 daemon이 listen하고 있는 tcp port가 있으면 sge가 이 일을 대신 돌려준다. 그러니까 평소 시스템 부하를 관찰하고 있다가 실행시켜야 할 일이 접수되면 그것을 노는 장비에 투하시켜서 실행하고 그 결과를 전달해주는 것이다. console로 나가는 게 있으면 다른 장비에서 실행시킨 것을 마스터 쪽으로 redirection을 한다든가 하는 일도 하겠지.

그런데 원래 이런 일에 익숙하다고 보면, 바보같이 일을 이렇게 시키기보다 자신의 application에서 fork로 여러 개의 일을 벌이거나 아니면 그냥 background job으로 여러 개를 벌려놓거나 해도 된다. mpi를 쓰면 더 간단하고 빠르게 할 수 있는데, 대개 공학적인 소양이 없는데 엔지니어링 세계에 있는 이들은 이상하게도 전통적인 방식을 고수하려고 하는 경향이 있다.

지금은 sun grid engine이라고 하지 않고 오픈소스로 개발되어 son of grid engine이란 이름을 달고 있고 그 스스로도 그 스스로를 부르기에 옛날 SGE의 재탕이다라고 할 정도다. 말이 그리드이고 그리드엔진이지 그냥 스케줄러다. 한방에 병렬로 후다닥 해버릴 수 있는 일을 수도 없이 쪼개서 이 스케줄러에 실행을 의뢰하는 일을 해야하는 건데 또 이런 이들은 꼼꼼하게도 꾸역꾸역 이 일을 한다. 해낸다라고는 할 수 없다. 이 인간도 정상적인 인간이면 이걸 꼬박 꼬박 꾸역 꾸역 오래 지속해서 할 수 없다. 처음엔 대단한 것이라도 하는 양 떠들지만 좀 지나면 금방 흐지부지된다.

내가 말하고 싶은 것은 어쩔 수 없이 single thread로 돌아야 하는 상용 소프트웨어 (synopsys의 vcs같은 게 여기 속한다)를 써야 되고 그게 대단위로 돌아야 한다고 하면 SGE가 좋은 답이 된다. 관리하기가 편해지니까.

하지만 내가 만들어서 돌려야 되는 것이라면 single thread로 꾸역꾸역 돌려야 할 이유가 없다. 더구나 개개의 single thread process의 결과가 개별적인 파일로 떨어지게 되는데, 그거 언제 다 취합하고 자빠졌나. 그냥 MPI를 쓰면 단일 창구에서 취합되어 정리되는 걸. 또 순차적으로 돌리면 결과가 한 곳에 차곡차곡 쌓여서 골피 아플 이유도 없다.