2009/01/31

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이나 리듬박스등을 다시 실행해보면, 연주가 되는 것을 알 수가 있을 겁니다.



2009/01/30

고성능 스토리지(하이엔드 스토리지 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

2009/01/29

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

vnc2swf - Screen Recorder

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

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

2009/01/28

썬컴파일러와 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/