솔라리스에서 사용할 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% 이상의 성능을 내는 경우도 있습니다. 따라서 , 안정성에 문제가 없는 지를 확인해보시고 사용하시길 권고 합니다.
2007/12/27
솔라리스용 wxPython 컴파일 및 최적화하기.
2007/12/12
솔라리스 프로세스의 오픈 화일 보는 법
리눅스 사용자들을 보면, 왕왕 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`
2007/12/11
솔라리스 화일 시스템 성능 테스트 스크립트
솔라리스와 같은 유닉스 혹은 유닉스 유사 계열은 주로 서버사이드에서 많이 사용되는 관계로 화일 시스템의 혹독한 테스트를 필요로 하는 경우가 왕왕 있다. 이런 경우를 위해서 다양한 화일 시스템 테스트 툴이 있는데, 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
과 같이 실행함으로써 테스트할 수 있다.
2007/10/30
솔라리스 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이런경우 일단, 가장 쉬운 workaround로는
//
// 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% 가 증가하는 경우에는 캐쉬 테이블의 크기가 부족해지는 경우가 대부분입니다.
/etc/system에 튜닝을 하실 필요가 있습니다. 단 메모리가 충분이 있어야 합니다.
튜닝 대상이 되는 시스템 변수는 ncsize이며, ufs_ninode라는 변수의 상위 개념에 해당합니다.
일단 현재 사용되는 값을 확인하기 위해서는 다음과 같은 방법을 사용합니다.숫자를 확인하셨으면 다음과 같이 필요한 만큼의 숫자를 결정하신 후 /etc/system에 입력합니다.
# echo "ncsize/D" | mdb -k
ncsize:
ncsize: 129700
set ncsize= 1042865
또한, 디렉토리 나열을 느리지 않은데, 화일 /O(데이타를 읽거나, 쓸때)가 느리다고 판단이 되는 경우에는set segmap_percent=25
다음과 같은 시스템 변수의 튜닝을 할 필요가 있습니다.
segmap_percent
설정 이전에 먼저 보는 법은 다음과 같습니다.
# echo "segmap_percent/D" | mdb -k
segmap_percent:
segmap_percent: 12
확인이 되었으면, 다음과 같이 설정을 하되, 너무 큰 값을 설정하지 않도록 주의 합니다.
이 설정은 커널이 I/O를 위해서 많은 메모리를 사전 할당하도록 하므로, 메모리 사용에 커다란
영향을 주게 됩니다.
와 같이 튜닝하시고 테스트후 조정하는 과정을 거쳐야 합니다.
상황에 따라서는 위 두개의 튜닝을 동시에 진행할 수 있습니다. 그럴 수록 커널 메모리의 상태를 잘 이해하고 있어야 합니다. 참고로 커널이 사용하는 메모리의 상태를 보기 위해서는 다음과 같은 명령어를 사용할 수 있습니다.
#echo "::memstat" | mdb -k ; 솔라리스 9이후 부터 가능. 메모리가 큰 장비에서는 오래 걸림.
참고로 솔라리스 10의 ZFS를 사용하면 UFS가 가지는 위와 같은 문제가 근원적으로 발생하지 않습니다.
2007/10/29
프로세스의 서비스 종료 방법
솔라리스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
2007/08/20
솔라리스에서 성능 향상을 위한 컴파일
솔라리스에서는 다양한 형태의 성능 개선 방안이 있습니다.
사실 컴퓨팅 환경에서는 너무나 많다보니, 일일히 언급하기도 어렵습니다만,
일반적으로 간과되는 것 중 하나는 애플리케이션을 개발할때 사용했던 시스템
과 컴파일러와의 조함입니다.
솔라리스는 새버젼에서 조차 옛버젼에 대한 이진 화일 호환을 유지하다 보니,
구형 플랫폼을 위해서 컴파일된 이진 화일을 그대로 새 플랫폼으로 가져와서
(복사해서) 실행해도 전혀 문제가 없다 보니 간혹 새 플랫폼에 맞추어 컴파일
되어 있지 않은 경우가 왕왕 있습니다.
만약, 기존에 사용하던 플랫폼이 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의 경우 먹지
않으므로 적용되지 않습니다.
김봉환/
2007/08/13
솔라리스에서 애플리케이션 코어 분석( 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
2007/08/08
솔라리스에서 고성능 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
이 파라메터는 일회성 접속이 많은 '웹' 과같은 서버를 동작시키는 경우에도 필수적입니다.
2007/08/02
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
2007/07/24
솔라리스 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
2007/07/20
솔라리스 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을 추가할 수 있습니다.
김봉환/
2007/07/16
솔라리스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 폰트를 복사하게 되면 데스크탑 환경용 폰트
는 물론 일반 애플리케이션에서도 해당 폰트를 참조할 수 있게 된다.
2007/06/29
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를 공유하는 서버들간에 시간오차가 적도
록 해줍니다.
2007/06/11
오픈솔라리스에서 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를 실행해서 정상적으로 실행하면 성공적인 포팅 끝.
* 도움이 되셨으면 애드센스 클릭해주는 센스 *
2007/06/05
Solaris 10 network Tuning Parameters(수신 시스템)
수신시 packet loss가 발생하는 이유는 대개
- 수신자가 충분한 버퍼를 가지고 있지 못하거나,
- 수신측의 인터럽트가 CPU에 의해서 충분히 잘 처리되지 않거나,
- 수신측에서 수신 큐에 도착한 데이타를 페치하는 과정에서 딜레이가 있거나 하는 경우입니다.
위의 기준으로 봤을때 튜닝의 요소는 다음 세가지에 해당합니다.
1) 충분한 버퍼를 확보하기 위해서
tcp_conn_req_max_q ; Anonymous access에 대한 Queue를 늘립니다.
tcp_conn_req_max_q0 ; DoS 가 아닌 접속 요청에 대한 큐를 늘립니다.
tcp_max_buf ; 이 값이 대표적으로 중요합니다.
tcp_time_wait_interval ; 접속이 끝난후 안정 종료하는데 걸리는 시간입니다. 이값이 길면 다음 접속이 어렵습니다. 이 값이 해당이 있는 지는 잘 모르겠습니다. 매 송신시 별도 접속을 하는 경우에만 사용하세요.
tcp_recv_hiwat ; 주로 수신을 받아야 하는 경우 중요합니다. ftp client 등
tcp_xmit_hiwat ; 수신과 함께 송신이 많은 경우 필요 합니다. 주로 서버의 경우.
를 조정할 필요가 있습니다.
조정의 예)
#ndd /dev/tcp tcp_conn_req_max_q 2048
#ndd /dev/tcp tcp_conn_req_max_q0 2048
#ndd /dev/tcp tcp_time_wait_interval 3000
#ndd /dev/tcp tcp_recv_hiwat 1048576
#ndd /dev/tcp tcp_xmit_hiwat 1048576
#ndd /dev/tcp tcp_max_buf 1048576
2) CPU interrupt 처리를 잘 하기 위해서는
set ip:ip_squeue_fanout=1 ; 여러 cpu를 활용합니다. set ip:tcp_squeue_wput=1 ; NIC 개수보다 CPU 개수가 훨씬 많으면 설정하는 것이 좋습니다.(option)하나씩 적용해서 테스트해보시려면 2) -> 1) -> 3)순으로 테스트하시고, 3번은 앞에까지 했는데 효과가 없는 경우에만 사용하세요.
3) 패킷 처리 지연시간을 기본에서 0ms로 줄이려면 필요합니다. set ip:ip_squeue_wait=0 ; steam queue에서 packet drain시 지연 시간을 줄입니다.
썬의 나이아가라 시스템(일명 CMT)을 위한 튜닝을 하는 것이라면 2)번을 설정하는 것이 매우 중요합니다.
2), 3)은 /etc/system 에 변경사항을 추가해야 하며, 1)은 live로 파라메터를 변경할 수 있는 항목이므로 script화 하거나 SMF화 해서 사용하는 것이 좋습니다. 수시로 값을 변경해서 테스트할 수 있겠죠. /etc/system에 적용하는 것도 여전히 사용은 됩니다.
2007/05/28
Solaris 10 x86 IO tuning(ufs)
솔라리스10의 x86 버젼은 x86의 역사적인 이유(?)로 인하여, IDE 디스크를 사
용하는 경우에는 디스크의 모든 성능을 제대로 낼 수 없도록 되어(?)있기 때
문에 다소 튜닝할 필요가 있습니다. 솔라리스의 IDE 디스크는 기본적으로 physical device <-> ATAPI driver(SCSI HBA emulation) <-> sd(scsi disk) 와 같은 통신 방식을 사용하는데, 맨 하부의 물리적 디스크와 ATAPI 사이에서 데이타 전송시 사용하는 기본 블럭의 개수가 56으로 되어 있는데, 이 블럭을 128로 변경할 필요가 있습니다.
즉,
tunefs -a 128 /dev/rdsk/c1d0p0
tunefs -a 128 /dev/rdsk/c1d1p0
...
이 튜닝은 ufs에만 해당하면 zfs 인 경우에는 해당하지 않습니다. 또한, 이 옵션은 SATA와 SAS 디스크의 경우에는 해당되지 않습니다.
동시에 동시 전송 블럭의 수를 늘렸기 때문에 물리적인 디스크와 사용하게될 버퍼의 크기는 1M(=1048576)으로 설정할 필요가 있습니다. 다음과 같이 설정 하도록 합니다.
maxphys는 상당히 오래된 커널 변수인 관계로 최신 디스크나 어레이등을 사용 할 때는 반드시 사용하는 것이 좋습니다.
#echo "set maxphys=1048576" >> /etc/system
설정하고 재부팅이 필요합니다. 이 튜닝은 상위 화일 시스템과 상관없이 사용 하는 것이 좋습니다.
아울러, 솔라리스에서 제공하는 잉여 화일 시스템 서비스인 UFS용 access time 기록 기능을 정지시키게 되면, 화일 수가 많은 환경(web, bbs, cache ...) 에서 상당한 성능 향상을 볼 수 있습니다.
mount -F ufs -o remount,noatime /disk partition
위의 ufs 튜닝 옵션들은 모두 서비스 제공중에 설정가능한 것이나, 최적의 성능을 위해서라면 화일시스템을 새로이 구성하시는 것이 바람직합니다(구성할 때 위 옵션들을 사용하도록 구성)
* 유용하셨으면 AdSense 살짝 클릭해주세요 *
2007/05/07
Solaris 10 Update 3의 새로운 기능 "Secure by Default"
솔라리스 10 U3에는 여러 가지 기능이 좋아졌습니다만, 그 중에서 가장 독특한 기능의 변화는 Trusted Extension이라는 보안 강화 기능인데 , 이는 미군에서 요구하는 보안 등급을 준수하게 해주는 보안 강화 기능으로 매우 강력한 보안 구성 환경으로써, 실제로 이 기능을 구성하여 가동할 수 있다면, 웬만한 보안 소프트웨어는 거의 살 필요가 없을 정도입니다. 이 기능은 다소 복잡한 구성에 대한 이해가 필요하니 별도로 소개를 하도록 하겠습니다. 아울러, 솔10 U3는 보안을 위해서 "Secure By Default"라는 기능을 추가로 제공하고 있는데, 이름 자체에서 언급하는 의미 그대로를 해석하면, "기본적으로 보안이 강화된" 이라고 볼 수 있겠습니다.
최근에 솔라리스는 소스가 공개되었고, 이에 따른 솔라리스 소스의 문제점을 찾아내어 해킹을 시도하는 사례가 증가될 수 있다는 판단이 있었던 것 같습니다. 리눅스가 오픈 소스하에서 이런 문제때문에 상당히 괴롭힘을 당해왔다는 것을 생각해보면 쉽게 이해할 수 있는 일이라 할 수 있겠습니다.
따라서, 솔라리스10 U3(11/2006) 설치 과정중에는 Secure By Default를 하겠냐고 물어보는 과정이 있습니다. 이 과정에 동의를 하고, 구성을 사용하게 되면 솔라리스는 외부 접속을 위해서 ssh를 제외한 모든 원격 접속 서비스인 telnet, XDMCP 서비스등을 모두 disable 되거나 localhost에게만 허용하도록. 때문에, 그 이전 버젼을 사용하던 사용자들은 이런 내용의 사전 습득이 없으면 다소 당황할 수 있게 됩니다.
현재 모드를 알 수 있는 방법은 없으며, 관련 네트웍 서비스를 모두 오픈(사용할 수 있도 하거나) 혹은 '제한'을 두는 두가지의 명령만 있습니다. 사용법은
#/usr/sbin/netservices open
혹은
#/usr/sbin/netservices limited
입니다.
솔라리스10을 정상 설치후 telnet 서비스나 혹은 X-window 관련 서비스가 정상적으로 작동이 되지 않는다면 위의 명령어로 서비스를 오픈한 후 사용하시면 됩니다.
그러나, 안정적인 보안환경을 유지 및 사용하기 위해서는 ssh를 사용할 것을 강력하게 권고합니다.
ssh와 함께 제공되는 데이타 암호화 툴을 이용함으로써 tcp spoofing이나 암호 데이타의 snooping등을 원천적으로 봉쇄할 수 있게됩니다.
복수개의 노드를 관리하기 위해서 rlogin, rsh, rcp등을 사용하던 사용자들도 ssh기반의 환경으로 옮겨서 사용할 것을 강력하게 권고합니다.
| 기능 | unsecured 방법 | Secured 방법 | |
| 터미널 접속 서비스 | telnet | ssh | |
| 원격 실행 | rsh,rexec | ssh | |
| 화일 전송 | rcp,ftp | scp, sftp | |
| X Window 접속 및 Display | XDMCP | ssh -X |
솔라리스의 ssh 서비스를 이용하기 위해서는 일반 사용자를 만들어서 사용하는 것이 바람직합니다. 솔라리스10 Update3에서 설치과정중 "Secure By Default"를 사용하는 것으로 설정하게 되면, 서버는 telnet으로 접속할 수 없게 되어 ssh를 사용해야 하는데, 솔라리스 개발자가 잠깐 졸았는지(?) ssh 서버가 root access를 허용하지 않도록 구성되어 있습니다.
따라서, root로 접속할 수 없게 되는 것이죠. 때문에, 설치를 정상적으로 한후, console(콘솔)에서 ssh 서버가 root로 로그인하는 것을 하용하도록 구성을 변경할 필요가 있습니다. 구성하는 법은 다음과 같이 합니다.
#cp /etc/default/login /etc/default/login.backup
#sed 's/CONSOLE=/#CONSOLE=/g' /etc/default/login > /tmp/login
#cp /tmp/login /etc/default/login
#cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
#sed 's/PermitRootLogin no/PermitRootLogin yes/g' /etc/ssh/sshd_config > /tmp/sshd_config
#cp /tmp/sshd_config /etc/ssh/sshd_config
#svcadm restart ssh
와 같이 실행함으로써 ssh가 root로 로그인할 수 있도록 할 수 있습니다.
X-window 로그인이나 애플리케이션 화면출력(Display)를 위해서는 클라이언트쪽(PC나 노트북등)에 X server를 지원하는 운영체제(solaris, linux)를 사용한다면 ssh -X를 쉽게 사용할 수 있습니다. 만약, windows나 Mac을 사용하는 경우라면 ssh -X를 이용한 원격 디스플레이를 지원하는 X server 에뮬레이션 소프트웨어를 사용하셔야 합니다.
* 도움이 되었으면 Google AdSense 살짝 찍어주세요 *
2007/04/26
Solaris10 x86의 제한(limit) 점
Max # of CPUs
오픈 솔라리스에 있는 코드를 보면 알 수 있는 것인데,
amd64 아키텍쳐, 즉 64비트 x86 머쉰에서는 64개의 CPU를 운영하도록 '하드코
딩'되어 있으며 x86 아키텍쳐, 즉 32비트 x86 머쉰에서는 32개의 CPU를 운영
하도록 '하드코딩'되어 있다.
여기서 amd64 아키텍쳐라고 해서, amd CPU만 해당되는 것이 아니다. Intel의
64bit 머쉰(EM64T)들도 솔라리스는 amd64로 인식하기 때문에, 인텔의 64비트
지원 CPU들의 시스템에서는 최대 64개의 CPU를 구동할 수 있도록 되어 있다.
CPU가 이렇게 많다고 해서 성능이 다 좋아지는 것은 아니며, 하부의 하드웨어
아키텍쳐가 이만한 CPU를 잘 동작시킬 수 있는 구조를 가지고 있어야 한다.
Max # of RAM
메모리는 2TB RAM을 운영할 수 있는 스팍용 솔라리스와는 달리 x86용은 128GB
를 운용할 수 있도록 되어 있는데, 이는 CPU 구조와 밀접한 관련이 있다. 스
팍은 완전한 64bit 가상 메모리 지원 구조를 가지고 있는 반면에 x86은 그렇
지 않기 때문에 그런 것이다.
Maximum threads
예전 x86용 솔라리스에서는 최대 8000개의 스레드밖에 만들 수가 없었으나 지
금은 스레드의 개수는 완전히 시스템이 장착하고 있는 메모리의 양에 의해서
만 제한이 된다. 스레드의 기본 stack(스택) 사이즈는 1M 씩 잡혀 있으므로,
32비트의 스레드를 3만개(30,000)를 만들려면 30GB의 스택 공간이 필요하게
되므로 실행이 불가능해진다. 따라서, 이렇게 많은 스레드를 구동시키려면 기
본 스택 사이즈를 매우 작게 만들어야 한다.
2007/04/18
Dtrace와 Java : Java를 Dtrace로 해부해볼 수 있을까?
어려운 문제다.
Dtrace를 만든 3명중에 한명인 Adam 조차도 Java를 dtrace로 완전히 분해하는 게
어렵다고 했다. 그나마 JDK 1.6이후에는 솔라리스10의 jvm이 dtrace probe를 지원하게
되서 훨씬 쉬어지긴 했지만 말이다.
JDK 1.6.x이전에는 java vm은 운영체제 입장에서 독립적인 프로세스이면서, 내부적으로는 자바 애플리케이션을 실행시켜주는 머신 역할을 하고 있어서, 실제로 jvm의 애플리케이션인 java의 thread들은 운영체제에서 정확하게 무슨일을 하는지 알 수가 없었다. 그래서, jvm을 블랙박스라고 했다.
안에 어떤일이 일어나는 지 모르는 상태에서 jvm의 그 자체에 대고 dtrace 때려봐야 코끼리 뒷다리 만지기식이었다고 할까.
그래서, JDK 1.4.x와 JDK 1.5.x에서는 jvm이 구동될때 dtrace로 추적이 가능하도록 하는 플러그인 모듈(JNI 인터페이스)이 오픈 소스 프로젝트로 개발되었는데 성능이 워낙 후지다 보니, 욕을 많이 먹는 와중에 jdk 1.6.x이 발표되면 흐지 부지 되었다.
기술적으로는 운영체제에서는 jvm 안에 있는 thread의 움직임을 알수가 없으므로 jvm이 내부의 움직임을 외부 운영체제에 알려주어야만 운영체제에서는 무언가를 해볼 수가 있다. 그나마, 솔라리스8에서 솔10이 되면서 Thread-to-LWP 할당 방식이 1-to-1이 되었기 때문에 Java Thread를 운영체제에서 어느 정도 알게 된것이 발전이라면 발전이다. (참고 pstack, jstack)
JDK 1.5이전에는 java vm이 dtrace에게 java application에 대한 정보를 제공해주기 위해서 java vm이 제공하는 JNI기반의 DVMTI라는 trace interface module을 통하여 dtrace를 지원했었다. (https://solaris10-dtrace-vm-agents.dev.java.net/ )
그러나, 이 모듈은 매우 심각한 오버헤드로 많은 자바 개발자들로 하여금 경악을 금치 못하게함으로써 많은 사용이 되지 않았으며, 그러는 동안에 jdk 1.6 버젼에서 외부 trace를 위한 기능이 대폭적으로 개선되면서, 솔라리스용 java vm 1.6.x는 특별히 자체적으로(natively) dtrace를 지원하도록 개선되었다.
쉽게 얘기하면, jdk 1.6대를 사용해서 무언가를 돌리고 있으면, 애플리케이션은 자동적으로 java vm의 hotspot vm의 dtrace probe(검사 포인트)를 실시간 등록을 해준다. 때문에, java vm 로딩은 다소 좀 늦어지긴 했으나, 모니터링 부분에서는 혁신적인 발전이 제공되었다고 볼 수 있다.
아울러 jdk 1.6이 제공하는 trace 확장 기능은 java vm 자체의 모니터링 및 trace 기능도 발전시켜서 아주 화려한 툴들을(jconsole, demo/JTop, demo/MemoryManagement) 기본적으로 제공함에 따라 dtrace의 필요성이 많이 감소해졌다. ㅡ.ㅡ;
그러나, 여전히 dtrace는 막강하다. 애플리케이션의 문제를 논리적으로 접근하는 힘은 어디에서나 강할뿐 아니라, jdk 1.6이 java thread의 procedure에 대한 정보를 모두 노출함으로써 dtrace적 논리로 문제의 근원을 찾아볼 수 있게 되었다.
freemind라는 java application을 jdk 1.6으로 실행했을 경우이다.
bash-3.00# pgrep freemind
2352
bash-3.00# ptree 2352
2352 /bin/bash /usr/sfw/bin/freemind.sh ; freemind를 실행시켜 주는 쉘이다.
2356 /usr/bin/java -Dfreemind.base.dir=/usr/sfw/lib/freemind-bin-max-0.8.0/ ; 실제 freemind.jar의 java pid
bash-3.00# dtrace -l | grep 2356 | c++filt | tail
62071 hotspot_jni2356 libjvm.so jni_UnregisterNatives UnregisterNatives-entry
62072 hotspot_jni2356 libjvm.so jni_UnregisterNatives UnregisterNatives-return
62073 hs_private2356 libjvm.so void VM_CMS_Initial_Mark_Operation::doit() cms-initmark-begin
62074 hs_private2356 libjvm.so void VM_CMS_Initial_Mark_Operation::doit() cms-initmark-end
62075 hs_private2356 libjvm.so void VM_CMS_Final_Remark_Operation::doit() cms-remark-begin
62076 hs_private2356 libjvm.so void VM_CMS_Final_Remark_Operation::doit() cms-remark-end
62077 hs_private2356 libjvm.so HashtableEntry*Hashtable::new_entry(unsigned,oopDesc*) hashtable-new_entry
62078 hs_private2356 libjvm.so void RuntimeService::record_safepoint_begin() safepoint-begin
62079 hs_private2356 libjvm.so void RuntimeService::record_safepoint_end() safepoint-end
62356 hotspot_jni2925 libjvm.so jni_GetCharArrayRegion GetCharArrayRegion-return
( c++filt는 Sunstudio를 설치해야만 제공되는 C++ name demangle 유틸이다./opt/SUNWspro/bin에 있다. )
java가 pid 2356의 dtrace probe를 위한 probe point를 대거 등록해놓은 것이 보인다.
이중에서 hotspot_jni2356으로 등록되어 있는 probe statement가 중요하다. 실제 자바 애플리케이션의 함수들을 trace할때 필요하다.
그러면, freemind라는 java application을 dtrace할 수 있게 되었다. dtrace 해주자. ;-)
#dtrace -n 'hotspot_jni2925:::{@[probefunc]=count()}' ; pid 2925가 가장 일을 많이 하는 함수를 프린트하자.
...
jni_IsAssignableFrom 1984
jni_GetSuperclass 2388
jni_IsInstanceOf 3818
jni_SetIntArrayRegion 27688
jni_GetByteArrayElements 28064
jni_MonitorEnter 28064
jni_MonitorExit 28064
jni_ReleaseByteArrayElements 28064
jni_GetArrayLength 36036
jni_GetPrimitiveArrayCritical 38248
jni_ReleasePrimitiveArrayCritical 38248
jni_CallStaticVoidMethod 69000
이렇게 나온다. 햐! 엄청 좋아졌다.
그러면, 가장 많은 부하를 제공하고 있는 jni_CallStaticVoidMethod()가 호출되는 어떤 경우일까? 또 dtrace해주자 !
#dtrace -n 'hotspot_jni2925::jni_CallStaticVoidMethod:CallStaticVoidMethod-entry{@[jstack()]=count()}'
몇가지 경우가 나타났다.
...
libjvm.so`jni_CallStaticVoidMethod+0xe0
libmawt.so`X11SD_Lock+0x43
libawt.so`Java_sun_java2d_loops_MaskFill_MaskFill+0x96
sun/java2d/loops/MaskFill.MaskFill(Lsun/java2d/SunGraphics2D;Lsun/java2d/SurfaceData;Ljava/awt/Composite;IIII[BII)V*
sun/java2d/pipe/AlphaColorPipe.renderPathTile(Ljava/lang/Object;[BIIIIII)V*
sun/java2d/pipe/DuctusShapeRenderer.renderPath(Lsun/java2d/SunGraphics2D;Ljava/awt/Shape;Ljava/awt/BasicStroke;)V*
sun/java2d/pipe/DuctusShapeRenderer.fill(Lsun/java2d/SunGraphics2D;Ljava/awt/Shape;)V*
sun/java2d/pipe/PixelToShapeConverter.fillRect(Lsun/java2d/SunGraphics2D;IIII)V*
sun/java2d/S
0xfc6a5f35
0xfc402e9d
0xfc6dc99d
0xfc402e9d
0xfc402e9d
0xfc758abc
0xfc76f8fa
0xfc402c71
0xfc402c71
0xfc6947fe
0xfc782015
0xfc75cc9c
0xfc402e9d
0xfc402e9d
0xfc402e9d
0xfc768b95
0xfc699bb4
0xfc5cd0d0
0xfc402c71
0xfc402e9d
0xfc402e9d
0xfc402e9d
0xfc402e9d
0xfc400202
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x1a3
libjvm.so`__1cCosUos_exception_wrapper6FpFpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v2468_v_+0x27
libjvm.so`__1cJJavaCallsEcall6FpnJJavaValue_nMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x2f
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4pnRJavaCallArguments_pnGThread__v_+0xc1
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x7e
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0xd2
libjvm.so`__1cKJavaThreadRthread_main_inner6M_v_+0x4c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x196
libjvm.so`java_start+0xd3
libc.so.1`_thr_setup+0x52
libc.so.1`_lwp_start
1006
libjvm.so`jni_CallStaticVoidMethod+0xe0
libmawt.so`X11SD_Unlock+0x1d4
libawt.so`Java_sun_java2d_loops_MaskFill_MaskFill+0x20c
sun/java2d/loops/MaskFill.MaskFill(Lsun/java2d/SunGraphics2D;Lsun/java2d/SurfaceData;Ljava/awt/Composite;IIII[BII)V*
sun/java2d/pipe/AlphaColorPipe.renderPathTile(Ljava/lang/Object;[BIIIIII)V*
sun/java2d/pipe/DuctusShapeRenderer.renderPath(Lsun/java2d/SunGraphics2D;Ljava/awt/Shape;Ljava/awt/BasicStroke;)V*
sun/java2d/pipe/DuctusShapeRenderer.fill(Lsun/java2d/SunGraphics2D;Ljava/awt/Shape;)V*
sun/java2d/pipe/PixelToShapeConverter.fillRect(Lsun/java2d/SunGraphics2D;IIII)V*
sun/java2d/S
0xfc6a5f35
0xfc402e9d
0xfc6dc99d
0xfc402e9d
0xfc402e9d
0xfc758abc
0xfc76f8fa
0xfc402c71
0xfc402c71
0xfc6947fe
0xfc782015
0xfc75cc9c
0xfc402e9d
0xfc402e9d
0xfc402e9d
0xfc768b95
0xfc699bb4
0xfc5cd0d0
0xfc402c71
0xfc402e9d
0xfc402e9d
0xfc402e9d
0xfc402e9d
0xfc400202
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x1a3
libjvm.so`__1cCosUos_exception_wrapper6FpFpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v2468_v_+0x27
libjvm.so`__1cJJavaCallsEcall6FpnJJavaValue_nMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x2f
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4pnRJavaCallArguments_pnGThread__v_+0xc1
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x7e
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0xd2
libjvm.so`__1cKJavaThreadRthread_main_inner6M_v_+0x4c
libjvm.so`__1cKJavaThreadDrun6M_v_+0x196
libjvm.so`java_start+0xd3
libc.so.1`_thr_setup+0x52
libc.so.1`_lwp_start
1010
그 중에 가장 호출 빈도수가 높은 경우는 위와 같다. (c++filt를 쓰지 않아서 mangling 되어있다)
자바가 화면에 새로 그리기 위해서 호출이 많은 것 같다(필자는 자바 전문가가 아니라서 자세히 설명하진 못하겠다. 하지만, 애플리케이션 그래픽 프로그램이고 이벤트를 받지 않으면 별로 하는 일이 없기 때문에 이렇게 나오는게 아닌가 싶다.)
mangling이 답답하다면 demangle 해서 보자.
자바를 아는 자바 전문가들에게는 진짜 필요한 툴이 아닌가 싶다.
참고로, dtrace는 솔라리스10에서만 사용가능하므로, 솔라리스에서만 이렇게 dtrace를 통한 java trace가 가능하다.
문제를 알았다면, 이제 자바 전문가를 불러서 해결해달라고 하자. ㅡ.ㅡ;
Dtrace 활용하기 : Xorg의 버그 finding
오픈 솔라리스를 쓰다보면 확실히 많은 버그에 시달리게 된다. 그나마 썬 솔라리스는 패치도 제공해주고 하니, 가끔씩 패치하면 버그가 줄어드는 것을 볼 수가 있는데, 오픈 솔라리스는 그것도 못하니 새로 깔아야 한단 얘긴데... 참으로 귀찮은 일이 아닐 수 없다.
한편으론 dtrace를 활용하면서 배워보려고 하는 사람들에겐 아주 좋은 환경이 아닐 수 없다.
여기 저기 떠돌아다니는 버그들 덕분에 dtrace 활용율을 늘릴 수는 있을 테니 말이다.
오늘은 firefox 2.0 영문 브라우저를 쓰고 있는데, 미디어 다음 사이트를 접속만 하면 시스템의 CPU가 버닝아웃될 지경이다.(참고로 내 시스템은 Mobile Athlon 3000+/amd64/2G from Acer )
그래서, dtrace로 Xorg의 어느 부분이 문제인지 찾아보고 싶어졌다. 평소에는 바뻐서 그냥 죽였다 다시 살리곤 했는데, 오늘은 시간이 좀 되는 관계로...
prstat상으로 보면, 나는 브라우저를 사용하고 있는데, CPU 점유는 Xorg가 거의 다하고 있다.
Xorg가 누구 때문에 이렇게 열심히 일하는 지를 보려면 /usr/demo/dtrace/whofor.d를 이용하면
쉽게 추측할 수 있다(물론, prstat만 가지고도 어느 정도 예측할 수 있지만 말이다)
#dtrace -s /usr/demo/dtrace/whofor.d
firefox-bin sleeping on Xorg:
value ------------- Distribution ------------- count
2048 | 0
4096 | 5
8192 |@@@@@@@@@@@@@@@ 6102
16384 |@@@@@@@@@@@@@ 5053
32768 |@@@@ 1703
65536 |@@@ 1057
131072 |@ 587
262144 |@ 358
524288 |@ 199
1048576 |@ 288
2097152 |@ 244
4194304 | 148
8388608 | 43
16777216 | 15
33554432 | 16
67108864 | 2
134217728 | 0
챠트상으로 나온 결과를 보면, firefox가 잦은 횟수로 Xorg에 CPU를 빼앗기고 있다.
firefox가 Xorg에 부담을 주고 있는 것으로 예측할 수 있다.
그럼 Xorg의 뭐가 잘못되서 CPU를 이렇게 쓰는 것인지 궁금해졌다. '도대체 Xorg를
왜 이렇게 만들어가지설라무네...'
일단 CPU를 과점하고 있는 Xorg의 pid로 pstack을 찍어봤다. 흠...
Xorg의 문제인지, shared library의 문제인지가 궁금하기 때문이다.
_XSERVTransSocketRead() 란 함수가 불려지고 있는 것으로 나오는데 이게 어느 라이브러리에 붙어있는 것인지 알 수가 없다.
dtrace를 떴다.
#dtrace -b 2g -n 'pid$target::_XSERVTransSocketRead:entry{ustack();}' -p `pgrep Xorg`
Xorg의 문제이다.
여기서 _XSERVT* 함수가 불릴때만 문제가 되는 것인지 확정할 수 없다. 일단 Xorg가 문제임으로 Xorg의 Sub function들을 대상으로 호출 회수 상태를 알고 싶어졌다. 다시 dtrace를 했다.
#dtrace -n 'pid$target:Xorg::entry{@[probefunc]=count()}' -p `pgrep Xorg`
Xalloc, Xfree를 과도하게 하고 있는 것이 보인다.
이 함수는 둘다 Xorg의 메모리 할당과 해제를 위한 함수인데, 뭐 때문에 메모리 할당 해제를
이렇게 심하게 반복할까? 궁금해진다. 다시 dtrace를 돌렸다.
Xalloc이 호출될때, 어떤 stack을 경유해서 Xalloc() 이 호출되는 지 궁금하기 때문이다.
이 부분을 알게 되면, Xorg의 문제의 중요 부분을 알 수 있겠다 싶다.
# dtrace -n 'pid$target:Xorg:Xalloc:entry{@[ustack()]=count();}' -p `pgrep Xorg`
Xorg`Xalloc
libxaa.so`XAAInitPixmapCache+0x72b
Xorg`localAllocateOffscreenArea+0x63
Xorg`xf86AllocateOffscreenArea+0x36
libxaa.so`XAACreatePixmap+0x226
Xorg`ProcCreatePixmap+0xff
Xorg`Dispatch+0x2d2
Xorg`main+0x4de
Xorg`_start+0x7a
1932
Xorg`Xalloc
libxaa.so`XAAValidateGC+0x305
Xorg`damageValidateGC+0x40
Xorg`ValidateGC+0x1a
Xorg`ProcPolyFillRectangle+0x101
Xorg`Dispatch+0x2d2
Xorg`main+0x4de
Xorg`_start+0x7a
3281
Xorg`Xalloc
Xorg`miRegionCreate+0xf
Xorg`miComputeCompositeClip+0x98
libfb.so`fbValidateGC+0x63
Xorg`miBSCheapValidateGC+0x89
libxaa.so`XAAValidateGC+0x63
Xorg`damageValidateGC+0x40
Xorg`ValidateGC+0x1a
Xorg`ProcPolyFillRectangle+0x101
Xorg`Dispatch+0x2d2
Xorg`main+0x4de
Xorg`_start+0x7a
3382
Xorg`Xalloc
Xorg`AddResource+0xda
Xorg`ProcCreateGC+0xbd
Xorg`Dispatch+0x2d2
Xorg`main+0x4de
Xorg`_start+0x7a
4191
Xorg`Xalloc
Xorg`CreateGC+0x1a
Xorg`ProcCreateGC+0xa5
Xorg`Dispatch+0x2d2
Xorg`main+0x4de
Xorg`_start+0x7a
4191
Xorg`Xalloc
Xorg`miRectsToRegion+0x13
Xorg`miChangeClip+0x35
Xorg`miBSCheapChangeClip+0x27
libxaa.so`XAAChangeClip+0x43
Xorg`damageChangeClip+0x44
Xorg`SetClipRects+0xe1
Xorg`ProcSetClipRectangles+0x87
Xorg`Dispatch+0x2d2
Xorg`main+0x4de
Xorg`_start+0x7a
4949
Xorg`Xalloc
Xorg`SetClipRects+0x3f
Xorg`ProcSetClipRectangles+0x87
Xorg`Dispatch+0x2d2
Xorg`main+0x4de
Xorg`_start+0x7a
4949
Xorg`Xalloc
libxaa.so`XAADoGlyphs+0x5b7
libxaa.so`XAAGlyphs+0x95
Xorg`damageGlyphs+0x337
Xorg`CompositeGlyphs+0x13e
Xorg`ProcRenderCompositeGlyphs+0x347
Xorg`ProcRenderDispatch+0x26
Xorg`Dispatch+0x2d2
Xorg`main+0x4de
Xorg`_start+0x7a
6327
다시 dtrace를 돌렸다.
흠... 끝의 다섯개의 스택에 관심이 갔다. 특히, 마지막 스택을 유념하게 보게된다.
그 앞의 스택의 호술 횟수(4949)보다 50%이상 많다(6327)
ProcRenderCompositeGlyphs() Glyphs 이라.. 어라, 이건 폰트 문제인데... Glyphs를 damage()
한후 libxaa에 있는 XAAGlyphs를 다시 호출하느라 메모리를 할당하고 있네...
왜 이러지 미쳤나? xaa 라이브러리는 True type 폰트를 위한 anti-aliasing 라이브러리이다.
firefox가 열려고 시도한 웹페이지에서 지정한 true-type 폰트의 anti-aliasing 때문에
생긴 것일까?
어느 정도 원인은 파악했다. 역시 dtrace다 !!!
그런데, 이걸 어떻게 해결해야 하나...가 고민이다. Xorg를 업그레이드 해야 하나? 솔라리스를 다시 깔아야 하나? 아니면, 옵션 변경으로 할 수 있을까?
여기서부터는 dtrace문제 밖인데... 웬지 dtrace가 해결까지 해줬으면 좋겠다는 꿈을 꿔본다.
"도움이 되셨으면 구글 애드센스 살짝 눌러주는 센스를 기대하겠습니다"
2007/04/16
윈도우즈 비스타에서 NTFS 크기 변경
비스트가 설치되어 있는 시스템에서 솔라리스를 설치하려면 일단 디스크 파티
션을
재조정할 필요가 있습니다. 포맷되어 있지 않은 디스크 영역이 있다면 모를까
일반적으로는 시스템이 공급될때 부터 하나의 디스크 혹은 볼륨으로 구성되어서
오므로, 솔라리스나 리눅스를 설치하고자 한다면, 파티션을 새로이 조정해야
하는데
윈도우즈 비스타이전에는 파티션 매직이나 Gparted와 같은 제3의 유틸리티 혹은
오픈 소스 유틸리티를 이용하여 다시 파티셔닝을 했었습니다. 그러나, 비스타
에서는
파티션을 재조정할 수 있는 툴을 자체적으로 제공합니다.
이 툴을 이용하여 100% 사용하고 있는 NTFS 파티션을 10GB 줄이게 되면, 10GB
규모의
빈공간의 디스크가 나오게 되는데, 이공간에 솔라리스를 설치하면 됩니다.
NTFS 확장이나 축소를 위한 툴은 Control Panel(제어판) -> System and
Management(시스템 관리) -> Administrative Tools(관리툴) -> Computer
Management(컴퓨터 관리) -> Disk Management(디스크 관리)
에서 접근 가능합니다. 사용방법 별로 어렵지 않으며, 마우스 우측 버튼을 통
하여 쉽게 해결할 수 있습니다. 명령어로도 가능합니다.
원래 소스는 아래 페이지를 참고하세요.
http://www.bleepingcomputer.com/tutorials/tutorial133.html
* 도움이 되셨다면 위 Google Adsense 살짝 클릭해주는 센스 기대합니다. *
2007/03/15
2007 US New Summer Time & Patch
미국의 Daylight(aka. 서머타임)의 변경일이 금년 2007년부터 앞당겨졌습니다.
예전에는 4월인가 5월부터 였는데, 금년부터는 3월에 하는 것으로 바뀌었습니다.
따라서, global time을 참고해야할 서버들은 시간이 맞지 않게됩니다.
여러 고객들에게 매우 중요한 일이므로 필히 아래 url을 참고하신 후
관련 패치를 받으시라고 전달해주시기 바랍니다.
Time의 변경은 단순 소프트웨어 뿐 만 아니라, 하드웨어(시스템 컨트롤러등)에도
치명적인 변화를 요하므로 고객들로 하여금 꼭 사전에 Patch Management Time을
잡아서 필요한 Patch를 모은후 Patch할 수 있도록 유도하시기 바랍니다.
솔라리스 10은 122032-04(SPARC) 122033-04(x86)를 설치해야 합니다.
패치를 받을려면 당연히 썬의 서비스 계약이 이루어져 있어야 합니다.
solaris 및 썬 관련 모든 TimeZone 패치 정보는
여기를 참고하세요.
http://www.sun.com/bigadmin/hubs/dst/
2007/02/23
Solaris 에서 read_vtoc()의 사용
솔라리스는 예전의 작은 디스크들의 레이블로 SMI label을 사용했었는데요. 스토리지가 커지면서 LUN 기반의 스토리지나 zfs와 같은 초대형 스토리지 및 화일 시스템을 지원하기 위해서 EFI label이라는 것이 새로 생겼습니다.
read_vtoc() 시스템 콜은 예전에 SMI로 label 되었거나 새로운 Label인 EFI중의 2**32-1보다 작은 블록을 가진 디스크에 대해서만 사용할 수 있게되어 있으며, 새로이 EFI label을 사용하는 스토리지나 디스크의 경우에는 efi 인터페이스를 사용해서 vtoc를 읽어오도록 되어 있습니다.
즉, read_vtoc를 사용했다면 대신에 efi_alloc_and_init(3EXT)을 사용해서 소스를 새로이 변경하셔야 합니다.
코딩은 다음의 소스를 참고해서 작성하시면 될 겁니다. 다음은 i_label의 디스크를 읽는 방법을 담은 소스(opensolaris.org에서 퍼옴)입니다. 참고삼아, 작성하시길 바랍니다.
아래 소스 코드에는 없습니다만 efi_alloc_and_read로 vtoc를 리턴받으신 후 사용하신 후에는 반드시 efi_free()로 해당 vtoc를 free 시키셔야 합니다. 참고 man efi_alloc_and_read.3ext
도움이 되셨다면 위의 광고 한번 살짝 클릭해주세요.
630 * readefi(): Read a partition map.
631 */
632 static int
633 readefi(int fd, char *name, struct dk_gpt **efi)
634 {
635 int retval;
636
637 if ((retval = efi_alloc_and_read(fd, efi)) >= 0)
638 return (0);
639
640 switch (retval) {
641 case (VT_EIO):
642 return (warn(name, "Unable to read VTOC"));
643 case (VT_EINVAL):
644 return (warn(name, "Invalid VTOC"));
645 case (VT_ERROR):
646 return (warn(name, "Unknown problem reading VTOC"));
647 }
648 return (retval);
649 }
/* 내부 작동 원리 : libelf */
203 efi_alloc_and_read(int fd, struct dk_gpt **vtoc)
204 {
205 int rval;
206 uint32_t nparts;
207 int length;
208
209 /* figure out the number of entries that would fit into 16K */
210 nparts = EFI_MIN_ARRAY_SIZE / sizeof (efi_gpe_t);
211 length = (int) sizeof (struct dk_gpt) +
212 (int) sizeof (struct dk_part) * (nparts - 1);
213 if ((*vtoc = calloc(length, 1)) == NULL)
214 return (VT_ERROR);
215
216 (*vtoc)->efi_nparts = nparts;
217 rval = efi_read(fd, *vtoc);
218
219 if ((rval == VT_EINVAL) && (*vtoc)->efi_nparts > nparts) {
220 void *tmp;
221 length = (int) sizeof (struct dk_gpt) +
222 (int) sizeof (struct dk_part) *
223 ((*vtoc)->efi_nparts - 1);
224 nparts = (*vtoc)->efi_nparts;
225 if ((tmp = realloc(*vtoc, length)) == NULL) {
226 free (*vtoc);
227 *vtoc = NULL;
228 return (VT_ERROR);
229 } else {
230 *vtoc = tmp;
231 rval = efi_read(fd, *vtoc);
232 }
233 }
234
235 if (rval < 0) {
236 if (efi_debug) {
237 (void) fprintf(stderr,
238 "read of EFI table failed, rval=%d\n", rval);
239 }
240 free (*vtoc);
241 *vtoc = NULL;
242 }
243
244 return (rval);
245 }
