오픈 솔라리스와 3차원(3D) 인터페이스

썬마이크로시스템즈는 지난 5월 오픈 솔라리스 배포판을 새롭게 내놓았습니다. 많은 분들이 이와 관련된 블로깅을 하고 있으므로 참고하시면 됩니다.
sangpill님의 http://blogs.sun.com/snoopy40/entry/new_solaris_for_devepolers_opensolaris
kyunghwa님의 http://suns.tistory.com/

흥미로운 부분은 오픈 솔라리스에는 오픈 소스에서 3D 데스트크탑 인터페이스인 컴피즈 퓨전(compiz fusion)이 내장되어 있습니다. 쓸만한 그래픽카드를 가지신 분이면 바로 활성화함으로써, 그 화려한 부분을 엿볼 수 있습니다.

주 메뉴(메인)에서 환경설정 -> 모양새 를 선택하시면 테마를 변경할 수 있는 다이얼로그가 나오는데, 여기에서 Visualization Effects 란 탭을 선택해서 두번째 이후의 옵션을 선택하면, 3D 인터페이스가 나옵니다. 처음에 핫키를 모르는 분들을 위해서 몇가지 유용한 키를 언급해드리면,
작업창의 애플리케이션간의 스위칭을 위해서 Meta(Mod key or Windows Key) + Tab 을 누르시면 아주 멋진 윈도우 스윗칭 환경이 연출됨을 보실 수 있습니다.

맥에서 보이는 분위기와 비슷한 환경을 느껴보시고 싶으시다면 우측 위 코너로 마우스 포인터를 가져가시면 작업 데스크탑에서 실행되는 여러개의 애플리케이션들이 선택을 기다리면서 예쁘게 나열됩니다.
물론, 기존의 Alt-Tab도 작동을 합니다.

작업 데스크탑 간의 선택을 하시고 싶으시다면 마우스를 화면 좌측 위 코너로 가져 보시길 바랍니다.네개의 작업창이 모두 보이는 장면이 연출됩니다. 작업하시고 싶은 창을 선택하시면 됩니다. (혹은 Left Ctrl + Left Alt + Up Arrow 후에 Ctrl과 Alt유지하신 채 좌,우 화살키를 사용하셔도 됩니다.)



환상적입니다. 솔라리스에서 새로운 경험을 해보시기 바랍니다.

참고 이미지





* 솔라리스 컴피즈 설정 문제 해결(compiz setting configuration troubleshooting)

현재(2008년 6월)는 솔라리스가 Nvidia 그래픽카드와 가장 완벽하게 동작하고 있으며, ATI도 그런데로 동작하는 것으로
보고되고 있습니다. 인텔 내장보드의 경우에는 다소 xorg.conf에 수작업을 통한 구성변경이 필요한 것으로 되어 있습니다.



인텔 칩셋의 경우 Visual Effects Tab에서 작동 활성을 선택했는데 조금있다가 시스템이 멍해지는 현상이 발생하는
경우가 있습니다. 이런 경우에는 재부팅한 후 터미널 안전 모드로 로그인한후 터미널에서 다음과 같이 실행해서 기본 윈도우
매니저(default window manager)를 3차원 3D 매니저인 /usr/bin/compiz에서 이전 평면 윈도우
매니저인 /usr/bin/metacity 로 변경하도록 한다.



$gconftool-2 -s /desktop/gnome/applications/window_manager/default -t string "/usr/bin/metacity"



참고로 정확하게 설정되었는 지를 확인하는 방법은 다음과 같다.

$gconftool-2 -g /desktop/gnome/applications/window_manager/default



정상적으로 변경이 되었으면 로그아웃했다가 다시 로그인해본다. 물론, "그놈(Gnome)" 세션으로 로그인한다.

다음과 솔라리스

제목이 다소 거창합니다만, 다음 잘 아시죠 ?

국내 Top2에 드는 최대 포털이면서, 독특하게 포털 기반의 미디어 회사를 염두에 둔 회사입니다.

(최근 광우병으로 아고라 담당 서버들이 거의 매일 자빠지는 것으로 보입니다. 공식적인 사항으로는 ...)



다음 블로그가 제공하는 미디어 스트리밍 서비스가 어떤가 보다가 문득 미디어 서버가 너무 느린 것 같아서 아주 기초적인 호기심으로 서버의 이름을 추적해봤습니다.

...

cfs.flvs.daum.net

...



cfs ? 갑자기 호기심이 들더군요. lustre란 의미보다는 그냥 "clustered" 화일 시스템이라 생각하면서, 그래도
혹시나 하는 의구심도 들더군요. 그래서 또 그냥 아무 생각없이 서버가 무슨 운영 체제를 사용할까 궁금해서 "포트 스캐닝"
해봤습니다. ( 저 이짓 자주하지 않습니다. 혹시 오해하실까봐 ㅡ.ㅡ; )



그랬더니 이런 데이타가 나오더군요..



SF-Port80-TCP:V=4.20%I=7%D=5/14%Time=482A9706%P=i386-pc-solaris2.11%r(GetR

SF:equest,BB1,"HTTP/1\.0\x20400\x20Host\x20Header\x20Required\r\nContent-T

...



혹시 빨간색 글자 보셨습니까? 오픈 솔라리스 플랫폼을 의미하는 아키텍쳐 스트링입니다. 햐.. 리눅스만
쓴다고 하던 이 친구들이 조용히 오픈 솔라리스를 사용하고 있었네요. 가슴이 뭉클해집니다. 한때, 최대의 썬/솔라리스 고객이었던
다음이 죄다 리눅스로 바꾸고 나선 거의 만날 일이 없었는데... 뒤에서 솔라리스를 조용히 사용하고 있었네요.. 그것도 미디어
스트리밍이라는 아주 중요한 서비스를 위해서 말이죠...


오픈 솔라리스의 지평이 조금씩 넓어지고 있다는 것이 현실적으로 증명된 것 같아서 여간 기쁘지 않네요.

가상화 비교 (xVM & vmware ESX)

성능 측면에서 보면, 현재는 Xen3 기반이 Vmware ESX3보다 평균적으로 약간 떨어지는 것으로 되어 있는데 (XenSource Report : Xen vs. VMware 성능 비교 ) 성능은 CPU 사용과 IO 사용 측면에서 다소 차이가 있습니다.



CPU workload에서는 vmware가 약간 나은 것으로 되어 있는데, 이 부분은 다소 개선의 여지가 있음을 보여주는 것
같구요. 솔라리스 기반의 xVM server가 정식으로 나오면 빠르게 개선되지 않을까 생각합니다. 아직 썬의 xVM 서버는
베타라서 정식 비교는 힘들다고 생각합니다. 특히, 데스크탑은 컨트롤 도메인을 주 웍플레이스로 사용하면서 (X-window)
게스트를 접근하는 것이라 현재 오픈 솔라리스 기반의 버젼은 아직 불필요한 부하가 많다는 생각입니다.



반면 IO Workload를 기반으로 보면 첨부에서 보는데로 Host 방식의 Vmware ESX와 Para 방식의 Xen은 Io 인터페이스시에 극명한 차이가 나도록 되어져 있습니다.



Host 방식은 이론적으로 모든 Guest가 HW 디바이스를 직접 호스팅하는 것으로 보이지만, 실질적으로는 guest
instance에는 VM-aware device를 보여주며, VMM에서 native를 인터페이스 하도록 합니다.

VMM에서는 guest instance가 사용하는 VM-aware device driver들을 switching하면서, native 디바이스와 데이타 연결을 합니다. (첨부 1)



Para 방식은 Para 게스트 도메인의 디바이스 드라이버가 컨트롤 도메인의 네이티브 디바이스 드라이버와 마치 클라이언트-서버
형태의 접속을 사용하기 때문에 스위칭 오버헤드가 없습니다. 물론, 게스트 도메인과 컨트롤 도메인과의 커뮤니케이션 오버헤드가
있겠습니다만 디바이스 드라이버 스위칭 오버헤드보다는 낮은 것으로 평가됩니다.



즉, 진정한 비교가 되려면, Para에서는 Para용 Guest를 올려야 진정한 비교가 된다는 얘기겠죠. 그리고 이런 경우 xVM(Xen)이 vmware보다 우수한 성능이 나오리라 예상이 됩니다.



그리고 IO 작업이 많을 수록 CPU의 Idle time은 증가하기 때문에 현재 있는 vmware의 CPU 잇점은 그렇게 크지 않으리라 생각합니다.

오픈 솔라리스(opensolaris)와 xmanager

썬솔라리스는 업데이트3(?) 부터인가 "Secure by default"라는 기능이 적용되어져 있습니다. 간단하게 얘기하자면, 쓸데없이 포트 스캐닝과 같은 것에 탐지되지 않도록 불필요한 서비스를 죽여놓는 것을 말합니다.
그런데, XDMCP 기반의 dtlogin 환경을 원격으로 접근하는 xmanager가 연결해야 하는 서비스도 이 범주에 해당하는 관계로 서비스가 막 설치한 환경에서 활성화되어 있지 않습니다. 따라서, xmanager를 이용하여 서버에 연결해야 하는 경우에는 다음과 같이 "secure by default"를 풀어야 합니다.

#/usr/sbin/netservices open

netservices는 다음의 서비스를 외부에서 접속되는 것을 차단하도록 구성합니다. 물론, 호스트 내부에서는 접속이 가능합니다.

system_log
cmsd
rpcbind
xserver
sendmail
ttdbserver
dtlogin
webconsole
smcwbem

참고로 서버에 연결하는 바람직한 방법은 ssh [-X] 를 사용하는 것이 보안상 바람직합니다. Windows 클라이언트에서 연결하고 싶은 경우에는 Sun의 Secure Global Desktop이나 SunRay 혹은 VNC server, Seamless RDP 서버등과 같은 보안이 강화된 서비스를 이용하여 클라이언트 접속을 하는 것이 바람직합니다.

솔라리스에서 md5 첵섬 사용

솔라리스(Solaris) 10(최초 공개버젼에서는 못본것으로 기억합니다)에서는 기본적으로 md5 및 기타 첵섬을 위한 툴로 digest라는 툴을 제공합니다.

다음은 digest라는 툴을 이용해서 md5 digest를 구하는 예입니다.
#digest -a md5 datafile

참고로 digest가 제공하는 md5 이외의 알고리듬의 목록을 보시려면 다음처럼 실행하면 됩니다.
#digest -l

digesting 기법을 이용하면, 특정 디렉토리나 화일에 대해서 다이제스팅을 함으로써 시스템을 보안 강화를 요할 수 있습니다.(System hardening) 이러한 개념을 도입하여 편리하게 hardening을 지원해주는 유틸리티로 bart라는 유틸리티가 솔라리스에서는 기본적으로 제공됩니다.

솔라리스에서 일반 사용자가 ifconfig만 실행하게 할 수 있을까요 ? (Solaris RBAC)

가장 쉬운 방법은 그 사용자의 아디디가 user1이라고 할때
user1을 모두 로그아웃 시키고,
#usermod -P"Network Management" user1
이라고 실행한 후 user1이 로그인해보면

$profiles -l 실행했을 경우
자신이 실행할 수 있는 root 전용 명령어들이 나타납니다.

이 때 나타나는 명령어는 Network Management Profile(Role)에서 주어진 내용
으로 다음과 같습니다.

Network Management:solaris:cmd:::/sbin/dladm:privs=sys_net_config
Network Management:solaris:cmd:::/sbin/ifconfig:uid=0
Network Management:solaris:cmd:::/sbin/route:privs=sys_net_config
Network Management:solaris:cmd:::/sbin/routeadm:euid=0;
privs=proc_chroot,proc_owner,sys_net_config
Network Management:solaris:cmd:::/usr/sfw/sbin/zebraadm:privs=basic
Network Management:suser:cmd:::/usr/bin/netstat:uid=0
Network Management:suser:cmd:::/usr/bin/rup:euid=0
Network Management:suser:cmd:::/usr/bin/ruptime:euid=0
Network Management:suser:cmd:::/usr/bin/setuname:euid=0
Network Management:suser:cmd:::/usr/sbin/asppp2pppd:euid=0
Network Management:suser:cmd:::/usr/sbin/ifconfig:uid=0
Network Management:suser:cmd:::/usr/sbin/ipaddrsel:euid=0
Network Management:suser:cmd:::/usr/sbin/ipqosconf:euid=0
Network Management:suser:cmd:::/usr/sbin/rndc:privs=file_dac_read
Network Management:suser:cmd:::/usr/sbin/route:uid=0
Network Management:suser:cmd:::/usr/sbin/snoop:uid=0
Network Management:suser:cmd:::/usr/sbin/spray:euid=0

그런데, 이때 중요한 것은 user1이 새로 로그인해서 ifconfig를 실행하려면 특수한 쉘을 사용해야만 실행할 수 있습니다. 그렇게 안할 수도 있습니다만, 여러가지 이유로 이렇게 하는 것이 보안상이나 운영면에서 좋습니다.

$pfexec ifconfig -a plumb

혹은

$pfksh 
#ifconfig -a plumb <-이때 effective user id로 root를 받게 되는데, 앞서 나열된 명령어만 사용가능합니다.  #exit $  위처럼 프로파일을 사용하게 되면, 해당하는 명령어 이외에 다른 명령어 군들 도 실행할 수 있게 되는데, 이는 장단점이 있습니다. 실제로 ifconfig를 효과 적으로 컨트롤하려면 route 명령어도 사용할 수 있어야 하는 경우도 있으며, netstat와 같은 모니터링 커맨드도 돌릴 수 있어야 하기 때문에, 한번에 이런 것들을 가능하게 하는데는 이것이 가장 좋습니다.  하지만, 특수 쉘을 사용하지않고, root처럼 기본 쉘에서 바로 실행할 수 있도록 할 수 있는데 user1을 로그아웃 시킨후 다음과 같이 실행합니다.  #usermod -K"defaultpriv=proc_fork,proc_exec,sysnet_config" user1 을 실행한 후 user1이 새로이 로그인하면 위의 ifconfig 명령어를 실행할 수 있습니다. 이때는 pfexec/pfksh과 같은 특수 쉘을 사용하지 않고 바로 실행할 수 있습니다.  이 방법의 장점은 사용자의 애플리케이션이 바로 위의 해당하는 기능을 위한 시스템 콜을 일반 사용자로서 바로 사용할 수 있다는 점입니다. 반면, 이 방법의 문제점은 사용자 관점의 명령어 기준으로 구분하지 않고, 접 근권한 관점에서 컨트롤하기 때문에 위의 옵션이 다른 어떤 커맨드가 작동가 능한지 일단 알기 어렵습니다. 해당 애플리케이션이 어떤 디바이스를 접근하 고 어떤 시스템콜을 쓰는지를 조사해보아야만 알수 있는 것이기 때문입니다. 즉, 저위의 정의에 따라서, 사용자는 애플리케이션 내부에서 ifconfig를 실행 할 수 있습니다.  또한, 기존에 미리 구성되어 있는 프로파일을 사용하지 않고, 완전히 개인화된 프로파일을 만들어서 제공할 수도 있습니다. 이런 경우에는 어떤 사용자가 실행할 수 있는 명령어군들을 완전히 정의해서 사용할 수 있으므로, 완벽한 컨트롤을 할 수가 있는 반면에, 사용자가 원하는 기능에 의존성이 있는 명령어가 어떤 것이 있는 지를 사전에 조사해놓고 사용하는 것이 좋습니다. 예를 들면, ifconfig만을 돌릴 수 있는 Network Management2를 만들었는데, 실제로 사용자는 ifconfig와 함께 snoop을 늘 같이 돌리기 원할 수 가 있으므로, 이러한 조사를 사전에 해서 사용상 제한이 없도록 하는 것이 바람직합니다.  완전한 개인화를 하기위해서는 다음과 같은 순서로 합니다. 1) 일단 Profile을 작성합니다. /etc/security/prof_attr 2) 만든 프로파일(Profile) 이름으로 실행될 실행 화일을 선언합니다. /etc/security/exec_attr 3) 일반 사용자에게 새로 만든 프로파일을 적용합니다.  TIP ! user1을 로그아웃 시키지 않고 구성을 변경하려면 /etc/user_attr을 편집해야 합니다. 편집하게 되면 해당 사용자가 변경 이후에 실행하는 쉘부터 효과가 적용되어 나타납니다. 

솔라리스용 wxPython 컴파일 및 최적화하기.

솔라리스에서 사용할 wxPython 모듈을 포팅하고 최적화하는 방법을 입니다.
wxPython은 ./configure가 매우 뛰어난 호환성을 바탕으로 제작되었기 때문에 그다지 큰 수고로움이 필요없습니다.
일단, 훌륭한 컴파일러와 약간의 시간만 투자하면 됩니다.

컴파일러는 썬스튜디오 12를 권고합니다. 솔라리스에 들어있는 gcc가 오래됐을 뿐 아니라, gcc 새버젼을 받아서 재컴파일을 하더라도 솔라리스용으로 최적화하려면 스튜디오가 역시 필요하기 때문에 그냥 스튜디오 다운 받아서 사용하는 것이 편합니다. 스튜디오는 사용료가 무료이므로 그냥 다운 받아서 쓰면 됩니다.

소스의 형태는 주로 wxPython-src-2.8.7.1.tar.bz2와 같이 공급이 되는 데 이런 경우(bzip2 압축인 경우) 에는 다음과 같이 압축을 풀 수 있습니다. 물론, 그래픽 툴을 이용해도 좋습니다.

#bzip2 -dc wxPython-src-2.8.7.1.tar.bz2 | tar xvf -
#cd wxPython-src-2.8.7.1

경험적으로 썬 스튜디오가 확실히 gcc 보다 나은 것 같습니다.
스튜디오 12을 받아서 기본 환경으로 설치했다면 이제 cc /CC/dmake 등을 사용할 수 있게 되었을 겁니다.
그렇다면, wxPyhton 소스를 다운 받아서 압축을 풀고 디렉토리로 들어갑니다.


configure를 합니다. 최적화를 위해서는 다음과 같이 합니다. 설치시 바로 솔라리스 /usr에 설치할 목적으로 하는 경우에는 다음과 같이 구성하면 됩니다. 별도의 패키지를 구성하기 위해서는 --prefix 를 변경하면 됩니다.

#./configure \
--prefix=/usr \ <- /usr 에 설치합니다.
--with-gtk \ <- gtk+2 UI용 라이브러리를 빌드합니다.
--with-opengl \ <- 3D 인터페이스를 opengl을 이용하여 구성합니다.
--enable-unicode \ <- Unicode를 지원하도록 합니다. (필히 하는 것이 바람직합니다.)
CC=cc \ <- c 컴파일러로 cc 를 씁니다. GCC를 쓰고 싶으면 gcc 선언
CXX=CC \ <- c++ 컴파일러로 CC를 씁니다. GNU C++를 쓰고 싶으면 g++ 선언
CFLAGS="-fast -xO3 -L/opt/SUNWspro/lib -lsunmath" \ C 컴파일러의 최적화 옵션을 선언합니다. 가장 빠르게 하지만 최적화 수준은 level 03로 유지 (레벨이 너무 높으면 플랫폼간 호환성이 떨어집니다. )
CXXFLAGS="-fast -xO3" \ <- C++ 컴파일러의 최적화 옵션을 선언합니다.
LDFLAGS="-L/opt/SUNWspro/lib -R/opt/SUNWspro/lib -lsunmath" <- 링키지 에디터의 라이브러리 옵션을 선언합니다. 썬 스튜디오 12는 썬에서 개발된 고성능 수학함수 라이브러리를 제공합니다. wxPython의 경우 일부 모듈에서 수학 함수를 사용함으로써 더 좋은 성능을 확보할 수 있습니다.


이미 커멘트에서 언급했듯이 , wxPython이 제공하는 몇몇 수학함수 호출용 라이브러리의 성능을 보다 최적화 하기 위해서는 썬 스튜디오가 제공하는 수학 함수 라이브러리를 이용하면 libm 혹은 gcc libm의 라이브러리 대비 최고 200% 이상의 성능을 내는 경우도 있습니다. 따라서 , 안정성에 문제가 없는 지를 확인해보시고 사용하시길 권고 합니다.

솔라리스 프로세스의 오픈 화일 보는 법

리눅스 사용자들을 보면, 왕왕 lsof 라는 툴을 사용하는 것을 보게된다. lsof라는 툴은 기본적으로 실행중인 프로세스가 어떤 화일을 열고 있는 지를 보여주는 툴인데, 오픈한 화일 뿐 만 아니라, 네트웍(소켓)을 오픈한 것도 보여주기 때문에, 어떤 포트를 사용하는 지 확인할 때 아주 유용한 툴로 널리 사용되어 왔다.

솔라리스에서는 이와 유사한 툴로 pfiles 라는 유틸리티가 제공이 되고 있으며, 솔라리스 8 에서는 /usr/proc/ bin 디렉토리에 있던 유틸리티였으나, 솔라리스 9때부터 /usr/bin으로 옮겨졌다.

lsof가 오랜동안 사용되어 오면서 보다 verbose한 내용을 제공하는 것은 사실이나, pfiles도 거의 동등한 수준에 내용을 제공하므로 상당히 유용할뿐 아니라, 솔라리스에서는 pfiles 면 충분하다는 생각이 든다.
pfiles의 사용법은 다음과 같다.

$pfiles

그런데, lsof나 pfiles는 프로세스의 특정 순간 (캡쳐를 시도하는 타임의 스냅샷)에 오픈된 화일만 보여준다. 만약, 해당 프로세스가 주기적으로 짧게 화일을 열고 닫는 것을 반복적으로 한다면, 이 유틸리티로는 매우 그 과정을 매우 찾기 힘들다. 리눅스에서는 그것을 해결하기가 현재는 매우 힘든 반면, 솔라리스 10에서는 dtrace라는 환상적인 툴을 제공함에 따라, 상상 이상의 데이타를 제공해준다.

다음의 dtrace 툴은 해당 프로세스가 언제 어떤 화일을 여는 지를 보여준다. dtrace에서 화일을 여는 것을 트레이스 하는 방법은 syscall의 open을 추적하는 방법이 있을 수도 있고, dtrace가 제공하는 io Provider를 이용하는 방법도 있다. 단순 화일명이외에 화일이 위치하는 디스크의 이름등과 같이 구체적인 정보를 보고자하는 경우에는 io Provider를 화일 이름정도만을 트레이스 하고 싶으면 open을 트레이스 하는 것이 편리하다.

/* open.d */
#!/usr/sbin/dtrace

syscall::open:entry
/execname == firefox-bin/
{
trace(copyinstr(arg0));
}



#dtrace -s open.d
와 같이 실행하고 있으면, dtrace는 firefox-bin 이라는 실행프로그램이 나타날때까지 가만히 있는다. 나타나게 되면, 그때 부터 트레이스를 시작한다. 실행 화일 이름은 실제로 실행된 프로그램의 이름과 간혹 다른 경우가 있다. 대게 환경 설정과 같은 것을 수반하기 위해서 쉘스크립트를 실행하는 경우가 있는데, 이런 경우에는 시작하는 쉘이 invoke하는 실제의 애플리케이션의 이진화일의 이름을 주는 것이 좋다.

위의 예처럼 firefox는 대게 firefox라는 쉘스크립트로 실행되지만, 실제 실행해보면, 실행 화일은 firefox-bin이라는 화일이 수행되고 있다.

위의 예에서 lsof와 같이 프로세스의 pid로 추적을 하고 싶으면서 dtrace의 아규먼트로 pid를 주고 싶다면 다음과 같이 변경해서 실행시키면 된다.

/* open2.d */
#!/usr/sbin/dtrace

syscall::open:entry
/pid == $1/
{
trace(copyinstr(arg0));
}

실행 예
#dtrace -s open2.d `pgrep firefox-bin`

솔라리스 화일 시스템 성능 테스트 스크립트

솔라리스와 같은 유닉스 혹은 유닉스 유사 계열은 주로 서버사이드에서 많이 사용되는 관계로 화일 시스템의 혹독한 테스트를 필요로 하는 경우가 왕왕 있다. 이런 경우를 위해서 다양한 화일 시스템 테스트 툴이 있는데, iGen이라던가, bonnie라던가 하는 것들이 웹에서 쉽게 찾아서 사용할 수 있는데,단순한 화일 쓰기 테스트만을 테스트하기 위해서 복잡한 툴을 사용하는 것은 다소 번거로운 것 같아서 하나 작성해보았다.

/dev/urandom에서 생성되는 랜덤 데이타 화일을 기반으로 테스트 화일을 1M 기준으로 동시에 작성하도록 되어 있다. 총 종료 시간을 측정하기 위해서는 실행화일 끝에 wait를 두도록 한다.

#!/usr/bin/bash
ARG1=$1; NUM_OF_FILES=${ARG1:=10}

set i=0
i=$((i+1))

maketmpfile() {
# 1MB file generation
tmpfilename=test$RANDOM

#echo $tmpfilename#

dd if=/dev/urandom of=$tmpfilename bs=1024 count=1024 > /dev/null 2>&1 &

# for debugging
#echo " dd if=/dev/urandom of=$tmpfilename bs=1024 count=1024"
#

}

while true
do
# for debugging
#echo -n "$i:"
#

maketmpfile
i=$((i+1))
if [ $i -gt $NUM_OF_FILES ] ; then
exit 1
fi
done
wait

테스트 방법은

$timex filebench_v2.bash 1000
과 같이 실행함으로써 테스트할 수 있다.

솔라리스 UFS 화일 시스템의 최대 화일 개수와 inode의 부족

단일 디렉토리 내에서는 32767개의 디렉토리만 지원하므로, 각 디렉토리는 서브
디렉토리를 가져야만 더 많은 디렉토리를 가질 수 있고, 각 디렉토리별로 더 많은
화일을 가질 수 있게 됩니다.

단일 디렉토리에 형성할 수 있는 화일의 개수는 이론적으로 제한이 없습니다만,
inode의 개수에 제한을 받습니다. 32비트 화일 시스템에서는 최대 40억개의 inode를 (unsigned long long for 64bit, unsigned long for 32bit) 구성 하실 수 있습니다만, inode에 할당하는 블럭의 크기(디폴트는 1 inode에 2kb를 사용)에 따라 변화가 있으므로 다음과 같은 방법으로 체크하실 필요가 있습니다.
inode만 보고 싶은 경우에는
#df -F ufs -o i /

혹은 기타 다른 상황까지 보고 싶은 경우에는 fstyp 이용
# fstyp -v /dev/dsk/c0t0d0s0 | less
ufs
magic 11954 format dynamic time Tue Oct 30 13:59:33 2007
sblkno 16 cblkno 24 iblkno 32 dblkno 760
sbsize 2048 cgsize 8192 cgoffset 64 cgmask 0xffffffc0
ncg 627 size 30803962 blocks 30337448
bsize 8192 shift 13 mask 0xffffe000
fsize 1024 shift 10 mask 0xfffffc00
frag 8 shift 3 fsbtodb 1
minfree 1% maxbpg 2048 optim time
maxcontig 128 rotdelay 0ms rps 167
csaddr 760 cssize 10240 shift 9 mask 0xfffffe00
ntrak 48 nsect 128 spc 6144 ncyl 10028
cpg 16 bpg 6144 fpg 49152 ipg 5824
nindir 2048 inopb 64 nspf 2
nbfree 1748247 ndir 31696 nifree 3392581 nffree 255808
cgrotor 101 fmod 0 ronly 0 logbno 1584
version 2
.....

참고 화일 /usr/include/sys/types.h

//
// 32bit의 경우
typedef ulong_t         ino_t;          /* expanded inode type  */
...
typedef ulong_t         fsfilcnt_t;     /* count of files */

// 64bit의 경우
typedef u_longlong_t    ino_t;          /* expanded inode type  */
...
typedef u_longlong_t    fsfilcnt_t;     /* count of files */
//
//
inode가 부족하다고 판단이 되는 경우에는 tunefs를 통해서  inode 블럭당 사용되는 용량을
줄여서 즉, space 기준으로 최적화를 함으로써 inode를 좀 더 획득할 수 있습니다.

그러나, inode가 풍부함에서 디렉토리를 나열하거나(ls) 하는데, 오랜 시간이 걸리면서
sys% 가 증가하는 경우에는 캐쉬 테이블의 크기가 부족해지는 경우가 대부분입니다.

이런경우 일단, 가장 쉬운 workaround로는
/etc/system에 튜닝을 하실 필요가 있습니다. 단 메모리가 충분이 있어야 합니다.
튜닝 대상이 되는 시스템 변수는 ncsize이며, ufs_ninode라는 변수의 상위 개념에 해당합니다.

일단 현재 사용되는 값을 확인하기 위해서는 다음과 같은 방법을 사용합니다.
# echo "ncsize/D" | mdb -k
ncsize:
ncsize:         129700

숫자를 확인하셨으면 다음과 같이 필요한 만큼의 숫자를 결정하신 후 /etc/system에 입력합니다.
set ncsize= 1042865

또한, 디렉토리 나열을 느리지 않은데, 화일 /O(데이타를 읽거나, 쓸때)가 느리다고 판단이 되는 경우에는
다음과 같은 시스템 변수의 튜닝을 할 필요가 있습니다.
segmap_percent

설정 이전에 먼저 보는 법은 다음과 같습니다.
# echo "segmap_percent/D" | mdb -k
segmap_percent:
segmap_percent: 12

확인이 되었으면, 다음과 같이 설정을 하되, 너무 큰 값을 설정하지 않도록 주의 합니다.
이 설정은 커널이 I/O를 위해서 많은 메모리를 사전 할당하도록 하므로, 메모리 사용에 커다란
영향을 주게 됩니다.

set segmap_percent=25

와 같이 튜닝하시고 테스트후 조정하는 과정을 거쳐야 합니다.

상황에 따라서는 위 두개의 튜닝을 동시에 진행할 수 있습니다. 그럴 수록 커널 메모리의 상태를 잘 이해하고 있어야 합니다. 참고로 커널이 사용하는 메모리의 상태를 보기 위해서는 다음과 같은 명령어를 사용할 수 있습니다.

#echo "::memstat" | mdb -k ; 솔라리스 9이후 부터 가능. 메모리가 큰 장비에서는 오래 걸림.

참고로 솔라리스 10의 ZFS를 사용하면 UFS가 가지는 위와 같은 문제가 근원적으로 발생하지 않습니다.

프로세스의 서비스 종료 방법

솔라리스10 ( 08/07 이후 )에서는 시스템이 부팅하면서 자동적으로 시작되는 모든 프로세스들은 SMF라는 서비스 관리하에서 구동이 됩니다. 따라서, 해당 서비스를 시작하거나 종료하기 위해서는 SMF의 관리 명령어인 svcadm을 사용해야 합니다.

telnet 서비스를 종료하기 위해서는
#svcadm disable telnet
과 같이 실행하며, 어떤 서비스가 있고 어떤 상태에 있는 지를 알기 위해서는
#svcs -a 를 사용합니다.(이전 블로그에 언급한 바 있습니다.)

이때 사용되는 telnet 혹은 telnet:default 와 같은 아규먼트를 서비스를 지칭하는 FMRI라고 합니다.

그런데, 어느날 prstat를 실행했는데 잘 모르는 프로세스가 실행되고 있다면 어떻게 해야 할까요?
즉, 특정 프로세스가 어떤 서비스에 의해서 시작되게 되었는지를 알아야 해당 FMRI를 찾아서 종료시킬 수 있을텐데, 프로세스만 실행되고 있다면 바로 알기가 어렵습니다. 이때, 사용할 수 있는 것이 pargs 라는 유틸리티입니다.

pargs는 아큐먼트로 오는 프로세스 아이디를 받아서, 그 프로세스가 실행할때 넘겨받은 아규먼트를 보여주는 유틸리티입니다만, -e 옵션을 사용하면, 그 프로세스가 실행할 당시에 상속받은 모든 환경 변수를 보여주는 기능도 합니다.

일반적으로 SMF에 의해서 실행된 모든 서비스들은 해당하는 FMRI에 대한 변수가 상속되어져 있기 때문에 의문의 프로세스 ID와 pargs -e 를 이용하여 해당 프로세스를 구동시킨 FMRI를 찾을 수 있습니다.

1298 noaccess 167M 89M sleep 59 0 0:01:50 0.0% java/23


와 같은 프로세스가 돌고 있는 것을 발견했을때, 이 프로세스가 어떤 FMRI로 시작했는 지를 알기위해서는 다음과 같이 실행합니다.
# pargs -e 426
#pargs -e 1298
1298: /usr/java/bin/java -server -Xmx128m -XX:+BackgroundCompilation -XX:PermSize=32m
envp[0]: LANG=ko
envp[1]: LD_LIBRARY_PATH=/usr/jdk/instances/jdk1.5.0/jre/lib/sparc/server:/usr/jdk/instances/jdk1.5.0/jre/lib/sparc:/usr/jdk/instances/jdk1.5.0/jre/../lib/sparc:/usr/lib/webconsole
envp[2]: NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat
envp[3]: PATH=/usr/sbin:/usr/bin
envp[4]: SMF_FMRI=svc:/system/webconsole:console
envp[5]: SMF_METHOD=/lib/svc/method/svc-webconsole start
envp[6]: SMF_RESTARTER=svc:/system/svc/restarter:default
envp[7]: TZ=ROK
envp[8]: XFILESEARCHPATH=/usr/dt/app-defaults/%L/Dt

위에서 envp[4]에서 해당 프로세스는 webconsole:console에서 서비스가 시작되었음을 알 수 있습니다. 따라서, 이 프로세스가 필요없다면, 이 서비스의 FMRI를 이용하여 죽일 수 있습니다.

다음과 같은 방법으로 서비스를 종료시킴으로써 프로세스를 종료시킬 수 있습니다.

#svcadm disable webconsole

솔라리스에서 성능 향상을 위한 컴파일

솔라리스에서는 다양한 형태의 성능 개선 방안이 있습니다.
사실 컴퓨팅 환경에서는 너무나 많다보니, 일일히 언급하기도 어렵습니다만,
일반적으로 간과되는 것 중 하나는 애플리케이션을 개발할때 사용했던 시스템
과 컴파일러와의 조함입니다.

솔라리스는 새버젼에서 조차 옛버젼에 대한 이진 화일 호환을 유지하다 보니,
구형 플랫폼을 위해서 컴파일된 이진 화일을 그대로 새 플랫폼으로 가져와서
(복사해서) 실행해도 전혀 문제가 없다 보니 간혹 새 플랫폼에 맞추어 컴파일
되어 있지 않은 경우가 왕왕 있습니다.

만약, 기존에 사용하던 플랫폼이 U-II 400Mhz를 가지고 있던 E450 장비였는
데, 32비트 애플리케이션을 개발해서 사용했다면, 기존에 개발된 애플리케이
션은 SparcV8+에 디폴트로 최적화 되었을 수 있습니다. 컴파일시 특별한 지정
이 업스면 32비트이면서 썬의 가장 최후 32비트 머신에 최적화된 구조로 컴파
일합니다.

그러나, 이후 CPU가 발전함과 동시에 이에 맞추어 최적화할 수 있도록 컴파일
러도 발전되었으므로, 구형 플랫폼에 솔라리스를 버젼업 했거나, 새로운 플랫
폼으로 완전히 이전하는 경우에, 하드웨어를 위한 최적의 튜닝을 원한다면 새
로 컴파일하는 것도 매우 훌륭한 방법이라고 할 수 있습니다.

현재 내가 가지고 있는 이진 화일의 속성을 알기 위해서는 다음과 같이 명령
을 내립니다.

$file /usr/sfw/bin/gs
> file /usr/sfw/bin/gs
/usr/sfw/bin/gs: ELF 32-bit MSB executable SPARC Version 1,
dynamically linked, stripped

위의 gs는 별 최적화 없이 32비트 구형 머쉰을 위한 구조로 컴파일되어 있음
을 알 수 있습니다. 만약 컴파일시 최적화 옵션을 제공했으면 달라지게 됩니다.

> file `which xine`
.../bin/xine: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
Required, UltraSPARC1 Extensions Required, dynamically linked, not stripped

위의 명령어는 32비트 머쉰중 가장 최신 기종인 SPARC32+ V1을 모델로 컴파일
되어 있으며, UltraSPARC 1 extensions을 사용한다는 것을 알 수가 있습니
다. 따라서, 컴파일시 어떤 최적화 컴파일을 제공했느냐에 따라서 성능에 차
이를 가져올 수 있으며, 이러한 차이는 '캐쉬'의 영향을 많이 받는 애플리케
이션과 '수학'과 '멀티미디어' 라이브러리를 사용하는 애플리케이션에서 두
드러진 차이를 보입니다.

따라서, 새로운 솔라리스 10에서 컴파일을 다시 해야 하는 경우, 사용하는 컴
파일에 따라서 다음과 같은 컴파일 옵션으로 시도해는 것은 상당히 가치있는
일입니다.

SunStudio 12 를 사용하는 경우
$cc -fast a.c

참고로 -fast는 다음과 같은 옵션의 매크로입니다.
-fns
-fsimple=2
-fsingle
-nofstore (x86)
-xalias_level=basic
-xbuiltin=%all
-xdepend
-xlibmil
-xlibmopt
-xmemalign=8s (SPARC)
-xO5
-xprefetch=auto,explicit (SPARC)
-xregs=no%frameptr (x86)
-xtarget=native

만약, -fast 옵션에 의해 임의의 리덕션이 수행되어서, 수행시 비정상 종료되
는 일이 발생한다면 최적화 레벨을 낮추어서 컴파일을 시도해볼 필요가 있습
니다. -fast의 옵션중 유효한 것만 재조합해서 테스트해보는 것도 중요합니다.

$cc -xO3 -xtarget=native a.c

만약, 수학 함수를 사용하는 경우에는 UltraSPARC의 VIS 인스트럭션과 강력한
썬의 수학 라이브러리를 사용하는 것을 시도해보는 것도 좋은 방법입니다.

$cc -xO3 -xtarget=native -xvis a.c -I/opt/SUNWspro/lib -lsunmath

gcc로 컴파일하는 경우에는 대개 머쉰 컴파일 옵션(-m)으로 최적화를 우선적
으로 시도해볼 수가 있습니다.
$gcc -mcpu=v9 a.c
$gcc -mtune=v9 a.c ; Sun compiler와는 달리 -mcpu, -mtune은 64비트 이진
화일 생성을 유도하지 않습니다.

gcc에서 빠른 수학 연산 및 멀티미디어 연산을 위해서는 다음과 같은 옵션을
사용해 볼 수 있습니다.

$gcc -ffast-math -mcpu=v9 -mvis a.c -I/opt/SUNWspro/lib -lsunmath

컴파일시 이렇게 튜닝한 애플리케이션은 특정 CPU 인스트럭션(특히, vis)를
사용할 수 있도록 되어 있을 수 있으며 이 경우에는 대상 이진 화일을 카피해
서 사용하는 플랫폼에도 해당 인스트럭션을 지원하는 CPU를 가지고 있어야만
합니다.

위의 예는 sparc 시스템을 예로 들었으며, 두 경우 모두 x86 플랫폼용 솔라리
스에서는 약간 다를 수 있습니다. -fast 옵션은 두 플랫폼 모두 공통이나 vis
옵션(-xvis, -mvis)이나 CPU 구조 옵션(-mcpu=v9)은 x86/amd64의 경우 먹지
않으므로 적용되지 않습니다.

김봉환/

솔라리스에서 애플리케이션 코어 분석( Core analyzing at Solaris )

솔라리스를 사용하다보면 간혹 홈 디렉토리에 코어(core)화일이 생기는 것을 볼 수가 있습니다. 사용에 별 지장이 없다면 그냥 지나쳐도 상관없겠지만, 그 코어가 내가 운영하는 서비스와 관련이 있는 지도 모르므로 확인해보는 습관은 중요합니다.

대개 메모리 접근 위반(Segmentation Violation)으로 생성되는 것이 대부분인데, 솔라리스의 애플리케이션에 포인터 처리가 미숙했거나, 솔라리스가 허용하는 데이타 패싱이 아니었거나 솔라리스에서 허용하는 프로토타입과 상이하게 다르거나 하는 경우에 흔히 생깁니다.

일단 core 화일이 생기게 되면, 해당 애플리케이션의 current directory에 생성됩니다. 대게 많은 애플리케이션들이 홈에서 시작이 되므로, 혹은 홈으로 현재 디렉토리를 옮기게 되므로 홈 디렉토리에 core가 왕왕 생기는 것을 볼 수가 있습니다. 또한, 솔라리스 내장되어 있는 각종 패키지들(gnome)과 같은 데스크 탑 솔루션등도 시작할때 홈에서 시작하므로 버그가 있는 경우 홈에서 core를 많이 볼 수가 있습니다.

core가 생기면 어떤 화일이 어디에서 문제가 생겨서 죽었는 지를 다음과 같이 해서 알 수 있습니다.

#file core
core: ELF 32-bit MSB core file SPARC Version 1, from 'thunderbird-bin'

#pstack core

core 'core' of 3968: /opt/sfw/lib/thunderbird/thunderbird-bin
----------------- lwp# 1 / thread# 1 --------------------
ff3416e0 _lwp_kill (b, ffbfe4b0, 0, b, fc00, 1) + 8
0051086c ???????? (b, 0, 510748, 510400, a, c4)
ff340618 __sighndlr (b, 0, ffbfe620, 510784, 0, 1) + c
ff335710 call_user_handler (b, ffbffeff, 0, 0, fe2b2000, ffbfe620) + 3b8
010b4794 ???????? (6e6e800, ff0a49bc, 24002400, 28002800, 28002800, 6e6e800)
010b5b44 ???????? (6cf5090, 63636c8, ff000000, 0, 80000000, ff0a39e4)
ff0a6fc0 __1cYnsOutputStreamReadyEventMEventHandler6FpnHPLEvent__pv_ (6c6fa74,
6c6faa8, 6c6fa70, 6cf5090, 10b5ab8, 18d79a0) + 34
ff0c03a0 PL_HandleEvent (6c6fa74, 1985454, ff0a6f8c, 1985454, 1985450, 6c6fa74) + 14
ff0c02b8 PL_ProcessPendingEvents (12, 1, d, 0, 0, 1985450) + 7c
ff0c23cc __1cQnsEventQdDueueImplUProcessPendingEvents6M_I_ (196dd08, 80004000,
ff000000, 0, 0, 1aef090) + 20
0072b840 ???????? (1af2f38, 1, 196dd08, 1, 1, ff0c23ac)
fea55ac8 g_main_dispatch (196e898, feabec00, 0, 0, fffffffd, ffffffef) + 19c
fea56ffc g_main_context_dispatch (196e898, c8, 0, 1, feabec00, 196e898) + 9c
fea574c8 g_main_context_iterate (1, 1, 1, 196e898, 196e8a0, 9) + 454
fea57c44 g_main_loop_run (1b99fe0, feabec00, ff339c58, 199a2f8, feaaa800, feaaa800) + 348
fee2a424 gtk_main (0, 0, 1b99fe0, 1aa4500, feff1eb0, 4ce0) + d0
0072bba4 ???????? (1aa6ac8, 196dd08, 18332d4, 72bbc0, c1f30000, 0)
....

위의 core는 thunderbird-bin이 생성한 것임을 알 수가 있습니다.
위의 core는 불행하게도 두가지 문제가 있는데, 하나는 debugging symbol을 가지고 있지 않는 함수가 있다는 것이고, 하나는 C++에 의한 맹글링으로 인해 함수 이름을 알아보기 어렵다는 점이 있습니다.

일단, C++ mangling 문제는 다음과 같이 함으로써 해결할 수 있습니다.

$pstack core | /opt/SUNWspro/bin/c++filt | less
core 'core' of 3968: /opt/sfw/lib/thunderbird/thunderbird-bin
----------------- lwp# 1 / thread# 1 --------------------
ff3416e0 _lwp_kill (b, ffbfe4b0, 0, b, fc00, 1) + 8
0051086c ???????? (b, 0, 510748, 510400, a, c4)
ff340618 __sighndlr (b, 0, ffbfe620, 510784, 0, 1) + c
ff335710 call_user_handler (b, ffbffeff, 0, 0, fe2b2000, ffbfe620) + 3b8
010b4794 ???????? (6e6e800, ff0a49bc, 24002400, 28002800, 28002800, 6e6e800)
010b5b44 ???????? (6cf5090, 63636c8, ff000000, 0, 80000000, ff0a39e4)
ff0a6fc0 void*nsOutputStreamReadyEvent::EventHandler(PLEvent*) (6c6fa74, 6c6faa8, 6c6fa70, 6cf5090, 10b5ab8, 18d79a0) + 34
ff0c03a0 PL_HandleEvent (6c6fa74, 1985454, ff0a6f8c, 1985454, 1985450, 6c6fa74) + 14
ff0c02b8 PL_ProcessPendingEvents (12, 1, d, 0, 0, 1985450) + 7c
ff0c23cc unsigned nsEventQueueImpl::ProcessPendingEvents() (196dd08, 80004000,
ff000000, 0, 0, 1aef090) + 20
0072b840 ???????? (1af2f38, 1, 196dd08, 1, 1, ff0c23ac)
fea55ac8 g_main_dispatch (196e898, feabec00, 0, 0, fffffffd, ffffffef) + 19c
fea56ffc g_main_context_dispatch (196e898, c8, 0, 1, feabec00, 196e898) + 9c
fea574c8 g_main_context_iterate (1, 1, 1, 196e898, 196e8a0, 9) + 454
fea57c44 g_main_loop_run (1b99fe0, feabec00, ff339c58, 199a2f8, feaaa800, feaaa800) + 348
fee2a424 gtk_main (0, 0, 1b99fe0, 1aa4500, feff1eb0, 4ce0) + d0
0072bba4 ???????? (1aa6ac8, 196dd08, 18332d4, 72bbc0, c1f30000, 0)
....

c++filt는 썬 스튜디오를 설치하면 따라오는 유틸리티입니다.
기본적으로 /usr/ccs/bin/nm도 디맹글링을 지원합니다만 사용 환경이 다릅니다.

위에서 발생한 core는 thunderbird-bin이 링크하는 동적 라이브러리에서 출력 스트림 이벤트 핸들러에서 발생한 문제임을 알수가 있습니다. 어느 라이브러리에서 발생했는지 알기 위해서는 커널 디버거인 mdb를 사용해야 합니다.

> mdb core
Loading modules: [ libc.so.1 libuutil.so.1 ld.so.1 ]
> $C
ffbfe3f0 libc.so.1`_lwp_kill+8(b, ffbfe4b0, 0, b, fc00, 1)
ffbfe450 0x51086c(b, 0, 510748, 510400, a, c4)
ffbfe4c0 libc.so.1`__sighndlr+0xc(b, 0, ffbfe620, 510784, 0, 1)
ffbfe520 libc.so.1`call_user_handler+0x3b8(b, ffbffeff, 0, 0, fe2b2000, ffbfe620)
ffbfe8d8 0x10b4794(6e6e800, ff0a49bc, 24002400, 28002800, 28002800, 6e6e800)
ffbfe940 0x10b5b44(6cf5090, 63636c8, ff000000, 0, 80000000, ff0a39e4)
ffbfe9a8
libxpcom_core.so`__1cYnsOutputStreamReadyEventMEventHandler6FpnHPLEvent__pv_+0x34(6c6fa74, 6c6faa8, 6c6fa70, 6cf5090, 10b5ab8, 18d79a0)
ffbfea08 libxpcom_core.so`PL_HandleEvent+0x14(6c6fa74, 1985454, ff0a6f8c,
1985454, 1985450, 6c6fa74)
ffbfea68 libxpcom_core.so`PL_ProcessPendingEvents+0x7c(12, 1, d, 0, 0, 1985450)
ffbfeac8 libxpcom_core.so`__1cQnsEventQdDueueImplUProcessPendingEvents6M_I_+0x20(196dd08, 80004000, ff000000, 0, 0, 1aef090)
ffbfeb30 0x72b840(1af2f38, 1, 196dd08, 1, 1, ff0c23ac)
ffbfeb90 libglib-2.0.so.0.400.1`g_main_dispatch+0x19c(196e898, feabec00, 0, 0,
fffffffd, ffffffef)
ffbfebf8 libglib-2.0.so.0.400.1`g_main_context_dispatch+0x9c(196e898, c8, 0, 1,
feabec00, 196e898)
....

위에서 $C 명령어는 core가 유도된 스레드의 스택을 보여줍니다.
장애의 소스가 되는 관심있는 함수와 모듈을 알수 있습니다.
libxpcom_core.so를 확인하게 되면 앞서 보았던, void*nsOutputStreamReadyEvent::EventHandler(PLEvent*)
임을 알 수 있기 때문입니다. 따라서, 개발자들은 이 함수의 소스를 확인해야 합니다.

지금부터는 이 함수의 어느 부분이 문제인지 확인하기 위해서는 소스 디버거나 dtrace를 사용해야만 하겠죠.

그러나, 경험적으로 core의 몇가지 정보를 더 얻을 수 있다면, 문제가 무엇인지 직감하는데 도움이
되는 경우도 있습니다.

예를 들면, 해당 core가 어떤 크리덴셜(퍼미션)을 가지고 실행했는가 ?
해당 코어는 어떤 환경에서 실행되었는가등을 알면 매우 큰 도움이 되는 경우가 있습니다.
다음과 같은 유틸리티를 통해서 알수가 있습니다.

#pargs -e core
#pldd core
#pcred core

솔라리스에서 고성능 TCP 를 위한 일반 옵션

다음은 솔라리스를 고성능으로 유지하기 위하여 사용하는 일반적인 튜닝 옵션입니다.

ndd -set /dev/tcp tcp_conn_req_max_q 8192
ndd -set /dev/tcp tcp_conn_req_max_q0 8192
ndd -set /dev/tcp tcp_max_buf 4194304
ndd -set /dev/tcp tcp_cwnd_max 2097152
ndd -set /dev/tcp tcp_recv_hiwat 400000
ndd -set /dev/tcp tcp_xmit_hiwat 400000

네트웍망이 우수하다면(일반적으로 사내정도) 다음과 같은 파라메터도 조정하는 편이 도움이 될 수 있습니다.
ndd -set /dev/tcp tcp_time_wait_interval 6000
ndd -set /dev/tcp_fin_wait_2_flush_interval 6000
이 파라메터는 일회성 접속이 많은 '웹' 과같은 서버를 동작시키는 경우에도 필수적입니다.

Solaris 10으로 업그레이드 후 현상

begin:vcard
fn:Bonghwan Kim
n:Kim;Bonghwan
email;internet:bonghwan.kim@sun.com
tel;work:82-2-2193-5225
tel;cell:82-16-325-9068
x-mozilla-html:FALSE
version:2.1
end:vcard

1.2Ghz의 U-III(12 cores)를 장착한 V1280 을 사용하던 한 사용자가 1.5Ghz의 U-IV+(24cores)가 장착된 시스템으로 업그레이드를 하게 되었습니다. 펌웨어라던가 다른 것들은 업그레이드 하지 않았구요(사실 펌웨어 업그레이드는 검토해보는 것이 좋습니다. 뭐 어쨌든) 애플리케이션도 그전에 있던 그대로 다시 재수행을 하게 되었는데, 그 해당 프로세스의 메모리 크기가 50% 정도 커졌읍니다.

왜 이런 일이 발생했을까요?

이것은 업그레이드 이전과 이후의 차이입니다.
업글 이전 :
                     Kbytes        RSS          Anon
total Kb       632800     497784     381176       

업글 이후 :
                    Kbytes        RSS          Anon
total Kb    1021168     387720     299464      

U-IV+는 솔라리스10 이후만을 지원합니다. 따라서, 운영체제가 업그레이드 되었죠. 애플리케이션은 전혀 손을 대지 않았구요. 일단 솔라리스10이 가진 변경된 피쳐를 간과한 것이 있습니다. 솔라리스 10은 스팍 시스템이 지원할 수 있는 페이지 사이즈를 여러개를 이용할 수 있도록 업그레이드 되어 있으며, 응용 프로그램에 맞추어 최적의 (자바 버추얼 머신의 경우에는 가장 큰) 페이지 사이즈를 자동적으로 이용할 수 있도록 되어 있습니다.

다음은 해당 프로세스의 pmap -x 를 본 결과 입니다.

업그레이드 이후
Address                             Kbytes        RSS           Anon     Locked Mode   Mapped File
FFFFFFFED5000000     524288       4096         4096          - rwx--          [ anon ]
FFFFFFFEFFC00000     233472       204800     204800     - rwx--          [ anon ]


업그레이드 이전
Address                             Kbytes        RSS           Anon     Locked Mode   Mapped File
FFFFFFFEE2C00000     262144     192512     192512       - rwx--    [ anon ]
FFFFFFFF0D800000     118784     106496      106496       - rwx--    [ anon ]

힙에 커다란 사이가 나는 것을 볼 수 있습니다. 그런데,  실제 메모리에 탑재되어 있는 영역은 얼마안됩니다.

이러한 차이는 두가지 이유가 있습니다. 솔라리스 10의  MPSS(Multiple Page size support)에 의해 이 프로세스에 가장 큰 페이지를 기준으로 할당을 하도록 함으로써 swap out된 메모리가 많이 할당되어 있게되었습니다. 페이지 사이즈가 커진다는 얘기는 페이징의 단위가 되는 메모리의 크기가 커졌다는 것을 의미합니다. 이것은 $pmap -xs <pid>로 확인할 수 있습니다. 따라서, 메모리 할당에 따른 조각(chunk)이 커짐에 따라 Fragmentation  커짐을 의미합니다.

참고 : man pagesize.1

솔라리스 10에서 OpenSSL 라이브러리 사용(OpenSSL link in SOlaris 10)- rdesktop example

솔라리스 10은 OpenSSL 라이브러리를 지원합니다.
그런데, OpenSSL 라이브러리가 /usr/lib에 들어있지 않고
/usr/sfw/{lib,include} 에 들어 있는 관계로 SSL을 사용하는 애플리케이션들
을 포팅해야 하는 경우 /usr/sfw/lib를 지정해주어야 하는 경우가 왕왕 있습니다.

대표적으로 rdesktop의 경우 prefix를 /usr/sfw 이외로 잡는 경우 (리눅스에
서는 흔히 /usr/local을 씁니다) 다음과 같이 선언함으로써 빌드를 할 수 있
습니다.

예) rdesktop의 빌드 예
#./configure --prefix=/usr/local --with-openssl=/usr/sfw
# gmake clean && gmake install

솔라리스 10의 고정(정적) 라우팅 (Static Routing)

begin:vcard
fn:Bonghwan Kim
n:Kim;Bonghwan
email;internet:bonghwan.kim@sun.com
tel;work:82-2-2193-5225
tel;cell:82-16-325-9068
x-mozilla-html:FALSE
version:2.1
end:vcard

솔라리스 10(U3이후) 에서는 정적 라우팅을 사용하기 위해서는

/etc/inet/static_routes

라는 화일에 다음과 같은 방법으로 라우팅 정보를 입력합니다.
# comments
destination gateway

예) /etc/inet/static_routes

#CDN network
192.168.1.1 Gateway1
#Image network
10.14.48.1 Gateway2

솔라리스 10 U3 이전 버젼에서는 가장 나이스 한 방법은 라우팅을 추가해주는 SMF를 하나 추가하는 방법이 있을 수 있으며, 가장 간단한 방법은 /lib/svc/method/net-init 에 직접 routing을 추가할 수 있습니다.

김봉환/

솔라리스10에서 TrueType 폰트

솔라리스 10에서는 TrueType 폰트를 설치하려면, 설치하고자 하는 환경과 사
용자의 관점에 따라 여러가지가 있을 수 있습니다. 일단, 트루타입을 어디에
서 사용하고자 하는 것입니다. 사용자 데스크탑 환경에서 쓰고 싶은 것인가?
아니면 특정 애플리케이션에서 쓰고 싶은가에 따라서 설치하는 디렉토리가 달
라질 수 있습니다.

MS-Windows를 사용해온 사용자들 입장에서는 다소 이해가 언뜻 안가는 것처럼
들릴 수 있는데, 이는 윈도우즈와 솔라리스가 제공해온 환경에 차이가 있기
때문입니다. MS-Windows는 데스크탑 환경에서 사용하는 모든 폰트를 트루타입
으로 제공하는데 여기에 사용되는 모든 폰트가 시스템 디렉토리에 저장되어
있습니다. 만약, 이때 별도의 트루타입 폰트를 가지고 있는 애플리케이션을
설치하고자 한다면 일반적으로는 사용자가 해당 애플리케이션 설치시 그 애플
리케이션이 가지고 있던 트루타입 폰트가 시스템 폰트 디렉토리에 설치가 되
게 됩니다.

따라서, 애플리케이션도 기본 시스템 폰트 디렉토리에서 자기가 원하는 폰트
를 찾아서 사용할 수 있게 됩니다. 애플리케이션에 따라서, 별도의 폰트 디렉
토리를 유지하는 경우도 있습니다.

그러나, 솔라리스는 오래전부터 멀티 유저 환경에서 사용되어 왔기 때문에,
시스템 디렉토리에 대한 쓰기 권한을 일반 사용자에게 제공해오지 않았습니
다. 따라서, root로 데스크탑을 사용해온 사용자들은 시스템 디렉토리에 해당
폰트들을 등록(복사) 해놓으면 원하는 환경(데스크탑 혹은 애플리케이션)에
가져다 쓸 수 있으나, 일반 사용자들은 시스템 트루타입 폰트 디렉토리에 쓰
기를 할 수 없으므로, 자신 사용자를 위한 별도의 디렉토리에 복사/등록해서
사용할 수 있습니다.

시스템 truetype 폰트 디렉토리는 로케일별로 흩어져 있으나, 대개 한글 관련
된 경로는
/usr/openwin/lib/locale/ko/X11/fonts/TrueType/
/usr/openwin/lib/locale/ko_KR.UTF-8/X11/fonts/TrueType/ (위 디렉토리와
동일함)
에 복사해서 집어 넣습니다. 필요에 따라서 fonts.dir와 fonts.alias를 만들
어 넣어야 합니다.

일반 사용자들은 $HOME/.fonts 디렉토리에 TrueType 폰트들을 복사한 후 로그
아웃 후 재 로그인하면 바로 사용가능하게 됩니다.

이때 등록된 트루타입 폰트들은 기본적으로 JDS(Gnome)에서 이용이 될 수 있
으며 StarOffice/StarSuite/Java와 같은 특정 애플리케이션에서 사용되어질
수 있습니다.

대개 starsuite은 시스템 전체적으로 설치되는 경우( /opt/starsuite8/ ) 별
도의 디렉토리를 ( /opt/starsuite8/share/fonts/truetype/ )를 따로 가져서
자체적인 트루타입을 가질 수 있습니다. Starsuite에서의 사용만을 목적으로
한다면 이 디렉토리에 설치를 해도 사용할 수 있습니다만 이런 경우 이 디렉
토리를 xset으로 기본 폰트 디렉토리로 등록하지 않게 되면 이 디렉토리 내에
있는 폰트들은 starsuite 이외의 애플리케이션에서는 사용할 수 없게 됩니다.

기존의 데스크탑 환경인 CDE는 TrueType 폰트를 사용하기 위해 변환(복사 및
fonts.dir / fonts.scale 생성)을 지원해주는 유틸리티를 제공한다
(/usr/dt/bin/sdtfontadm) 이 툴을 이용해서 복사된 TrueType 폰트는
$HOME/fontadm_fonts 라는 디렉토리로 복사되며, CDE 시작시 자동으로 font
path에 추가된다.

반면, JDS(Gnome)에서는 사용자용 TrueType 폰트 저장을 위해 $HOME/.fonts라
는 디렉토리를 제공하며, 별도의 툴 필요없이 복사만 하면, JDS(Gnome)이 알
아서 로딩한다. 실행 메뉴에 들어있는 폰트 관리 소프트웨어는 시스템 디렉토
리와 사용자 디렉토리의 TrueType 폰트 모두를 보여주나, 사용자 디렉토리에
들어있는 폰트에 대해서만 쓰기 권한을 제공한다.

JDS 환경에서는 유저별로는 $HOME/.fonts에, 시스템 전체로는 시스템 디렉토
리(위 참고)에 원하는 TrueType 폰트를 복사하게 되면 데스크탑 환경용 폰트
는 물론 일반 애플리케이션에서도 해당 폰트를 참조할 수 있게 된다.

Solaris와 System Clock(Wall Clock) 상호 운영도

대부분의 컴퓨터는 CPU를 포함한 모든 디바이스 간의 동기화를 이용하여 시스
템 클럭을 제공합니다. 이 클럭을 기본으로 CPU, Memory , PCI bus, PCI
device등이 정확한 통신을 할 수 있도록 합니다.
사용자가 컴퓨터에 내리는 시간은 이 시스템 클럭을 커널내 소프트 클럭으로
전환하여 가지고 있습니다. 사용자가 보게 되는 date & time은 이 소프트 클
럭을 인간이 볼 수 있는 포맷으로 전환하여 보도록 해줍니다. 물론, 타임존도
고려하게 됩니다.
만약 커널의 모듈(대개 디바이스 드라이버나 커널 자체 내부 함수)에서 과부
하가 형성되게 되면, 커널 내에서 외부 클럭을 가지고 와서 내부 소프트클럭
으로 전환하는 함수의 실행에 지연이 발생할 수 있으며, 결과적으로는 시간
업데이트의 지연(drift) 현상이 발생하게 됩니다.
지연된 시간을 기반으로 date & time은 비 정확한 시간을 가질 수 있게 됩니다.
또한 배터리에 의존하는 시스템 클럭은 배터리의 수명으로 인하여 클럭의 작
동에 지장을 받을 수 있습니다. 때문에 Out-Of-Box Time(Absolute Time)을 보
장받기 위하여 NTP와 같은 네트웍 타임 소스를 사용할 수 있습니다. NTP를 사
용하더라도 시스템에서는 drift가 발생할 수 있으나, NTP는 발생되는 drift를
최소화도록 유지하도록 함으로써 NTP를 공유하는 서버들간에 시간오차가 적도
록 해줍니다.

오픈솔라리스에서 dia 포팅하기

오픈솔라리스 b64a에서 dia를 포팅해서 사용하는 방법이다. 참고로 본인은 사
용자 쉘로 bash를 사용한다.(리눅스와 호환을 하기 위해서는 사용자 쉘을
bash로 하는 것이 절대적으로 필요하다.)

썬 솔라리스가 Solaris 10 U3까지는 freeware를 포팅하려면 불편한 것들이 많
았었는데 이번에 사용한 오픈 솔라리스 b64a 버젼에서는 놀라운 호환성을 보
였다. 즉, configure & gmake하면 하면 대부분 되었는데 유니코드를 지원하기
위해서 GNU xgettext가 필요했다.
PATH를 다음과 같이 우선 설정한다.
export PATH=/usr/local/bin:$PATH:/usr/sfw/bin

일단 GNU xgettext 소스를 다운 받는다
압축을 푼후 해당 디렉토리로 들어가서,
./configure --prefix=/usr/local
gmake && gmake install

컴파일이 다되면,

root 사용자로, #gmake install 해서 설치해준다.

또 /usr/bin/xgettext를 자꾸 찾을 수 있으므로 /usr/bin/xgettext를 이름을
잠깐 변경해놓고( mv /usr/bin/xgettext /usr/bin/xgettext.org ) 새로 설치
한 GNU xgettext로 링크되도록 한다. ( ln -s /usr/local/bin/xgettext
/usr/bin/xgettext)

설치가 끝나면, dia 소스를 다운 받는다. configure하기 전에 일단 환경설정
을 한다.
솔라리스도 /usr/lib/libintl.* 도 있고, /usr/local/lib/libintl.* 도 있으
므로, LD_LIBRARY_PATH=/usr/local/lib를 환경변수에 일단 등록해준다.

압축을 푼후 디렉토리로 들어가서
./configure --enable-shared --prefix=/usr/local --enable-gnome
--with-cairo --with-gnomeprint LDFLAGS="-L/usr/local/lib -R/usr/local/lib"

한다. python 플러그인을 사용하기 위해서는 --with-python을 지정하면 되는
데, 이때 dia는 python관련 소스를 재 컴파일하려고 시도한다. 불행하게 솔라
리스는 동적 오브젝트만 지원하는 관계로 libpython*.a가 지원되지 않는다.
따라서, 솔라리스에서 python 플러그인을 사용하려면 python도 새로이 받아서
설치해야 한다. 여기서는 python 플러그인을 사용하지 않는 구성을 한다.

configure가 끝나면, 바로 build를 시도한다.

#gmake && gmake install

설치가 끝난후 dia를 실행해서 정상적으로 실행하면 성공적인 포팅 끝.

* 도움이 되셨으면 애드센스 클릭해주는 센스 *