솔라리스에서 dtrace로 자바 메모리 활동 추적하기

Sun의 Jim Fiori가 제시한 방식입니다.

#!/usr/sbin/dtrace -qs

/*

* Show object allocation, aggregating the Java stack, methods,

* and object sizes

*

*/



hotspot$1:::object-alloc

{

       this->class = copyinstr(arg1,arg2);

       this->sz = arg3;

       @[jstack(40, 8000)] = count();

       @objs[this->class] = count();

       @sizes["Sizes"] = quantize(this->sz);

}

END

{



       trunc(@,20);

       trunc(@objs,10);

       printf ("\n****************Top Java stacks for memory
allocations*************\n");

       printa(@);

       printf ("\n****************Top Objects for memory
allocations*************\n");

       printa(@objs);

       printf ("\n****************Object sizes*************\n");

       printa(@sizes);



}

Pass in the JVM pid. You will have to use this startup flag for the JVM:



# java -XX:+ExtendedDTraceProbes



If you can't use Java 6, I've got something similar that uses the DTrace
VM agents.



To add looking at "heap" allocations via libumem, just add some PID
provider probes like:



pid$1::malloc:entry

{

   @mall_stack[jstack(40, 8000)] = count();

   @mall_sz = quantize(arg0);

}

<솔라리스, 디트레이스,자바, Solaris, dtrace, java>

Solaris에서 유요한 dtrace script : 읽으려고 시도했다가 에러 리턴된 것만 트레이스 하기

명령어 라인에서 한 줄로 실행하기 위해서는 다음과 같이 했습니다.(오픈솔라리스)
$pfexec dtrace -q -n 'syscall::open*:entry/execname != "gnome-netstatus-" && execname != "VBoxSVC"/{self->trace=timestamp;d=copyinstr(arg0);}' \
                        -n 'syscall::open*:return/self->trace&&arg1<0/{printf("%s:%d:%s(%d)\n",d,pid,execname,arg1);self->trace=0;}'  | tee /var/tmp/open2.log

gnome-netstatus- 와 VBoxSVC라는 프로세스에서 시도하는 open() call은 회피합니다. 너무 많아서.

script로 바꾸면 다음과 같이 작성합니다.

#/usr/sbin/dtrace

syscall::open*:entry
/execname != "gnome-nstatus-" && execname != "VBoxSVC"/
{
            self->trace=timestamp;
            d=copyinstr(arg0);
}

syscall::open*:return
/self->trace && arg1<0/
{
            printf("%s:%d:%s(%d)\n",d,pid,execname,arg1);
            self->trace=0;
}

eopen.d
라고 이름을 지었다면

dtrace -s eopen.d
라고 실행합니다.

결과는 다음과 같습니다.
....
/var/pkg/pkg/SUNWavahi-bridge-dsd/0.5.11%2C5.11-0.101%3A20081119T214544Z/filters:3752:pkg(-1)
/var/pkg/pkg/SUNWlang-common/0.5.11%2C5.11-0.101%3A20081119T233506Z/filters:3752:pkg(-1)
/var/pkg/pkg/SUNWperl584man/5.8.4%2C5.11-0.101%3A20081119T215746Z/filters:3752:pkg(-1)
/var/pkg/pkg/SUNWadmap/0.5.11%2C5.11-0.101%3A20081119T214241Z/filters:3752:pkg(-1)
/var/pkg/pkg/SUNWgnome-l10nmessages-zhCN/0.5.11%2C5.11-0.101%3A20081119T233244Z/filters:3752:pkg(-1)
/var/pkg/pkg/SUNWnfsc/0.5.11%2C5.11-0.101%3A20081119T215559Z/filters:3752:pkg(-1)
/var/pkg/pkg/SUNWos86r/0.5.11%2C5.11-0.101%3A20081119T235320Z/filters:3752:pkg(-1)
....

Solaris 8 서비스 단종 절차 단계 2 종료

솔라리스 8의 운영체제 지원의 마지막 단계에 이름에 따라 이제 솔라리스 8 서포트는 공식적으로 완전 종료되었다고 할 수 있겠습니다.

업무상 어쩔 수 없이 솔라리스 8을 계속해서 사용해야 한다면 특수 지원 서비스 계약( vintage support)를 하셔야 할 듯 하겠습니다. <br /> <br />* Phase 2 EOSL for Solaris 8 OS Has Arrived <br /><a class="moz-txt-link-freetext" href="http://communications1.sun.com/r/c/r?2.1.3J1.2TZ.11wryA.CHpe8E..T.GBWS.2KpE.bW89MQ%5f%5fCdZAFPD0">http://communications1.sun.com/r/c/r?2.1.3J1.2TZ.11wryA.CHpe8E..T.GBWS.2KpE.bW89MQ%5f%5fCdZAFPD0</a> <br />Sign up for Solaris 8 Vintage Patch support if you would <br />like to continue running your applications on Solaris 8. 

솔라리스는 매우 오래전부터 구버젼의 이진 화일을 신버젼에서도 그냥 복사해서 실행시킬 수 있도록 가장 진보된 '애플리케이션 이진 호환성'을 유지하고 있습니다. 쉽게 얘기하면 그냥 업그레이드 하면 된다는 뜻이죠. 굳이 단종된 구버젼의 서비스를 비싸게 구매할 필요가 없단 뜻이기도 합니다.

다만 애플리케이션의 성능 최적화를 위해서는 상업용 애플리케이션의 업그레이드가 필요할 수 는 있겠습니다. 혹은 상업용 애플리케이션의 추가 지원을 위해서도 상업용 애플리케이션의 동반 업그레이드가 요구되어질 수도 있습니다.  상업용 애플리케이션이 문제가 된다면 이때 과감하게 상업용 수준의 '오픈 소스'로 이전하시길 권고합니다.

웹은 아파치, 애플리케이션 서버는 'glassfish'. 그 어떤 상업용 애플리케이션 서버보다 훌륭합니다. 만약 DB를 바꾸기 쉽지 않으시다면, 솔라리스 10의 S8C, S9C를 이용해서 이전 환경을 그대로 가져다가 수행하는 것도 좋을 듯 합니다.

가상화와 윈도우즈 게스트의 네트웍 성능

1.Type 2 하이퍼바이저의 게스트 운영체제를 위한 네트웍 구성
오픈솔라리스 (opensolaris)에서 버추얼 박스를 통한 Type 2 가상화 시스템을 운영하고 있습니다. 3개의 윈도우즈 XP Pro guest 와 1개의 Opensolaris guest, 1개의 Ubuntu guest를 구성해놓은 상태에서 3개의 windows XP는 상시 운영하고 있습니다.

Type 1의 가상화인 xvm이나 vmware와는 달리 Type 2의 경우에는 가상화된 영역내의 네트웍 카드를 가상화 시스템인 Type 2 하이퍼바이저로부터 부여 받게 됩니다. 저의 경우에는 '버투얼박스'에 의해서 네트웍 카드를 가상화 게스트에 할당하게 됩니다.

이때 구성할 수 있는 네트웍 카드는 AMD PCNET Family PCI Ethernet Card가 기본으로 잡히고 Intel EtherPro Desktop 100Mb 네트웍 카드도 잡을 수 있습니다. 사실 하이퍼 바이저의 입장에서는 다른 네트웍 디바이스를 프리젠트하면서, 게스트 운영체제의 디바이스 드라이버로부 서로 다르게 받아지는 명령어들을 에뮬레이션 하는 부분에서의 성능 차이가 매우 클 것입니다만 이 이야기는 여기서 언급할 내용은 아닙니다. 기회가 되면 이부분을 언급해 보겠습니다.

하이퍼바이저에서 사용할 네트웍 카드를 선정하게 되면, 게스트에게 가상 네트웍 카드를 사용하는 방식을 결정해야 하는데, 이 방식에 따라서 게스트 운영체제가 IP 주소를 설정하는 방식이 변경되게 됩니다.

가장 기본적인 방식인 NAT 방식을 설정하면 게스트 운영체제는 하이퍼바이저가 제공하는 사설 IP 주소를 DHCP 방식으로 부여받게 되고, 하이퍼 바이저는 내장된 NAT 기능을 통해 자체적으로 default gateway 역할을 함과 동시에 외부 운영체제(하이버바이저가 실행되고 있는 운영체제)로 게스트의 패킷들을 포워딩하게 됩니다. 이후 시스템 운영체제가 패킷을 적당히 포워딩하게 됩니다.

NAT 방식과는 달리 게스트 운영체제에 '호스트 인터페이스(Host Interface)' 방식을 설정할 수 도 있습니다. 이 방식을 선택하게 되면, 게스트 설정시 사용할 실제 네트웍카드로 선택을 해야 하는데, 게스트에 나타나는 가상화된 네트웍 카드를 마치 서버의 실제 네트웍 카드인것처럼 동작하도록 합니다. 즉, 게스트 운영체제는 실제로 실제 연결된 네트웍 카드를 통해 외부 네트웍에 직접 연결되어 있는 형태를 가지게 됩니다. 이때의 경우에는 게스트 운영체제가 해당 네트웍카드에서 DHCP 클라이언트를 운영하여 IP를 받을 수 있음은 물론, 정적 IP를 임의로 설정할 수도 있게 됩니다.

브로드컴 네트웍 카드(bge0)카드에 192.168.x.x 정적 주소를 가진 서버가 한대 있다고 합시다. 이 서버에 버추얼 박스를 설치 실행해서 설정된 게스트 중 NAT 방식은 게스트가 10.x.x.x 대의 IP를 받게되고 하이퍼바이저의 패킷 포워딩에 따라서 패킷이 움직이는 반면, 'Host Interface' 방식은 서버의 bge0 에 설정된 192.168.x.x와 같은 네트웍 단의 주소를 정적으로 설정하거나 DHCP로 받을 수 있게 됩니다.

이 두방식은 용도와 목적에 따라서 장단점이 있습니다. 일반 기업에서 서비스를 올리기 위해서는 '호스트 인터페이스'가 나은 면이 있고, 개발자들의 용도라면 NAT가 편리합니다. 기업내 네트웍을 담당하는 부서에 요청할 필요가 없기 때문이죠.

그런데, NAT 를 사용하게 되면 이미 언급된 대로 하이퍼 바이저를 통해서 패킷에 헤드 비트들이 추가적으로 붙게 되므로 직접 붙는 경우와 달리 패킷당 크기가 변하게 됩니다. 윈도우즈 게스트들은 기본적으로 단위 전송 크기(MTU)를 1500으로 고정을 하게 된 상태로 운영하는데 이렇게 되면 게스트에서는 단일 패킷이지만, 버추얼박스에서 추가된 비트들로 인해 두 패킷으로 분리되어 두개로 나가게 되는 경우가 생기게 됩니다. 이렇게 되면 버추얼 박스가 한번 보내면 될 것을 두번 보내야 하므로 CPU를 더 쓰게 되고, 게스트 입장에서 볼때는 성능이 더 떨어지게 됩니다. 하이퍼 바이저가 두번처리하는 것을 기다려야 하기 때문이죠.

따라서, 이와 같이 Type 2 기반의 가상화를 하는 경우에는 게스트 운영체제에 Ethernet MTU 크기를 변경함으로써 하이퍼바이저가 두번할일을 최소화 시킴으로써 시스템이 느려지는 것을 최대한 막아볼 수 있습니다.(역으로 얘기하자면, 기본 구성 대비 성능이 좋아지는 셈이죠)

2. MTU 변경을 통한 성능 개선
2.1 윈도우즈 게스트 튜닝
일단, 현재 구성된 상황에서 MTU가 문제가 없는 지 확인을 하기 위해서는 Windows Guest 내에서 도스 명령어 창을 실행합니다. "시작 -> 실행 -> cmd 입력"
여기에서 외부 인터넷의 한 사이트의 IP 주소를 설정하고 어떤 패킷의 크기가 적합한 지를 검사해봅니다.
여기에서는 www.google.com 의 한 IP 주소를 사용했습니다. 참고로, 제가 테스트하는 네트웍은 미국의 화이어월을 통해서 패킷이 나가는 경우이므로 나라와 상황에 따라 다를 수 있으므로 적절한 사이트의 주소를 선택하실 필요가 있습니다.

만약 www.google.com이 아닌 www.naver.com의 IP 주소 를 획득하고 싶다면, 도스 창에서 다음과 같이 실행하면 여러개의 IP를 얻을 수 있습니다.

>nslookup www.naver.com

테스트용 주소를 결정했으면 (여기서는 64.233.189.104) 다음과 같이 실행해서 MTU 길이에 따른 문제가 있는 지를 확인해봅니다.

>ping 64.233.189.104 -f -l 1500
C:\>ping 64.233.189.104 -f -l 1500
Pinging 64.233.189.104 with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 64.233.189.104:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

위와 같은 메세지가 나오면 위 명령어에서 1500부터 10씩 빼가면서 테스트를 해봅니다.
C:\>ping 64.233.189.104 -f -l 1480
Pinging 64.233.189.104 with 1480 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 64.233.189.104: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\>ping 64.233.189.104 -f -l 1470
Pinging 64.233.189.104 with 1470 bytes of data:
Reply from 64.233.189.104: bytes=56 (sent 1470) time=113ms TTL=127
Reply from 64.233.189.104: bytes=56 (sent 1470) time=109ms TTL=127
Reply from 64.233.189.104: bytes=56 (sent 1470) time=105ms TTL=127
Reply from 64.233.189.104: bytes=56 (sent 1470) time=111ms TTL=127
Ping statistics for 64.233.189.104: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),


1470 bytes에서 "Packet needs to be fragmented but DF set" 없이 작동되고 있음을 알 수 있습니다. 단단위의 튜닝을 좀 더 해볼 수도 있습니다.
그렇게 해서 최적의 MTU가 나왔다면 (예를 들어, 1472) 이제는 레지스트리에 저장을 해야 합니다. 레지스트리를 수정하는 자제하는 방법은 여기를 참고하십시요. 쉽게 얘기하면
"시작버튼->실행->regedit" 을 실행합니다. 좌측 트리에서 다음과 같이 순서를 찾습니다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\
네트웍 인터페이스가 너무 많아서 어떤 것인지 모르겠으면 죄다 설정하십시요.
좌측 트리에서 각 ID 위에 마우스를 두고 우측 버튼을 누르면 'New..'가 나타납니다. 여기서 DWORD 값을 추가하면 우측 화면에 키 이름을 넣으라고 나옵니다. 여기에서 MTU 라고 입력하시고, MTU에서 마우스 우측 버튼을 누르면 'Modify Key' 가 나옵니다. 선택하시고 값을 입력하시는 데 우측 아래에서 십진수(Decimal)을 선택하신후 1472를 입력합니다.

같은 방법으로 모든 네트웍 카드에 대해서 설정하시고, regedit을 종료한 후에, 게스트 운영 체제를 재부팅합니다.

진화하는 mysql

몇일전에 발표된 것 같군요. (Apr 21st PDT)
http://dev.mysql.com/doc/mysql-5.4-features/en/index.html

MySQL 5.4의 새로운 버젼이 발표되었는데, 주목할 만한 것이 있네요.

기존의 큰 문제점 중 하나였던 innodb의 확장성이 X86에서 16-way(16cores) 수준으로 늘어났습니다.
그런데, CMT에서는 64-way까지라네요. 왜 다른지 좀 이해가 안가긴 합니다만(아마도 CMT는
스레드  개념을 써서 그런게 아닌가 싶네요. 코어야 어차피 8개니... 8way라서 그런가 ? )
어쨌든 CMT에서는 더 많은 (무려 4배) core까지 확장을 하고 있습니다.

그리고 성능(Response time)도 smpfix를 통해서, insert의 경우 응답시간이 1/4배로 빨라지고,
처리량(Throuput)은 대개 3배정도가 빨라지는 놀라운 결과를 보여주고 있습니다.
http://code.google.com/p/google-mysql-tools/wiki/SmpPerformance


더욱이 이번 mysql 5.4는  솔라리스의 독보적인 추적툴인 Dtrace를 지원하게 되었습니다.
Dtrace는 mysql의 전체적인 데이타 흐름을 보여주는 기능을 지원함에 따라, 이전에는 상상할 수 없는 수준의
데이타베이스 엔진 작동 추적이 가능해졌습니다. Amazing !!!
아래와 같은 데이타 베이스 작동 메커니즘을 보여줄뿐 아니라, 매 작동 단위당 응답시간을 체크할 수 있는 놀라운 기능이 가능해졌습니다.

오픈 솔라리스 랩탑 판매 개시!!

도시바가 오픈 솔라리스가 기본 장착된 노트북 판매를 개시했네요.
opensolaris.com에서 온라인상으로 가능하고, 일단 현재는 미국만 가능한 것으로 되어 있습니다.

솔라리스가 기본 장착된 랩탑이라, 흥분되는 군요.

자세한 내용은 아래 링크로 고고..

On The Record

솔라리스에서 화일 시스템 캐쉬 최적화를 위한 전략

The Zone Manager: Filesystem Cache Optimization Strategies

솔라리스에서  제공되는  대표적인  화일 시스템인 ufs와 zfs가 사용하는 캐쉬를 이해하고 최적화해서 사용할 수 있는 전략 수립을 도와줍니다.

ufs의 경우는 데이타가 충분히 메모리에 올라가있도록 캐쉬 크기를 조절하고 메모리에 유지되도록 해주는 설정방법을 제공하며, zfs의 경우는 ARC(cache)의 크기를 조정하는 파라메터 설정을 제공합니다.

한번 참고 삼아 훑어볼 만합니다.

JAVA 미들웨어를 위한 솔라리스 ( Solaris ) 10 튜닝

솔라리스에서 각종 자바 미들웨어를 위한 튜닝 방법입니다.
관련 글은 웹스피어에 관해서만 언급이 되어 있으나, Weblogic, Glassfish등에도
그대로 적용된다고 할 수 있겠습니다.

Solaris Network Tuning for WebSphere Application Environment - Albert Leigh's Weblog

위 사이트를 가보시면 몇몇 주요 튜닝이 있습니다.
CONNECTION REQEUSTS를 위한 튜닝과 TCP 버퍼를 위한 변수들
그리고 접속을 위한 변수들의 튜닝이 있습니다.

특별히 다중 코어를 가진 장비에서는 솔라리스의 ip 스트림큐를 늘려주어야 하는데
지금 4core 이상의 장비들을 기준으로 보면 당연히 늘리는 것이 좋을 듯 합니다.

    set ip:ip_soft_rings_cnt = 8<br />    set ddi_msix_alloc_limit = 8<br />

대개 코어의 개수와 동일하게 설정해주고 테스트를 해보는 것이 좋을 것 같습니다.
여러 단계의 테스트가 가능하다면 설정없이 테스트하고, 설정한 후에 테스트를 해보면
어떤 영향이 있는 지 좀더 알 수가 있습니다. 하드웨어의 사양이 끊임없이 변하므로
관련 변수도 끊임없이 수정 테스트가 필요합니다.

오픈 솔라리스에서 인증서와 .p12 화일을 만드는 법

인증서를 만들기 위해서는 일단 다음처럼 실행합니다.
새로운 x509 인증서 발급을 하되 키는 nethippo-CA.key.pem에 담고, 인증서는 nethippo-CA.cert.pem에 담도록 합니다. 유효기간은 10년으로 정합니다.
$openssl req -new -x509 -keyout nethippo-CA.key.pem -out nethippo-CA.cert.pem -days 3650

발급된 인증서를 바탕으로 외부 유출이 가능한 .p12 화일을 생성합니다.
$openssl pkcs12 -export -in nethippo-CA.cert.pem -inkey nethippo-CA.key.pem -out nethippo.p12 -name "Kildong Hong"

이제 썬더버드와 같은 곳에서 위에서 생성한 .p12  화일을 import하여 장착한 후 메일을 사이닝 혹은 암호화할 수 있게 됩니다.

나의 X2200에 무슨 일이?

최근 x2200 장비에 로그인을 했더니, 매우 느리다는 느낌이 왔습니다.
이유를 확인해야 한다고 생각했는데, 바빠서 잊고 있었습니다.

그래서 오늘 짬을 내서 보기로 했습니다.

우선은 ssh로 로그인하는 데 느려진 것 같아서
일단 /etc/nsswitch.conf와 /etc/resolv.conf를 확인해보았습니다.
별 문제가 없는 데 왜 느려졌지 하는 생각이 드는 군요.

일단 vmstat로 시작을 해보았습니다.

 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr s0 s1 s2 --   in   sy   cs us sy id
 0 0 0 2287196 2068940 26 2 152 3  3  0  0 15 -1 -0  0 1245 1719  632  0 24 75
 1 0 0 3477208 2840460 1 46  0  0  0  0  0  0  0  0  0  421  458  278  0 25 75
 1 0 0 3477104 2840356 0  4  0  0  0  0  0  0  0  0  0  446  806  353  0 26 74
 1 0 0 3477104 2840356 0  0  0  0  0  0  0  0  0  0  0  406  435  254  0 25 75
 1 0 0 3477104 2840356 0  0  0  0  0  0  0  0  0  0  0  416  437  276  0 25 75
 1 0 0 3477104 2840356 0  0  0  0  0  0  0  0  0  0  0  408  477  260  0 25 75
 1 0 0 3477104 2840356 0  0  0  0  0  0  0  0  0  0  0  410  436  265  0 25 75
 1 0 0 3477104 2840356 0  0  0  0  0  0  0  0  0  0  0  443  747  340  0 26 74
 1 0 0 3477104 2840356 0  0  0  0  0  0  0  0  0  0  0  418  487  265  0 25 75
 1 0 0 3477104 2840356 0  0  0  0  0  0  0  0  0  0  0  409  439  265  0 25 75
 1 0 0 3477104 2840356 0  0  0  0  0  0  0  0  0  0  0  415  436  257  0 25 75

아무것도 안하고 있는 이 장비가 뭔가 열쒸미 하고 있네요.. 왜 평균 CPU가 75%일까 ?
sys%가 25%인 것으로 봐서, 4개의 코어이니, 한 코어가 system 관련해서 cpu를 다쓰나 ?
mpstat를 보기로 했습니다.
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0    0   0    3   340  131  168    0    1    0    0    71    0   0   0 100
  1    2   0    0    49    3   80    0    1    1    0   327    1   0   0  99
  2    0   0    0    16    0   28    0    1    0    0    67    0   0   0 100
  3    0   0    0    15   13    0    0    0    1    0     0    0 100   0   0
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0    0   0    0   355  140  181    0    6    0    0    93    0   0   0 100
  1    0   0    0    51    2  124    1    4    2    0   611    0   5   0  95
  2    0   0    0    26    4   43    0    1    0    0    97    1   0   0  99
  3    0   0    0     9    8    0    0    0    1    0     0    0 100   0   0
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0    0   0    0   340  132  170    0    2    0    0    75    0   1   0  99
  1    0   0    0    47    3   77    0    2    2    0   367    0   0   0 100
  2    0   0    0    17    0   32    0    4    0    0    68    0   0   0 100
  3    0   0    0    11   10    0    0    0    2    0     0    0 100   0   0
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0    0   0    0   345  134  169    0    4    0    0    78    0   0   0 100
  1    0   0    0    47    3   78    0    3    1    0   313    0   0   0 100
  2    0   0    0    16    0   30    0    2    0    0    69    0   0   0 100
  3    0   0    0     9    8    0    0    0    2    0     0    0 100   0   0

음.. 예상대로 cpu (3번) 하나가 syscall 때문에 죽어나고 있네요.
뭐 때문에 저럴까요 ?

dtrace를 해보기로 했습니다.
일단, 도대체 커널의 어떤 부분이 cpu 3번을 다 쓰고 있을까 궁금합니다.

$pfexec dtrace -n 'fbt:::entry{@[probemod]=count();}'
dtrace: description 'fbt:::entry' matched 33143 probes
^C

  devfs                                                             1
  FX                                                                8
  cpu_ms.AuthenticAMD.15                                            8
  elfexec                                                           8
  lofs                                                             11
  mntfs                                                            16
  kcf                                                              20
  fifofs                                                           24
  pset                                                             24
  swrand                                                           28
  cpu.generic                                                      48
  ptm                                                             112
  pts                                                             141
  namefs                                                          147
  ttcompat                                                        236
  ptem                                                            276
  dld                                                             400
  mac_ether                                                       491
  arp                                                             494
  mac                                                             520
  scsi                                                            559
  ldterm                                                          755
  rootnex                                                         783
  ata                                                             997
  doorfs                                                         1024
  tmpfs                                                          1030
  sata                                                           1199
  sha1                                                           1284
  ohci                                                           1437
  nfs                                                            1508
  dls                                                            1544
  nv_sata                                                        2061
  sd                                                             2098
  TS                                                             2639
  nge                                                            2779
  procfs                                                         2893
  tl                                                             3066
  specfs                                                         6696
  ip                                                             7521
  ehci                                                           8709
  sockfs                                                         9242
  bge                                                            9686
  ufs                                                           38891
  pcplusmp                                                      45652
  genunix                                                     1267865
  unix                                                       28401472

sys는 전부 커널 영역이라 fbt Provider를 지켜봤는데, unix가 많이 사용되고 있군요.
어떤 unix의 어떤 모듈이 많이 사용되는 지 궁금해지는 군요.
 $pfexec dtrace -n 'fbt:unix::entry/cpu==3/{@[probefunc]=count();}'
dtrace: description 'fbt:unix::entry' matched 1538 probes
^C

  cmt_balance                                                       1
  cpu_choose                                                        1
  cpu_resched                                                       1
  cpu_wakeup                                                        1
  disp_lowpri_cpu                                                   1
  hati_sync_pte_to_page                                             1
  page_get_pagecnt                                                  1
  poke_cpu                                                          1
  setbackdq                                                         1
  tsc_gethrtimeunscaled                                             1
  tsc_gethrtimeunscaled_delta                                       1
  tsc_scalehrtime                                                   1
  x86pte_access_pagetable                                           1
  x86pte_get                                                        1
  x86pte_release_pagetable                                          1
  av_dispatch_softvect                                              2
  av_set_softint_pending                                            2
  cbe_low_level                                                     2
  cbe_softint                                                       2
  cms_hdl_getcms                                                    2
  cms_hdl_getcmsdata                                                2
  cms_poll_ownermask                                                2
  dosoftint_epilog                                                  2
  dosoftint_prolog                                                  2
  gethrestime_sec                                                   2
  pc_gethrestime                                                    2
  put                                                               2
  gethrestime_lasttick                                              3
  hr_clock_lock                                                     3
  hr_clock_unlock                                                   3
  x86pte_inval_func                                                 3
  ip_ocsum                                                          4
  lock_set_spl                                                      4
  av_check_softint_pending                                          6
  call_func_ntv                                                    12
  checked_rdmsr                                                    12
  cmi_hdl_rdmsr                                                    12
  msri_lookup                                                      12
  ntv_rdmsr                                                        12
  ntv_rdmsr_xc                                                     12
  mutex_vector_enter                                               15
  cbe_fire                                                         18
  cbe_reprogram                                                    18
  default_lock_delay                                               22
  tsc_gethrtime_delta                                              38
  putnext                                                          46
  xc_serv                                                          51
  hilevel_intr_prolog                                              69
  hilevel_intr_epilog                                              70
  page_release                                                    105
  intr_thread_epilog                                              148
  intr_thread_prolog                                              148
  bcmp                                                            168
  av_dispatch_autovect                                            217
  hat_page_getshare                                               374
  hment_mapcnt                                                    374
  hat_page_clrattr                                                704
  page_io_trylock                                                 704
  page_io_unlock                                                  704
  page_lookup_nowait                                              704
  hat_page_setattr                                                705
  hat_pagesync                                                    907
  page_next_scan_large                                            914
  x86_hm_enter                                                   1184
  x86_hm_exit                                                    1184
  page_add                                                    3056448
  page_sub                                                    3059851
  page_unlock                                                 3060007
  page_trylock                                                4852320

page_trylock ? 뭔가가 lock을 하려고 하는데 안되나 보군요.
page_trylock을 유도하는 process가 뭔지 궁금해졌습니다.
$pfexec dtrace -n 'fbt:unix:page_trylock:entry/cpu==3/{@p[execname]=count();}'
dtrace: description 'fbt:unix:page_trylock:entry' matched 1 probe
^C

  fsflush                                                     8032633

아..... 하.. 그렇군요. fsflush가 계속해서 page lock을 시도했군요.
그러고나니, 아주 오래전에 제가 화일 시스템 옵션을 변경했던 적이 생각이 납니다.
ufs의 옵션을 변경했었고 nfs로 외부 화일 시스템을 하나 마운트했던 게 생각이 나는 군요..
그게 이런 결과를 초래한 줄은 생각도 못했군요. ㅡㅡ;

어느 쪽의 문제인지 확인이 필요하겠네요.

/etc/vfstab을 확인해봤습니다.
/var/run on swap read/write/setuid/devices/xattr/dev=4800003 on 목  2월 12 14:41:03 2009
/export/home on /dev/dsk/c1t0d0s7 read/write/setuid/devices/intr/largefiles/xattr/noatime/onerror=panic/dev=780007 on 목  2월 12 18:32:57 2009
/net/129.158.2.181/export/web on 129.158.2.181:/export/web remote/read/write/nosetuid/nodevices/xattr/dev=4a80002 on 목  2월 12 17:07:37 2009

nfs를 우선적으로 umount 해보려고 했더니 안되는 군요. ㅡㅡ; 그제서야 생각났습니다.
nfs 대상 서버가 임시로 올렸다가 죽인 서버였다는 것을... 
그렇다고... 이렇게 cpu를 많이 사용하는게 이해는 안되는 군요..
버그가 아닌가 생각이 드는군요. 패치를 찾아봐야 겠습니다.

클라우드 컴퓨팅이 과연 비즈니스일까요?

이런 질문을 수도 없이 들었습니다.
클라우드 컴퓨팅은 기존의 IT Infrastructure의 근간을 바꿀 큰 흐름이자, 새로운 형태의 경쟁이자 비즈니스 모델로 성장하고 있습니다.

그냥 방관해서는 안될 이유는 변화하는 비즈니스가 나의 비즈니스에 어떤 영향을 주는 가 하는 점에 대해서 반드시 한번 생각해볼 필요가 있습니다.

SalesForce.com이나 아마존은 이런 질문의 좋은 대답이 될 듯 합니다. 
참고로,아래 링크는 아마존의 수익이최근에 어떻게  증가하고 있는 지를 잘 보여주고 있습니다.
단순히, DVD나 책팔아서 늘고 있는 수입이 아니라는 점을 인지할 필요가 있을 듯 합니다.
http://blogs.zdnet.com/BTL/?p=9422

이러한 클라우드 컴퓨팅 환경을 구축하기 위해서는 이런 동적 데이타센터의 기저에 어떤 운영체제를 두느냐에 따라 향후의 그림이 달라진다는 점입니다. 명확한 것은 윈도우즈는 아니라는 점입니다.
현재 x86의 관점에서는 vmware가 상당한 선점효과를 가지고 있는 듯 합니다만, 현재 클라우드 컴퓨팅의 핵심은 모두 오픈소스로 구성되어 있다는 점에서 장기적으로는 xen 기반의 가상화 기술이 대세를 이룰 것으로 예상합니다.

 자체적으로 클라우드 환경을 구축하는 곳에서는 vmware의 가치가 여전히 존재합니다만, 클라우드 서비스를 이용하여 매출을 창출하려 하는 클라우드 컴퓨팅 서비스에서는 가장 저렴한 비용이 핵심이므로 xen 기반의 클라우드 컴퓨팅이 대세가 될 것입니다.

아울러, Platform as a Service 관점에서 본다면 여전히 Vertical Scaling의 필요성도 병립하게 됩니다. 따라서, 기존의 Legacy big server들도 아키텍쳐에서 한자리를 차지하게 될 예정입니다.
이런 예측하에서 작은 서버들 - horizontal scaling layer 와 Vertical Scaling 모든 레이어에서 탁월한 객체 가상화와 동적 운영 능력을 가진 운영체제는 '솔라리스'가 유일하다고 할 수 있겠습니다.

x86에서는 xen 기반으로 Big Sparc에서는 LDom/DDom 등 이미 한세대 앞선 기술을 제공하고 있기 때문입니다.

추가로 하나 더 지정한다면, 클라우드 컴퓨팅을 구축하면서 가장 중요한 부분은 역시 보안임을 결코 잊을 수 없습니다. 보안을 생각한다면, 다시금 솔라리스를 생각하지 않을 수 없군요. 여러 면에서 보면 솔라리스의 우수함을 인정하지 않을 수가 없는데, 솔라리스가 얼마나 사람들로 하여금 사랑을 받을 지 궁금하군요.

gnome 사용자 환경 초기화 하기

솔라리스를 여러 버젼을 오랜 동안 업그레이드해오면서도 사용자 디렉토리(홈)은 계속 유지해서 사용해오다 보니,
홈디렉토리에는 상당히 많은 '가비지'들이 누적되게 됩니다.
그 중에서도 구성과 관련된 설정 화일들이 남아서 새버젼에서 홈을 마운트할 때 호환성 문제를 야기시키더군요.
대표적인 것이 gnome 구성 화일인데, 이 구성 화일을 쉽게 초기화 하는 방법이 있습니다.

썬 솔라리스에서는 로그 아웃을 하시고 Failsafe Mode로 로그인하신 후
$gnome-cleanup exit
를 실행하고 재 로그인하면 된다고 되어 있군요.

opensolaris의 경우에는 svcadm disable -t gdm 을 실행해서 로그인 매니저를 죽인후 터미널 로그인 환경으로 재 로그인해서 위의 명령어를 실행하고 다시 svcadm enable -t gdm을 실행하면 될 듯 합니다.

---- 아래 Solaris 10 08/10(U6) Release Note 원문입니다. ----

User Preferences Not Fully Compatible

User preferences in your home account for an earlier version of the
GNOME Desktop might be partly incompatible with the version on the Java DS
Release 3.

Workaround: Reset your preferences.
Perform the following steps:

1. 
   

   Log out of the Java Desktop System.

   
   
   
   
2. 
   

   Click Session and choose Failsafe terminal.

   
   
   
   
3. 
   

   Log in.

   
   
   
   
4. 
   

   In the failsafe terminal window, enter the following commands:

   
   
   
   
   
   
   

   % <b><kbd>gnome-cleanup exit</kbd></b><br />

   
   
   
5. 
   

   Log in again.

   
   
   

   Your GNOME preferences are now reset.

   
   
   
   

Windows 7이 발표되었다는 군요... 솔라리스랑 한번 비교해봤습니다. 좀 웃기나 ^^;

Windows7 Home Premium (컨수머용)	OpenSolaris
Windows7 Professional(중소기업용)	SunSolaris
Windows7 Enterprise	SunSolaris
Windows7 Home Basic(신흥국가)	OpenSolaris
Windows7 Starter(일부 OEM)	OpenSolaris
Windows7 Ultimate	N/A

인텔 Core 2 Duo CPU 결함

vaio sz56ln을 구입한지 꼭 1년 넘었습니다.

vendor_id    : GenuineIntel
cpu family    : 6
model        : 15
stepping    : 11
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm nx lm lahf_lm
cpu MHz        : 2194.365
model name    : Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz

그런데, 갑자기 mpstat에서 cpu가 하나 안나오더군요.
참고로 오픈 솔라리스를 사용하고 있습니다.

$ mpstat 1
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0  297   0    3   461  256 1091  195   11   17    0 19433   15   9   0  76
  0   24   0    0   383  183  312    9    0    0    0 11447    5   4   0  91
  0    0   0    1   424  224  549   98    0    0    0 17563   12   5   0  83
  0    0   0    1   400  198  408   26    0    0    0 14405    7   4   0  89
  0    0   0    1   399  199  390   63    0    0    0  8293    7   5   0  88
 
cpu 컬럼에 0,1이 번갈아 찍혀야 하는데 어찌된 일인지 0번만 계속 찍히는 군요...
psrinfo 로 cpu 상태를 확인해보고 싶어졌습니다.

$ psrinfo -v
Status of virtual processor 0 as of: 02/03/2009 11:38:00
  on-line since 02/03/2009 11:18:59.
  The i386 processor operates at 2200 MHz,
    and has an i387 compatible floating point processor.
Status of virtual processor 1 as of: 02/03/2009 11:38:00
  faulted since 02/03/2009 11:19:43.
  The i386 processor operates at 2200 MHz,
    and has an i387 compatible floating point processor.


헉 ! cpu의 두번째 코어(1번코어)에 장애가 났다고 되어 있습니다.
아니 우예 이런 일이....
솔라리스에 들어있는 장애 관리 툴이 생각이 났습니다.
장애 발생시 자세한 정보를 기록해놓는 툴입니다.

$ fmdump
TIME                 UUID                                 SUNW-MSG-ID
Jan 10 15:12:12.7637 29741a56-c24d-4279-d1ca-a27f0b5244d0 ZFS-8000-D3
Feb 03 11:19:43.3373 178eb5f4-32b5-c164-950e-d89ecd92725a INTEL-8000-1J
Feb 03 11:19:43.5471 2c436e7a-a2ff-e2ca-f0d0-c64b2ed5dc39 INTEL-8000-1J

동일한 INTEL cpu 장애가 있었습니다. 구체적인 내용을 알고 싶었습니다.

$ fmdump -Ve -u 178eb5f4-32b5-c164-950e-d89ecd92725a
TIME                           CLASS
Feb 03 2009 11:15:41.729047265 ereport.cpu.intel.internal_timer
nvlist version: 0
    class = ereport.cpu.intel.internal_timer
    ena = 0x11b7022c15402001
    detector = (embedded nvlist)
    nvlist version: 0
        version = 0x0
        scheme = hc
        hc-list = (array of embedded nvlists)
        (start hc-list[0])
        nvlist version: 0
            hc-name = motherboard
            hc-id = 0
        (end hc-list[0])
        (start hc-list[1])
        nvlist version: 0
            hc-name = chip
            hc-id = 0
        (end hc-list[1])
        (start hc-list[2])
        nvlist version: 0
            hc-name = core
            hc-id = 1
        (end hc-list[2])
        (start hc-list[3])
        nvlist version: 0
            hc-name = strand
            hc-id = 0
        (end hc-list[3])

    (end detector)

    disp = processor_context_corrupt,return_ip_invalid,unconstrained
    IA32_MCG_STATUS = 0x4
    machine_check_in_progress = 1
    privileged = 0
    bank_number = 0x5
    bank_msr_offset = 0x414
    IA32_MCi_STATUS = 0xb200221010040400
    overflow = 0
    error_uncorrected = 1
    error_enabled = 1
    processor_context_corrupt = 1
    error_code = 0x400
    model_specific_error_code = 0x1004
    threshold_based_error_status = No tracking
    __ttl = 0x1
    __tod = 0x4987a8cd 0x2b7460e1

코어 내부 타이머 문제라고 하는 것 같군요. 어쨌든 수정할 수 없는 에러가 하나있다고 나오는 군요.
에러 코드 0x400, 모델 관련 에러 코드 0x1004랍니다
음... http://www.sun.com/msg 에 가서 메세지 id를 넣어봤습니다. http://www.sun.com/msg/INTEL-8000-1J


Major fault 급이군요.. 솔라리스가 오프라인을 시도할 거라고 되어 있군요. 성능이 줄거라고도
되어 있습니다.

해당 CPU를 교체하라고 되어 있네요.. ㅡ.ㅡ;

랩탑이 죽은 건 안타깝지만, 말로만 듣던 솔라리스의 '자가 예측 진단 기능과 장애 관리 기능'을  제눈으로
보고야 말았네요. 기능은 환상이기잠 자주 보고 싶은 기능은 아니군요.ㅡ.ㅡ;

서비스 센터를 가기로 결정했습니다. 문득, 장애난 cpu를 수리했다고 치고 바꿨을 경우 처럼 장애(faulty)로  처리되어 있는 코어를 수리된 것으로 변경하면 어떨까 생각이 들었습니다.

다음과 같이 실행을 해봤습니다.

#fmadm faulty
--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Feb 03 11:19:43 178eb5f4-32b5-c164-950e-d89ecd92725a  INTEL-8000-1J  Major   

Fault class : fault.cpu.intel.internal
Affects     : cpu:///cpuid=1
                  faulted but still in service
FRU         : hc://:product-id=VGN-SZ56LN_B:chassis-id=28205682-7001541:server-id=vaio-bhkim/motherboard=0/chip=0
                  faulty

Description : An internal error has been encountered on this cpu.  Refer to
              http://sun.com/msg/INTEL-8000-1J for more information.

Response    : The system will attempt to offline this cpu to remove it from
              service.

Impact      : Performance of this system may be affected.

Action      : Schedule a repair procedure to replace the affected CPU.  Use
              'fmadm faulty' to identify the module.

--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Jan 10 15:12:12 29741a56-c24d-4279-d1ca-a27f0b5244d0  ZFS-8000-D3    Major   

Fault class : fault.fs.zfs.device

Description : A ZFS device failed.  Refer to http://sun.com/msg/ZFS-8000-D3 for
              more information.

Response    : No automated response will occur.

Impact      : Fault tolerance of the pool may be compromised.

Action      : Run 'zpool status -x' and replace the bad device.

--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Feb 03 11:19:43 2c436e7a-a2ff-e2ca-f0d0-c64b2ed5dc39  INTEL-8000-1J  Major   

Fault class : fault.cpu.intel.internal
Affects     : cpu:///cpuid=0
                  faulted and taken out of service
FRU         : hc://:product-id=VGN-SZ56LN_B:chassis-id=28205682-7001541:server-id=vaio-bhkim/motherboard=0/chip=0
                  faulty

Description : An internal error has been encountered on this cpu.  Refer to
              http://sun.com/msg/INTEL-8000-1J for more information.

Response    : The system will attempt to offline this cpu to remove it from
              service.

Impact      : Performance of this system may be affected.

Action      : Schedule a repair procedure to replace the affected CPU.  Use
              'fmadm faulty' to identify the module.

'장애' 기록 자체를 없앨 수 있나 확인을 해봤습니다.

#fmadm reset hc://:product-id=VGN-SZ56LN_B:chassis-id=28205682-7001541:server-id=vaio-bhkim/motherboard=0/chip=0
fmadm: failed to reset module chip=0: specified module is not loaded in fault manager

안되는 군요. ㅡ.ㅡ;

#fmadm repaired hc://:product-id=VGN-SZ56LN_B:chassis-id=28205682-7001541:server-id=vaio-bhkim/motherboard=0/chip=0
fmadm: recorded repair to of hc://:product-id=VGN-SZ56LN_B:chassis-id=28205682-7001541:server-id=vaio-bhkim/motherboard=0/chip=0

'수리됨'으로 마킹을 시도해봤습니다. 그랬더니, 다음처럼 나오는 군요... ㅡ.ㅡ;

$ psrinfo -v
Status of virtual processor 0 as of: 02/03/2009 16:17:36
  on-line since 02/03/2009 16:17:32.
  The i386 processor operates at 2200 MHz,
    and has an i387 compatible floating point processor.
Status of virtual processor 1 as of: 02/03/2009 16:17:36
  on-line since 02/03/2009 16:14:03.
  The i386 processor operates at 2200 MHz,
    and has an i387 compatible floating point processor.

둘 다 온라인으로 나오는 군요.....  이런....

맘이 불안해집니다. 장애난 CPU를 다시 재마킹해서 사용하면
문제가 없을까...

#fmstat 1

로 실시간 상황을 상당히 지켜보고 있습니다만, 아직은 문제가 없군요.

음... 매우 고민되는 군요. 서비스 센터를 가야하나 말아야 하나...

인텔 네할렘에 가장 최적화된 운영체제... - 오픈 솔라리스

인텔에서 발표할 예정인 '네할렘' 기반의 프로세서는 흥미롭게도 3~4년 전에 AMD가 사용했던 아키텍쳐를 다시 들고 나타났습니다. 당시의 AMD의 아키텍쳐는 두개의 소켓 박스를 구성하면서 NUMA 구조를 채택했었는데, 증가하는 버스 대역폭의 압력에 시달리던 인텔이 마침내 AMD의 구조의 우수성에 인정을 한 셈이라고 할 수 있습니다.

재미있는 것은 당시 AMD가 이런 NUMA 구조의 x86 박스를 발표하면서 가장 적합한 운영체제로 솔라리스를 추천했고, 썬과 함께 공동 프로모션을 많이 했었습니다. 그 이유는 아주 오래전부터 NUMA에 적합하도록 최적화 개발을 유지한 운영체제인 솔라리스가 가장 잘 동작했기 때문이었습니다. 리눅스는 아직도 NUMA operation에 문제가 있는 것으로 얘기가 되는 듯 합니다.

그런데, 이 AMD 아키텍쳐를 가져온 네할렘(Nehalem) 역시 솔라리스의 NUMA 기능들의 덕을 톡톡히 볼 것으로 예상됩니다. 위 비디오에서 인텔의 엔지니어가 언급하듯이, 오픈 솔라리스의 Thread management, MPO, Power 최적화 프로젝트(Tesla)등... 솔라리스가 네할렘에 가장 적합한 운영체제임을 언급하고 있군요...

아주 멋진 일이 아닌가 싶습니다. 이런 장비를 들고, 윈도우즈만 쓰겠다고 버둥대는 일부 사용자들이 다소 안습이군요.

OpenSolaris & Intel: Nehalem

오픈 솔라리스 커널 디버거 MDB 팁

Tips and Tricks at OpenSolaris.org

opensolaris 11/08에서 mp3 음악듣기.

오픈 솔라리스는 gstreamer 기반의 미디어 플레이 프레임웍과 gnome 기반의 인터페이스를 기본적으로 제공하고 있습니다. 기본 멀티미디어 플레이어인 '토템'은 바로 이 gstreamer 프레임웍을 이용하고 있으므로, 될 듯 보입니다만, 작동되지 않습니다.

이렇게 얘기하면, 솔라리스 깔자 말자 mp3 복사해서 음악들으면 나와야 할 것 같습니다. 그런데, 불행하게도 그렇지는 않습니다. 이유는 기본적으로 mp3를 지원하는 코덱 라이브러리(이하, 코덱)이 들어있지 않고, 이 코덱을 호출하는 gstreamer의 mp3  코덱 플러그인이 기본번들되어 있지 않기 때문입니다. 이렇게 가장 중요해보이는 패키지가 없는 이유는 해당 코덱의 라이센스 때문입니다. 코덱에 따라 어떤 mp3 코덱은 번들하려면, OEM 제품이 라이센스 비용을 지불해야 하거나 상업용 버젼만을 제공해야 하기 때문입니다.

특히, mp3 디코더로 가장 유명한 lame 라이브러리는 소스 형태로만 배포가 되도록 규정되어 있으므로 여기에서는 GPL mp3 코덱인 mad 라이브러리를 이용해보도록 하겠습니다.
역시 같은 sourceforge.net에서 id3taglib로 받을 수 있습니다.

http://sourceforge.net/project/showfiles.php?group_id=12349

위의 두개의 화일을 다운받은 후에 압축을 풉니다.
각각의 디렉토리에 들어가서 ./configure --prefix=/usr CFLAGS="-O -ffast-math" 와 같이 실행한 후 gmake를 실행합니다. 컴파일이 잘 끝나면, pfexec gmake install을 실행해서 /usr 디렉토리에 설치하도록 해줍니다.

이 과정으로 id3tag와 mad가 설치가 되었다면, 이제 gstreamer의 플러그인 패키지를 다운 받습니다.


일단 mp3 를 연주하기 위해선 현재 상황을 파악하고 필요한 패키지들을 다운 받은 후에 설치를 해주어야 합니다.

일단 gstreamer를 컴파일하기 전에 현재 어떤 코덱이 지원되는 지 확인을 해봅니다.
gst-inspect 를 실행해보면, 지원되는 미디어 포맷과 확장자가 나타납니다.
만약 필수 플러그인들이 존재하지 않는다면, 아래 플러그인 사이트에서 *-base-*도 다운을 받아야 합니다. 여기서는 *-base-*가 있다고 가정하고 진행합니다.

이제 gstreamer의 mp3 플러그인을 다운 받도록 합니다.
다운은 http://gstreamer.freedesktop.org/src/gst-plugins-ugly/gst-plugins-ugly-0.10.10.tar.gz 합니다.
압축을 풀고 디렉토리로 들어가서 앞서 돌렸던 같은 옵션으로 ./configure를 돌립니다.
gmake 한 후 pfexec gmake install로 설치를 끝내도록 합니다.

이제 totem이나 리듬박스등을 다시 실행해보면, 연주가 되는 것을 알 수가 있을 겁니다.

고성능 스토리지(하이엔드 스토리지 or Highend Storage) 와 ZFS의 궁합 ?

일단, zfs는 최초 개발시 대규모 캐쉬 메모리를 가지고 있지 않다는 가정하에서 - 즉

JBOD 혹은 저렴한 내장 디스크들. - 디자인이 되었습니다.

반면, 시스템에 장착되는 메모리의 비용/용량은 급격히 떨어지는 것을 활용하는 것에

촛점을 둠에 따라,  zfs는 가급적이면 많은 메모리를 끌어다가 저 성능의 디스크를 위한

캐쉬 처럼 작동할 수 있는 메커니즘을 넣게 되었습니다. 이렇게 대용량 메모리를 캐쉬버퍼로

쓰게되면 당연히 시스템 장애시 플러시 되지 않은 데이타들이 화일 시스템에 dirty area를

만들 수 있게되므로(과거 화일 시스템들의 큰 문제였죠.) zfs는 '항상 data state가 보장되는'

기술을 채택하게 됩니다. flush 되지 않은 내용이 날라가더라도 file system이 깨지지는 않습니다.

일단 디스크에 쓰인 것은 언제나 보장이 됩니다.  따라서, 화일 시스템에서 데이타가 깨진 다는 둥

이런 얘기는 고객과 얘기할 때 zfs에서는 사용하지 않으시길 바랍니다.



이러한  커다란 캐쉬는 저렴한 디스크들과 함께 사용시 고성능을 제공해주는 근간이 되기도 합니다.

썬의 오픈 스토리지는 이러한 특징에 기반하여 고성능을 제공하고 있습니다.



반면 단점도 발생합니다.  다른 서비스를 위해서 상당한 메모리를 사용하는 애플리케이션들이 탑재되는

경우에는 메모리 점유에 대한 경쟁현상이 발생하므로 이런 경우에는 zfs가 사용하는 캐쉬 버퍼 영역을

제한해야 할 필요성이 대두되게 되었습니다.  쓰기를 많이 할 수록 이런 문제는 더욱 더 많이 발생하겠죠.

때문에 Sun Solaris 10에서는 함께 사용하게 될 애플리케이션의 종류를 염두에 둬서 사전에 이런 코치를

해주실 필요가 있습니다. 만약 데이타베이스 처럼 헤비한 '쓰기' 트랜잭션을 반드시 가지는

애플리케이션들인 경우에는 필히 arc-max를 적정 수준의 메모리로 제한하셔야 합니다.

잘 모르겠다 싶으면 최소, 중간, 대량 정도로 구분했을 때 최소는 메모리의 1/8, 중간은 1/4, 대량은 1/2

정도로 두시면 됩니다. arc 캐쉬로 설정된 값만 큼 모든 메모리가 사용되는 것이 아니므로 설정했다

하더라도 사용되지 않으면 다시 애플리케이션이 사용할 수 있도록 return되게 되어 있습니다.



연속적으로 이 문제는  zfs 의 캐쉬 버퍼가 끊임없이 늘어나게 됨에따라 캐쉬를

오퍼레이션 타임(서비스 타임)이 급증하는 현상도 함꼐 발생했는데, 이에 따라서 zfs는 계속 사용하게

되면 response time이 일정치 않아지는 문제와 disk service time이 늘어나는 것 처럼 나타나게 됩니다.

이러한 문제로 zfs는 기존의 ufs가 가지고 있던 'throttling' 기법을 도입하게 되었습니다.

즉, 무조건 애플리케이션이 주는 데이타를 다 받는 것이 아니라, 디스크에 적당히 내려지면 받고 하는

식으로 조절되도록 개선되었는데, 이는 file system IO의 응답시간을 더 예측가능하도록(일정해지도록)

해주는 개선효과를 가집니다. 이 개선 효과를 보실려면 Sun Solaris 10 U6이상을 사용하셔야 합니다.



끝으로, 이 메일의 주제에 나온 것처럼 스토리지가 엄청난 양의 캐쉬를 가지고 있는 경우라면 zfs는

어떨 것인가 하는 주제가 나옵니다. 즉, 이미 스토리지가 충분한 캐쉬를 가지고 있는데, zfs가 쓸데없이

캐쉬를 운영하기 위해서 헛짓하면서 cpu time을 낭비하고, 응답시간을 지연할 필요가 있는가 하는 문제가

발생합니다.



이렇게 고성능의 캐쉬가 달린 (주로 하이엔드 스토리지) 스토리지를 사용하는 경우라면 헛짓하지 않고

바로 바로 채널로 내려보내는 것이 오히려 훨씬 좋겠죠. 따라서, 이런 경우에는 zfs가 flushing을 하지

않도록(헛짓) 하는 것이 필요합니다. 이 캐쉬 플러시 작동은 저렴한 디스크가 내장한 캐쉬를 플러시하기

위해서 사용된 것인데, 비휘발성 고비용 캐쉬를 가진 어레이 붙였다면 필요가 없겠죠.

최소한 6x40같은 급 이상의 스토리지를 사용하면서 솔라리스10 U4을 사용하신다면 /etc/system안에

zfs의 noflush를 활성화하는 것을 권고합니다. (set zfs:zfs_nocacheflush = 1
)



반가운것은 솔라리스 10 U7에는 cached를 가진 어레이를 자동으로 감지하도록 변경되어서 제공한다니

update 7을 사용하시도록 패치하거나 새 버젼을 설치해보시는 것도 좋을 듯 합니다.



관련 기술의 이해는 이곳을 참고하시기 바랍니다.
 http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide

솔라리스에서 원격화면(vncviewer)을 동영상으로 캡쳐하는 툴

vnc2swf - Screen Recorder

python 버젼도 생겼네요.
vncserver에서 연결하는 내용을 동영상 화일로 저장해줍니다.
동영상 포맷은 .swf 혹은 .flv 입니다.

데모 환경 구성에 아주 유용한 툴입니다.

썬컴파일러와 gcc의 옵션 비교

오픈솔라리스에 들어있는 기본 gcc 컴파일러는 버젼이 상당히 낮습니다. 3.4.x(?)
따라서, 그럭저럭 사용하는데는 큰 문제 없습니다만,
컴파일러 저버젼 사용에 따른 최적화 부족 현상과 버그 현상이 발생할 수 있는데
이는 썬의 컴파일러를 사용하면 대부분 발생하지 않는 문제입니다.

따라서, 솔라리스에서는 썬의 컴파일러(스튜디오)로 모든 애플리케이션을
재 컴파일하는 것이 최고의 선택이라고 할 수 있습니다.

그런데, 간혹  gcc 용으로 제작된 환경에서는 gcc 옵션으로 컴파일하게 되어 있어
빌드시 상당한 오류를 접하게 됩니다. 이때 아래에 나오는 옵션으로 치환해서
사용할 수 있습니다.
Translating gcc/g++/gfortran Options to Sun Studio Compiler Options

아울러, 필요 불가결하게 gcc를 사용해야 한다면, 최신의 gcc를 sun 컴파일러로 최적화로 컴파일해서
사용하는 것이 바람직합니다.

한편,컴파일러 옵션 차이가 별것 아니겠거니 생각한다면 커다란 오산입니다.
특히, 병렬 처리를 하는 경우에는 이러한 차이를 결코 무시하면 안됩니다. 병렬 처리에는 매우 많은
요소들이 결합되는데, 각 요소별로 최적화 수준에 따른 누적된 지연시간이 만만치 않기 때문입니다.

여러개의 CPU를 가진 경우에는 OpenMP를 적절하게 사용하고, 멀티 CPU 노드를 여러개 운영하는
환경에서는 MPI stack 및 호출 애플리케이션을 최적화해서 적용하도록 해야 합니다.

아래 페이지 참고 :
http://www.coyotegulch.com/products/acovea/
http://developers.sun.com/solaris/articles/options.html
http://opensolaris.org/os/project/gccfss-on/bestoptions/