Sun Developer Network 공식 블로그

자바 어플리케이션의 플랫폼 독립성은 개발자들이 "한번 작성하고, 어느곳에서나 실행한다"는 패러다임을 이용할 수 있도록 합니다. 그와 더불어 자바 프로그래밍 언어의 인기는 플랫폼 제공자들이 특히 서버 분야의 자바 벤치마크 테스트 에서 최고의 퍼포먼스를 낼 수 있게 서로 경쟁을 하도록 하고 있습니다. 결과적으로 기업들은 자바 환경에서 고성능의 어플리케이션 서버를 배치할때 지출 대비 퍼포먼스 레벨이라는 관점에서 많은 선택사항을 가지고 있습니다.

자바 개발자는 그들의 어플리케이션을 개발하고 배치할 플랫폼의 다양한 선택을 가지고 있습니다. 자바 개발 시스템을 평가 할때 개발자는 보통 적어도 아래와 같은 점을 고려 합니다:

• 성숙도, 보안성, 그리고 안정적인 운영체제. OS 를 디버그하는 기능 없이 어플리케이션의 버그를 추적하는 것은 매우 힘듬.
  
  
• 자바특수한 분석, 디버깅 그리고 모니터링 툴.
  
  
• 고성능의 자바 가상 머신(JVM) 바이트코드 실행 엔진과 동적 최적화 컴파일러.
  
  
• 고성능의 통합 개발 환경(IDE). 좋은 IDE는 코드-컴파일-배치-테스트 싸이클을 줄여 준다.

최고의 자바 개발 플랫폼을 선택하는 것은 복잡합니다. 왜냐하면 자바 프로그래밍 툴의 개발자들은 다른 자바 개발자 같이 어떠한 플랫폼에서도 동일하게 실행되도록 툴을 디자인하는데 최선을 다하기 때문입니다. 그렇다면 플랫폼 하단의 하드웨어의 성능문제를 제외 하면 모든 자바 개발 환경은 동일하게 만들어 졌을까요? 그렇지는 않습니다.

이 글은 운영체제들 간의 일대일 비교를 시도하지 않습니다 그러나 대신 솔라리스가 네이티브한 기능과 JVM 그리고 자바 개발 툴과 어떻게 결합되는지에 대해 살펴볼 것입니다. 별다른 지시가 없으면 이 글에서 말하는 솔라리스는 솔라리스 10 운영체제를 뜻합니다.

툴과 기술에 대해 언급하기 전에 솔라리스의 기본적인 두가지 장점에 대해 고려해 봅시다.

첫째로 솔라리스는 tier 1 자바 개발 플랫폼 입니다. 썬은 HotSpot JVM 과 Java SE JDK 의 대부분을 솔라리스에서 처음으로 개발했습니다. 그러므로 솔라리스는 자바를 위해 가장 중요한 퍼포먼스 최적화 플랫폼입니다.

둘째로 솔라리스는 특이하게 자바 플랫폼에 대한 서포트를 솔라리스 서포트 계약에 포함하고 있습니다. 썬 자바 데스크탑 시스템 R3 와 자바 2 플랫폼5 는 통합되어 있고 솔라리스 서비스 플랜하에서 지원됩니다.(몇몇 컴포넌트들을 제외한) 다른 어떠한 운영체제도 이와 유사한 자바 서포트를 제공하고 있지 않습니다.

솔라리스 운영체제 SunOS 코어는 개발자들에 친숙한 UNIX 쉘 커맨드와 툴을 제공하고 오픈 그룹(Open Group) 의 Unix 98 명세(SUS ver 2 로도 알려짐) 를 따릅니다. 솔라리스10은 GUI 윈도우 시스템, 웹 브라우저, 그리고 SunOS 코어 툴들을 추가했습니다. SunOS 코어는 현재 AT&T SVR4.0 에 기원을 두고 있고 수백개의 유틸리티, 유저레벨 프로그램들이 BSD 기반의 SunOS 4대 부터의 레가시 어플리케이션과 스크립트에 대한 하위호환성을 보장합니다. 성숙된 그리고 안정적인 운영체제로써 솔라리스는 추천할만 합니다.

• SPARC 과 x86 플랫폼 둘다에서 사용이 가능하고 수천개의 오픈소스 그리고 ISV 어플리케이션들이 지원됨.
  
  
• 2005년 6월에 OpenSolaris 를 출시 함으로써 솔라리스의 핵심 소스 코드는 모두 OSI 가 승인한 오픈소스 라이센스, CDDL 하에서 오픈 소스 커뮤니티에 무료로 제공되고 있습니다. 오픈 소스 커뮤니티의 노력으로 오픈솔라리스가 Power/PowerPC 로 포팅되는 작업이 진행중임.
  
  
• 상용 UNIX 와 리눅스 배포판중에서 가장 큰 설치기반을 가지고 있음. 2006년 11월 자로 7백만 이상의 카피가 등록 되었음.
  
  
• 만약 테스팅과 QA가 개발 프로세스의 일부로 포함되어 있다면 솔라리스의 잘 알려진 확장성이 또한 장점이 될 수 있음. 현실적인 로드 테스팅은 업계 표준의 운영체제와 일반적인 서버 하드웨어가 필요함.

솔라리스의 광범위한 사용과 안정성은 엔터프라이즈와 웹 기반 어플리케이션의 배치 플랫폼으로 계속적으로 논의를 불러 일으키고 있습니다. 자바 개발자 측면에서는 네이티브한 기능이 일반적으로 얼마나 개발을 잘 지원해 주는지, 사용가능한 개발툴이 질과 양 측면에서 얼마나 괜찮은지가 중요한 고려 사항입니다. 이러한 툴 (무료와 표준을 준수하는 것을 선호함) 은 IDE 와 분석, 디버깅 툴, 컴파일러 그리고 JVM 을 모두 포함합니다.

NetBeans IDE 는 Prague 에 있는 Charles 대학의 학생 프로젝트로 1996년에 시작 되었습니다. 썬은 1999년에 이 기술을 매입했고 2000년도에 이것을 오픈소스로 전환했습니다. 비록 수 많은 메이저 플랫폼들에 포팅 되었지만 솔라리스는 여전히 NetBeans 배포판의 제 1 tier 입니다. NetBeans IDE 는 썬의 페이지 에서 무료로 다운받으실 수 있습니다.

NetBeans IDE 는 자바 데스크탑, 엔터프라이즈, 웹 어플리케이션 -- 자바 SE, 엔터프라이즈 자바빈(EJB), 자바 ME 모바일 어플리케이션등을 포함 개발을 지원하고 있습니다. IDE는 오픈 소스 툴인 Ant 를 통해서 프로젝트 빌드 프로세스를 자동화 합니다. 또한 버전 컨트롤과 리팩토링 기능을 지원합니다.

NetBeans IDE 의 모든 기능들은 모듈로써 제공되고 이것은 IDE 가 확장될 수 있도록 해 줍니다.다른 프로그래밍 언어를 지원하는 것 같은 새로운 기능들은 추가적인 모듈을 설치 함으로써 추가가 가능합니다. Visual Web Pack 모듈을 통해 NetBeans IDE 는 웹어플리케이션을 위한 드래그-앤-드롭 빌드 기능을 제공합니다. NetBeans Enterprise Pack 은 자바EE 어플리케이션의 개발을 지원하고 SOA 비주얼 디자인툴, XML 스키마 툴, BPEL 을 이용한 웹서비스 orchestration, 그리고 UML 모델링 같은 것들을 포함하고 있습니다.

가장 중요한 점은 NetBeans IDE (그리고 이에 기반해서 개발되는 썬 자바 스튜디오 크리에이터 와 썬 자바 스튜디오 엔터프라이즈)를 통해 생성한 Java EE 호환 코드는 여러분의 어플리케이션이 안전하게, 서버 제공사와 관계 없이, 그리고 어떠한 라이센스 요금 없이 호환 서버들 끼리 이동이 가능하도록 해 줍니다.

몇몇 추가적인 IDE 들이 솔라리스와 다른 플랫폼들을 위해 개발되어 왔습니다. 이것들은 NetBeans IDE 를 기반으로 하는 썬 자바 스튜디오 크리에이터와 썬 자바 스튜디오 엔터프라이즈 입니다. 이것들과 다른 개발 툴은 썬의 페이지 에서 다운로드 가능합니다.

다른 오픈 소스 그리고 써드 파티 IDE 들(솔라리스 x86 플랫폼에서 Eclipse 같은) 또한 사용이 가능합니다.

DTrace 는 동적 추적 설비로써 솔라리스에 포함되어 있습니다. 이것은 사용자 프로그램과 운영체제 자체의 행동을 검사할 수 있습니다. DTrace 는 사용자가 시스템을 탐색해서 어떻게 동작하는지, 다양한 소프트웨어의 레이어상에서의 퍼포먼스 문제를 추적할때, 소스 코드의 에러를 찾아 낼때 모두 사용될 수 있습니다.

프로덕션 상태의 어플리케이션을 디버깅하는데 크래쉬 덤프와 메모리 스냅샷을 사용하는 것은 비실용적입니다. DTrace 를 통해서 사용자는 시스템을 검사하여 "내 프로세스를 죽인 시그널이 어디서 들어 왔지?" 혹은 "특정 쓰레드가 왜 비선점됐지?" 같은 질문에 대한 대답을 얻을 수 있도록 해 줍니다.

솔라리스는 DTrace 로 추적할 수 있는 30,000 개 이상의 접근 포인트를 제공하고 또한 필요하면 추가적으로 접근 포인트를 만들 수 있도록 해 줍니다. DTrace 를 사용해서 사용자는 운영체제의 특정 지점에서 데이타를 수집해서 어떻게 여러분의 어플리케이션이 솔라리스와 상호작용하는지를 알아 볼수 있도록 합니다. DTrace 는 라이브한 개발 혹은 프로덕션 환경에서 사용될 수 있도록 디자인 되었고, 다른 어떠한 툴로도 볼 수 없는 시스템의 전반적인 정보를 볼 수 있도록 합니다.

2006년 12월에 출시된 Java SE6 은 DTrace probe 를 기본적으로 포함하고 있어서 사용자가 손쉽게 현재 실행 중인 바자 어플리케이션의 상세 정보를 수집할 수 있도록 도와 줍니다.

DTrace 는 오픈솔라리스 커뮤니티의 일부 이기 때문에 이것은 지속적으로 다른 운영체제들 에 포팅될 것입니다. 그러나 썬에서 처음 출시하는 다른 모든 툴 처럼 최신의 DTrace 기능은 솔라리스에서 제일 먼저 출시되고 테스트될 것입니다.

DTrace probe 는 솔라리스의 매개 포인트 입니다 ? 시스템의 상세정보를 알아볼 수 있는 장소.

probe 는 probe 를 구분할 수 있는 4가지 속성을 이름으로 가집니다. :

provider:module:function:name
        

• Provider ? probe 는 providers 에 의해 사용가능해짐.DTrace의 핵심 요소. syscall 은 provider 의 예제임.
  
  
• Module ? 각 probe 는 module 과 연관되어 있음. modules 은 커널 모듈들의 이름을 가지고 있음: ufs, nfs, libc 등등.
  
  
• Function ? 각 probe 는 역시 마찬가지로 function 가 연관되어 있음. 함수의 예제로는 malloc 으로 모듈 libc 에 존재함.
  
  
• Name ? 각 probe 는 또한 enter 혹은 return 같은 name 을 가짐.

이러한 명명 규칙은 사람들이 쉽게 probe 를 구분할 수 있도록 가독성을 제공 합니다. 와일드카드 문자 “*” 와 “?” 가 사용 가능합니다. 또한 속성을 지정하지 않고 그대로 놔둔다면 속성에 위치에 가능한 모든 값들이 포함됩니다. 예를 들어 다음의 예제는:

syscall:::entry
        

syscall provider 는 모든 시스템 콜의 진입과 리턴 시점을 검사 합니다. 이 예제에서 module 과 function 값이 생략됐으므로 매칭은 모든 시스템 콜에 들어 갈때 이루어 집니다.

다른 예제로 다음을 보시기 바랍니다:

syscall:open::entry
        

이 예제는 open 시스템 콜의 진입시에 매칭됩니다.

D 프로그램 소스는 그림에서 a.d 혹은 b.d 로 표현됩니다. 프로그램을 dtrace 커맨드를 이용해 실행할때, 커맨드는 프로그램을 해석하고 그것을 libdtrace 라이브러리를 이용해서 중간 레코드로 기록 합니다. 소스가 해석되면 이것이 라이브 시스템에서 실행해도 안전한지 테스트 됩니다. 그 다음에 DTrace 가 중간 레코드를 수락하고 이것을 커널로 로드한다음 커널 모듈로 변환합니다.

그림 1: DTrace ? 동작 방법

커널의 DTrace provider 는 프로그램 커널 모듈의 probe description 의해 깨워지고 probe 가 실행됐을때 프로그램으로의 콜백을 제공 합니다. 콜백은 프로그램 내의 액션 구문이 실행되도록 합니다. 일반적으로 이러한 액션 구문은 수집, 간결화, 데이타 보고 입니다.

provider 는 자바 코드를 위해 개발되어왔습니다. provider 는 DTrace 가 자바 어플리케이션의 지능적인 정보를 수집할 수 있도록 합니다. 예를 들어 가비지 컬렉션이 언제 일어 났는지와 메소드 콜에 대한 정보 수집등을 할 수 있습니다.

DTrace 프로그램은 일반적으로 매우 간단합니다. Probe descriptions 은 probe 를 활성화 하고 모니터 합니다. 그리고 액션 구문은 probe 가 실행됐을때 무엇을 할지에 대해 설명하고 있는 probe description 을 따릅니다.

D 언어 프로그램은 다음과 같은 구조를 가지고 있습니다:

#!/usr/sbin/dtrace -s
provider:module:function:name
/predicate/
{
   action statements
}

첫번째 줄은 이 파일을 D 언어 스크립트로 구분되도록 합니다. 이 줄은 아래와 같이 dtrace 커맨드로 스크립트를 직접 실행했을때에는 필요 하지 않습니다:

dtrace [options] script_name
        

스크립트의 둘째 줄은 probe (혹은 probe 의 셋) 을 구분합니다.

세번째 줄은 선택사항인 predicate 로 슬래쉬 문자로 구별합니다. 액션 구문은 오직 predicate 가 참일때에만 실행 됩니다. predicate 섹션은 사용자가 액션 구문을 실행하는 특정 조건을 설정할 수 있는 필터로써의 역활을 합니다. 사용자는 조건을 실행파일의 이름 같이 많은 기준에 따라 설정할 수 있습니다.

액션 구문은 사용자가 시스템의 특정 상태의 정보를 수집하고 보고 할 수 있도록 도와 줍니다. 몇몇 probe 는 일반적인 정보를 가지고 있고 다른 것들은 꽤 상세한 정보를 제공 합니다.

특별한 probe 인 BEGIN 은 DTrace 프로그램이 시작될때 반응합니다; 비슷한 probe 로는 END 가 있고 DTrace 프로그램이 종료할때 반응합니다. 다음의 D-언어 프로그램이 실행될때 BEGIN probe 가 반응하며 문자 “Hello World” 를 출력하고 프로그램을 종료 합니다. 프로그램이 종료 되면 END probe 가 반응 하고 “Goodbye Cruel World.” 를 출력합니다. 프로그램에는 predicate 가 존재하지 않습니다.

#!/usr/sbin/dtrace -s
BEGIN
{
  printf("Hello World\n");
  exit(0);
}

END
{
  printf("Goodbye Cruel World\n");
}

다음의 프로그램에서 probe 는 시스템 콜이 실행될때 마다 활성화 됩니다 (syscall:::entry). predicate 절 (/execname=="bash"/) 은 액션 구문이 오직 bash 실행 파일에 의해 실행된 시스템 콜에만 반응하도록 제한 합니다. 여러분은 대신 윈도우 시스템을 위한 xsun 이나 혹은 자바 어플리케이션을 위한 java 로 설정할 수 있습니다.

action 구문은 내장변수인 probefnc 를 출력하도록 합니다.

#!/usr/sbin/dtrace -s
syscall:::entry

/execname=="bash"/
{
          printf("%s called\n",probefnc);
}

You can easily modify the above script to print only the
system calls made by 'java.'

#!/usr/sbin/dtrace -s
syscall:::entry
/execname == "java"/
{
          printf("Java(%d) called syscall %s\n", pid, probefunc);
}

JDK 6.0 은 JVM 에 대한 정보를 제공하는 두가지의 DTrace provider 가 내장되어 있습니다: hotspot 과 hotspot_jni 입니다. hotspot_jni provider 는 여러분의 자바 어플리케이션 상에서 JNI 호출에 대한 자세한 정보를 수집합니다.

타겟 어플리케이션에서 가비지 컬렉션이 언제 일어 났는지 출력해 주는 간단한 스크립트를 보시기 바랍니다. 내장 변수 walltimestamp 은 절대 시간을 가지고 있습니다 (1970년 1월 1일 00:00 부터의 나노세컨드). $target 변수는 프로세스 아이디로 -p 옵션을 통해서 스크립트로 전달 됩니다.

gc-begin probe 는 가비지 컬렉터가 시작될때 반응합니다.

hotspot$target:::gc-begin
{
        printf("GC started at %Y\n",walltimestamp);
}

이 스크립트를 실행하기 위해서는 첫번째로 자바 어플리케이션의 프로세스 아이디를 찾아야 합니다. 그 다음에는 프로세스 아이디를 스크립트를 실행할때 커맨드라인 매개 변수로 사용 합니다. 예를 들어 스크립트의 이름이 hotspot_gc.d 로 명명되었고 어플리케이션의 프로세스 아이디가 7792 라면 커맨드라인은 다음과 같이 될 것입니다:

    dtrace -qs hotspot_gc.d -p 7792
        

다음의 그림에서 스크립트는 pid 7792 를 가진 jedit 프로세스를 타겟으로 구동되고 있습니다. 참고하실 점으로는 jps 를 통해서도 타겟 시스템에 HotSpot Java Virtual Machines (JVMs) 의 목록을 보실 수 있습니다. jps 툴은 접근 권한을 가진 JV 의 정보를 리포팅하는 것으로 제한됩니다.

그림 2: DTrace Output

스크립트를 다음과 같은 수정함으로써 각 가미지 컬렉션 이벤트당 얼마의 시간이 소요됐는지 알 수 있습니다.

hotspot$target:::gc-begin
{
        printf("GC started at %Y\n",walltimestamp);
        self->ts = timestamp;
}

hotspot$target:::gc-end
/self->ts/
{
printf("\tand ran for %d milli secs\n",(timestamp - self->ts)/1000000);
self->ts = 0;
}

gc-begin probe 는 가비지 컬렉션 이벤트의 시작시에 반응합니다. 액션 구문은 절대 시작 시간을 출력해주고 변수 self->ts 는 시작 이벤트의 상대 시작 시간을 저장합니다.

gc-end probe 는 각 가비지 컬렉션 이벤트의 종료시에 반응합니다. 내장 함수 timestamp 가 probe 의 시작과 종료 사이의 시간차를 계산하는데 사용 됩니다. timestamp 는 반드시 이런 경우와 같이 상대적인 계산에만 사용되어져야 합니다.

jstack 은 주어진 자바 프로세스 혹은 코어 파일 혹은 원격 디버그 서버의 자바 쓰레드의 스택 트레이스를 보여 줍니다. J2SE 5.0 update 1 부터, jstack 은 DTrace 액션으로써 사용이 가능합니다. jstack 은 복합-모드 스택 트레이스 를 출력할 수 있고 (예를 들어 자바와 네이티브 C/C++ 언어 의 프레임들), 선택적으로 네티이브 프레임을 포함합니다. 또한 사용자가 락 과 데드락 에 관한 정보를 출력할 수도 있습니다.

jstack 은 시스템 정지 혹은 무한루프 같은 프로그램을 추적하는데 유용합니다. 시스템 정지(hang)에는 많은 이유가 있을 수 있습니다, 그러나 보통 어플리케이션 코드, API 코드 혹은 라이브러리 코드의 deadlock 에서 일어나게 됩니다. 종종 이러한 시스템 정지가 CPU 싸이클을 전부 잡아 먹는 무한 루프로 판명되기도 합니다.

정지된 시스템을 진단하는 첫번째 단계는 가상 머신 프로세스가 현재 idle 상태 인지 혹은 루프를 돌고 있는 쓰레드가 모든 CPU 싸이클을 잡아 먹고 있진 않은지 확인 하는 것입니다. 여러분은 운영체제 유틸리티를 이용해서 이러한 것이 사실인지 검사해 봐야 합니다. 솔라리스에서는 커맨드 prstat -L -p pid  를 통해서 타겟 프로세스 내의 모든 경량 프로세스들의 통계를 보여 주고 이를 통해서 CPU 싸이클의 대부분을 소비하는 쓰레드를 구분할 수 있도록 합니다.

만약 VM 프로세스가 루프를 돌고 있다면 문제의 원인을 발견하기 위한 첫번째 단계는 쓰레드 덤프를 얻는 것입니다. 그러나 만약 프로세스가 백그라운드 프로세스로써 실행 되거나 JVM 출력이 알수 없는 장소로 리다이렉트 되어 있다면 어떨까요? 이러한 경우 어플리케이션 콘솔과 표준 입/출력은 사용이 불가능 합니다. 어쨌거나 사용자는 jstack 유틸리티를 이용해서 스택 트레이스를 얻을 수 있습니다. jstack -F pid  옵션을 이용해서 루핑 되고 있는 프로세스의 스택 덤프를 얻습니다. RUNNABLE 상태에 있는 쓰레드들에 촛점을 맞추면 루핑되고 있는 쓰레드의 범위를 좁혀 나갈 수 있습니다.

여러분은 또한 JVM 내의 DTrace agent 라이브러리를 실행 시킴으로써 특정한 JVM 과 자바 플랫폼을 위한 DTrace probe 를 제공할 수 있습니다. 이 agent 는 dvmti 이고 Java Virtual Machine Tool Interface (JVM TI) 를 사용하여 다양한 JVM 이벤트를 요청하고 이러한 이벤트 들에 대한 콜백 코드를 DTrace probe 에 제공합니다.

DTrace 와 자바 기술의 통합외에도 자바 EE 소프트웨어는 다수의 검사 툴을 제공합니다. 이러한 툴은 어떤 플랫폼 상에서나 사용이 가능합니다. 그러나 그중에서도 솔라리스 gcore(1) 유틸리티와 툴들의 결합은 언급될 가치가 있습니다.

사후조사 툴은 멈춘 자바 프로세스 혹은 자바 코어 덤프의 정보를 제공합니다. 자바 툴은 솔라리스 gcore 유틸리티와 같이 사용될 수 있도록 디자인 되었습니다. gcore 를 이용해서 시스템의 코어 덤프를 얻은 다음에는 다음과 같은 툴을 이용하여 코어 덤프를 분석할 수 있습니다:

• jinfo ? 주어진 자바 프로세스 혹은 코어 파일 혹은 원격 디버그 서버의 자바 설정 정보를 출력.
  
  
• jmap ? 솔라리스 pmap 툴과 비슷한 정보를 출력.
  
  
• jstack? 이전에 논의 했듯이 jstack 은 솔라리스 pstack 툴과 동일하고 DTrace 와 같이 사용 가능.
  
  
• jsadebugd ? 자바 프로세스 혹은 코어파일에 부착되서 디버그 서버처럼 동작함. 원격 클라이언트 jstack, jmap, jinfo 같은 원격 클라이언트가 Java RMI 를 통해서 서버에 붙을 수 있음.
  
  
• jhat? a Java heap dump browser.

한개의 추가적인 개발 툴을 기억해둘 필요가 있습니다: Sun Studio Performance Analyzer 는 썬 스튜디오 컴파일러 툴의 일부 입니다.

자바 어플리케이션을 프로파일링 할 때, Sun Studio Performance Analyzer 는 JVM 상의 데이타를 수집합니다. 클럭 프로파일링, 하드웨어-카운터 프로파일링 그리고 동기적인 트레싱이 모두 지원됩니다.

Sun Studio Performance Analyzer 는 자바 프로세스의 각 LWP 마다의 이벤트를 기록하고 각각의 이벤트마다의 콜스택을 기록함으로써 데이타를 수집합니다.

자바 어플리케이션은 유일무이한 특징가지므로 예전의 언어로 쓰여졌던 어플리케이션 즉 네이티브하게 컴파일 되는 언어 의 프로파일링 과는 다르게 매우 어렵습니다. 자바 프로그램의 어떠한 메소드도 Hotpost JVM 을 통해 해석되는 버전이 존재하므로 HotSpot JVM 에 의해 동적으로 컴파일 되는 다른 버전이 존재할 수도 있습니다. 또한 자바 어플리케이션은 이미 컴파일된 네이티브 메소드를 직접 호출할 수도 있습니다. 이렇게 복합-모드 자바 어플리케이션에서 두개의 콜스택은 매우 의미가 있습니다: 자바 콜스택 과 머신 콜스택

두개의 콜스택은 Sun Studio Performance Analyzer 을 이용한 프로파일링 작업 시에 모두 저장되고 분석에 사용할 수 있습니다. 프로파일링 결과는 GUI 분석기 혹은 커맨드 라인으로 볼 수 있습니다. 3가지 서로 다른 representation 을 제공합니다:

• User Representation 은 컴파일 되고 해석된 자바 메소르를 이름 으로 보여주고 자연스러운 형태의 네이티브 메소드를 보여 줌.
  
  
• Expert Representation 은 User Representation 와 유사하지만 JVM 내부의 몇몇 상세 정보들이 노출 됨.
  
  
• Machine Representation 은 JVM에 의해 해석된 자바 어플리케이션 대신에 JVM 자체의 함수를 보여 줌.

솔라리스 컨테이너는 여러분이 완전히 분리된 솔라리스의 인스턴스를 설정함으로써 리소스, 오류, 안전한 독립성을 얻을 수 있도록 합니다. 솔라리스 컨테이너는 운영체제 가상화의 한 타입으로써 두가지 매인 컴포넌트로 구성되어 있습니다: 솔라리스 존과 솔라리스 리소스 메니저(SRM). SRM 은 물리적인 시스템 리소스를 관리하고 솔라리스 존은 네임스페이스 고립을 컨트롤 합니다.

배치 환경에서 솔라리스 컨테이너의 장점은 매우 명확합니다:

• 서버 통합에 따란 관리 비용의 감소화 운영체제 인스턴스 수의 감소. 비용을 절감하기 위해 회사들은 배치된 어플리케이션을 좀더 적은 수의 서버로 통합하기를 원함.
  
  
• 컨테이너 간에 동적인 리소스 할당을 통한 향상된 리소스 활용.
  
  
• 오류의 전파, 및 어플리케이션간의 보안 규정 위반등을 최소화 함으로써 서비스 가용성 향상.
  
  
• 향상된 유연성. 소프트웨어 기반의 컨테이너는 동적으로 재설정이 가능함.
  
  
• 계정의 향상된 계정의 정확성과 유연성. 시스템이나 프로세스가 아닌 워크로드에 기반을 둠.

개발자들에게 주는 장점 또한 명확합니다:

• 개발 그룹은 하나의 서버를 조직내의 다른 유저들과 공유할 수 있음. 각 컨테이너들은 고립되어 있고 보안성이 제공 되므로 다른 그룹들의 생산성에 영향을 주는 일이 없음.
  
  
• 개인 개발자들을 위해 솔라리스 컨테이너는 동일한 서버에 몇가지 독립된 실행 환경을 같이 존재하도록 함으로써 개발과 테스팅을 각각 독립적으로 수행할 수 있음.

리눅스 어플리케이션을 위한 솔라리스 컨테이너는 리눅스 어플리케이션이 솔라리스를 수정하지 않고도 실행될 수 있도록 합니다. 솔라리스 컨테이너의 모든 장점을 결합하면 이 기능은 최고의 가상화, 리소스 관리 그리고 OS 유연성을 제공합니다.

서보 공학은 Java SE 5.0 의 Hotspot JVM 에서 소개되었고, 서버 어플리케이션의 튜닝 타임 특히 힙 사이즈와 향상된 가비지 컬렉터 튜닝 등의 작업 시간을 크게 줄일 수 있습니다. 플랫폼 설정에 따라 이것은 최적의 컴파일러, 자바 힙 설정 그리고 가비지 컬렉터를 선택해 줍니다. 대부분의 경우 out-of-the-box 설정이 어플리케이션의 최고의 튜닝 옵션을 제공합니다 HotSpot JVM 은 모든 메이저 운영체제에 포팅되었지만 솔라리스는 여전히 tier 1 개발 플랫폼으로 남아 있습니다.

스마트 튜닝을 구현하기 위해서 JVM 은 JVM이 실행되고 있는 머신의 타입을 결정합니다. 만약 머신이 서버 클래스 라면 Hotspot JVM 은 좀 더 큰 힙을 할당하고 병렬 가비지 컬렉션을 구현 하고 서버 컴파일러를 사용합니다. 서버 컴파일러는 실행시간이 긴 어플리케이션을 위해 디자인 되었고 시작 시간과 메모리 풋푸린트가 중요하지 않고 런타임 퍼포먼스와 쓰루풋(throughput) 이 중요한 상황을 위해 사용됩니다.

만약 머신이 클라이언트 클래스라면 JVM 은 최소의 힙을 할당하고 직렬 가비지 컬렉션을 구현하며 클라이언트 컴파일러를 사용합니다. 클라이언트 컴파일러는 시작 시간이 짧고 작은 메모리 풋프린트가 중요한 상황을 위해 디자인 되었습니다.

JVM이 버서 클래스와 클라이언트 클래스 머신을 감지해 내든 말든지 간에 이것은 adaptive 힙 사이징 정책을 사용하여 퍼포먼스를 자동으로 튜닝 합니다. 개발자들을 위해서 서버 공학을 통한 자동화된 튜닝은 시간이 오래 걸리는 힙사이즈의 직접 튜닝이 없이도 최적의 성능을 얻어낼 수 있도록 합니다.

ZFS 파일 시스템은 솔라리스10에 처음 소개됐으며 일반적으로 시스템 관리자에게 커다란 장점 으로 생각 됩니다 ? 이 기술은 극적으로 스토리지 관리를 단순화 시켰고, 데이타 무결성과 고성능, 그리고 기본적으로 제한이 없는 확장성을 제공합니다.

개발자는 일반적으로 파일 시스템을 파일 시스템을 당연히 생각하고 대수롭지 않게 여기지만, 서서히 그들도 ZFS의 특별한 장점을 인식하고 있습니다.

한 솔라리스 개발자는 ZFS를 이용해서 그의 랩탑 컴퓨터에 몇가지 개발 워크스페이스를 유지 합니다. 워크스페이스들은 전체 솔라리스 개발 소스트리의 스냅샷으로 각각 2GB 사이즈를 가지고 있습니다. 몇가지 ZFS 커맨드들을 통해서 그는 하나의 프라이머리 워크스페이스를 로컬에 유지하고 필요한 만큼의 좀더 작은 워크스페이스들(diff 로 구성됨) 로 관리하고 있습니다. 이러한 접근을 통해서 그는 스크래치 빌드 워크스페이스를 통해서 개발 워크스페이스 외부에 빌드 결과물들을 보관합니다.

이러한 개발자들을 위해 ZFS는 매우 많은 수의 워크스페이스를 상대적으로 작은 용량을 가진 하드 드라이브상에서 제공합니다. 그리고 쉽게 관리할 수 있도록 합니다. ZFS는 디스크 용량을 아주 효과적으로 쓸수 있도록 해 줍니다.

ZFS의 관리 용이성은 개발자들에게 매우 편리 합니다. 예를 들어 ZFS는 단독 머신에 깔린 여러개의 솔라리스 설치본 간의 파일 시스템 공유를 쉽게 할 수 있도록 도와 줍니다. 파일 시스템을 공유하기 위해서, ZFS 풀을 만들고 이것을 각각 다른 솔라리스 설치본에 마운트 하고, 시스템 시작시에 zpool import , 종료시에 zpool export 를 수행하는 스크립트를 제공합니다. ZFS 는 ZFS 풀에 생성하는 어떠한 파일 시스템이라도 수작업으로 명시적으로 추가하거나 마운트할 필요가 없습니다 ZFS는 ZFS 풀에 생성하는 모든 파일 시스템을 자동으로 마운트 합니다.

자바 개발용 운영체제로써 솔라리스는 전통적인 언어를 개발할때 제공했었던과 같은 많은 잇점들을 제공합니다:

• 성숙도, 안정성, 넓은 사용자층
  
  
• IDE 와 디버깅 그리고 프로파일링 툴의 결합
  
  
• 확장성과 유지보수가 쉬운 ZFS 같은 진보 기술들

자바와 관련된 장점은 HostSpot Java VM과 통합된 프로파일링 툴을 포함합니다.

마지막으로 경쟁 운영체재들과의 추가적인 비교도 피할수 없습니다:

MS 윈도우와 비교해서 솔라리스는 다음의 기능을 제공합니다:

• 32-비트 주소 공간에서 좀 더 큰 자바 heap 사이즈
  
  
• 자바 어플리케이션의 원격 디스플레이

최종적으로 오픈솔라리스 커뮤니티는 리눅스와 다른 오픈소스OS 대안들의 장점들을 모두 희석시켜 버렸습니다. 오픈 소스 운영체제로써 이제 솔라리스는 포함되고 퍼포먼스, 사용성, 호환성, 서비스 비용과 모든 소유 비용의 측면에서 경쟁해야 합니다.

이글을 위해 정보를 제공해준 Brian Doherty, Angelo Rajadurai, Scott Oaks, Marty Itzkowitz, 그리고 Alexander Kolbasov 에게 감사의 인사를 전합니다.

• Download Page 솔라리스 개발 툴
• Observability Using Java Platform, Standard Edition 6, and Solaris OS ? 글
• Profiling Java Applications with Sun Studio Performance Tools ?글
• Solaris Developer Center
• Solaris Training Course Catalog
• Solaris Support and Services
• DTrace Quick Reference Guide
• DTrace by Example: Solving a Real-World Problem ? 글
• Sun Studio Performance Analyzer ? 소개
• Alexander Kolbasov’s weblog
• HotSpot JVM ? 소개
• Java EE Download Page
• Java EE Learning Path ? Training Course Catalog
• Sun Developer Expert Assistance