개발자로서의 경험을 가진 나로써는 '새장비 들어왔을 때 컴파일 좀 다시 한번 한다고 해서 문제가 될까 ? ' 하고 생각한 적이 있다. 그러니까, 썬에서 중요하게 여겼던 이진 화일 호환성에 대해서 큰 메릿을 못느꼈던 것이다. 그러다, 시간이 지남에 따라 많은 자신의 주요 업무가 증가하고, 봐야할 장비가 늘어나면서, 혹은 지금은 없어졌지만 예전 코드가 남아 있는 경우에 새로운 장비에 예전 이진 화일을 그냥 사용할 수 있는 것이 얼마나 커다란 생산성을 제공하는 지를 새삼스럽게 깨닫곤 한다. 테스트를 해야한다거나 특정 사실만 확인하면 될 급할 때 컴파일러 준비해야 하고 버젼 확인해되고 컴파일하고 디버깅하고 등등 이런 준비를 한다는 것이 생각보다 커다란 부하임을 느끼게 된 것이다. 만약 이럴때 운영체제가 예전 이진 화일의 호환성을 유지해준다면 그냥 돌려보고 확인하면 되는 경우도 많기 때문이다.
그러다 보니, 나를 포함한 많은 솔라리스 사용자들은 어느새 이런 주요 기능에 젖어있게 됐고 너무나 당연한 기능으로 생각하게 됐다. 그러다 보니, 여기서 발생하는 부작용이 나타났다.
8년째 같은 바이너리를 사용해오고 있는 고객이 있었다. 그 사이에 장비는 종류만 4번 바뀌었다.
어느날 나에게 연락을 해서는 클럭도 높고 새로나온 장비를 샀는데, 빠르긴 한 것 같은데 확 빨라졌다는 느낌을 못 받겠다. 왜 그런지 알 수 있겠나라는 요청을 해오셨다. 사실 이런 경우에는 개발자 컨설팅 서비스를 사셔야만 지원을 받을 수 있는 문제인데, 연간 서비스 비용으로 10억씩 내시는 분들이기 때문에 그냥 컨성팅 해드리기로 했다 ^^;
고객분의 애플리케이션을 확인해봤다. 시스템 사용 상태로 봐선 나쁘진 않았다. 하지만, 업무 시작하는 시간대에 부하가 증가(CPU usage 100%)해서 지연시간이 꽤 길었다가 부하가 떨어지면 정상적인 현상대로 내려오는 상황이었다.
사실 언뜻 생각해보면 시스템의 성능 대비 부하가 많아서 생긴 지극히 정상적인 상황이라고 할 수 있다. 그러나, 이런 현상에서 시스템의 업무 부하율을 평균 50% 이하로 유지해야 하는 고객의 입장에서는 장비를 추가로 구매해야 하는 상황이었다.
사실 벤더에서 일하는 엔지니어의 입장에서 보면 그냥 장비를 추가 구매하실 것을 권고하는 것이 맞을 수 있겠다 싶었다. 그런데, 고객분은 내부적으로 그럴 입장이 아니었던 모양이다. 내부적으로 테스트를 충분히 하셔서 새 기종이 적정 기종이라고 주장해왔고, 새로 구매한 플랫폼의 개수가 적정수라고 보고했던 것이다.
그런데, 막상 부하를 올려보니 위 그림 처럼 나온 것이다. 따라서, 추가 구매를 하면 당신 자신이 매우 곤란한 입장이고, 추가 구매를 안하자니 서비스가 불안한 상황이 된 것이다. 그래서 나를 부르게 되었던 것이다.
나는 일단 개선의 여지가 있는 지 확인해보기로 했다. 마침, 서비스 팀에서 이제는 상당히 보편화된 dtrace를 이용해서 애플리케이션의 락(lock)을 분석한 보고서가 있었다. 내 시간을 많이 덜어준 셈이다.
아래는 dtrace 결과를 통해서 보고된 내용중 일부이다.
===== Count ========
_write 410
.....
_save_nv_regs 2100
strcmp 5594
memcpy 8572
====== Time [Nano Second] ========
memcpy 51474200
_write 204638300
----------- dtrace end ---
보고서를 보니 해당 서비스 애플리케이션이 memcpy, strcmp를 많이 호출하는데다 소요 시간이 가장 긴 부분임을 알 수 있었다. '음... 메모리 오퍼레이션을 개선해볼 수 있겠는데' 라는 생각이 즉각적으로 들었다.
사실 해당 애플리케이션은 컴파일된지 근 8년이나 되는 오래된 애플리케이션이었다. 이전에 있던 플랫폼은 SF4900인데 반해 새 장비는 M3000 장비였다. 그렇다면 같은 스팍 구조의 CPU이긴 하지만 두개의 플랫폼은 클락을 제외하곤 캐쉬에서 큰 차이가 있다.
너무나 당연하게 캐쉬가 다르면 메모리 오퍼레이션에서 상당한 오버헤드가 만들어질 수 있다. corestat이나 cpustat으로 더 자세하게 분석할 수 있겠지만 확신이 들었기에 그런 과정을 생략하고 보유하고 있는 애플리케이션의 재컴파일을 요구했다. 썬스튜디오 12U1으로 컴파일했다.
단순히 재컴파일만 했는데 다음과 같은 놀라운 결과를 보였다. 부하가 몰렸을 때에도 고작 100% 밑을 돌았고, 전체 평균으로는 50%를 하향하는 매우 안정적인 상황으로 반전되었다. 고객은 당연히 놀라워하고 기뻐했다.
사실 이런 경우는 매 새로운 플랫폼이 들어올때마다 재컴파일을 했으면 생기지 나타나지 않았을 문제이다. 그러나, 현업에서는 몰리는 부하도 감당하기 힘든데, 장비가 들어올때마다 형상관리를 새롭게 변경하는 것도 쉬운일이 아닌 것이다. 그래서 솔라리스의 이진 화일 호환성 지원은 빛을 발해왔던 것이다. 그러나, 위와같은 부작용도 간혹(8년에 한번정도) 발생하긴 한다.
좋다고 해야할 지 나쁘다고 해야 할 지 헷갈릴 수도 있겠다.
간혹 고객분들 중에는 나름 테스트를 하기 위해서 여러 장비를 놓고 테스트를 하는 경우가 있다. 경쟁사에서는 무조건 재 컴파일을 요구해서 재컴파일을 해서 테스트하시고, 솔라리스에서는 잘 도니까 그냥 테스트하신단다. 얼핏 들으면 썬에 매우 우호적으로 들리는데 결과가 솔라리스에 불리하게 나오면 짜증내신다.... 컴파일할 때 같이 하셔서 하시지...
위 컴파일 시 사용되었던 컴파일러는 썬스튜디오 12 업데이트 1이다.
적용했던 컴파일 옵션은 다음과 같다.
32bit:
CFLAGS= -g -fast -xO3 -xtarget=native -D_POSIX_PTHREAD_SEMANTICS
64bit:
CFLAGS= -g -fast -xO3 -m64 -xtarget=native -D_POSIX_PTHREAD_SEMANTICS
여기에서 중요한 옵션은 -fast 옵션이며, 그외 -xO3는 이기종 스팍 플랫폼간 호환성(플로팅 포인트 연산간 호환성)을 위해서 덜 최적화하는 옵션이다. -xtarget 옵션은 -fast 매크로에 포함되어 있는 것이나 native 플랫폼 최적화를 명시한다는 의미에서 넣어졌다. 만약 해당 최적화가 다른 구 스팍 플랫폼에서 호환성 문제를 야기한다면, -xtarget=native를 -xtarget=generic 으로 변경해서 컴파일해야 한다.
