Solaris의 버추얼 머신 : 버추얼박스(virtualbox)의 성능

썬에서는 얼마전에 독일계의 이노텍(innotek)이란 회사를 인수한 적이 있다. 이노텍이란 회사는 가상머쉰의 일종인 '버추얼박스(virtualbox)'라는 오픈 소스 소프트웨어를 제작 공급하던 업체이다.

썬은 버추얼 박스를 인수한 이후 솔라리스에서도 아주 잘 동작하도록 꽤 수고를 드린 것 같다. 최신 버젼으로 제공된 1.62 버젼은 솔라리스상에서 설치되어서 오픈솔라리스, 솔라리스10(u5+)은 물론 윈도우즈 계열과 리눅스 계열의 게스트 운영체제를 지원할 뿐 아니라 해당 게스트 운영체제들의 성능을 향상시켜주는 게스크 에디션을 제공하면서 게스트로 솔라리스, 윈도우즈,리눅스, FreeBSD, OS/2를 가장 퍼펙트하게 제공하는 최초의 솔라리스용 버추얼 버신이라고 할 수 있겠다.

버추얼 벅스는 Type2 (Hosted VM)기반의 버추얼 머신으로 다른 운영체제위에서 동작하며 호스트 운영체제도 가장 많은 운영체제를 지원한다.(솔라리스, 리눅스, MacOSX, 윈도우즈)

위키에 있는 버추얼 머신 비교를 보면 쉽게 이해가 간다.
이노텍의 버추얼박스는 흥미로운 탄생 역사를 가지고 있는데, 버추얼박스 소스의 초기 코드(오픈소스가 되기 이전)가 마이크로소프사에 라이센스되었는데, 이로 인해서 마이크로소프트의 Virtual PC 2007과 거의 흡사하다고 할 수 있겠다. 유일하게 다르다면 VirtualPC 2007은 호스트운영체제로 윈도우즈만 지원하는 반면 VirtualBox는 주요 데스크탑운영체제 대부분을 지원한다는 것이 다르다면 다르겠다.


버추얼 박스 1.62에서 WindowsXP를 돌리는 모습니다. vbox guest edition을 설치한 이후에 화면 크기의 조절이라던가 마우스 모드의 자동전환, 성능등이 획기적으로 개선되어 있다.



vbox 1.62/Solaris 상에서 PC Wizard 2008을 다운받아서 시스템 정보를 확인하는 스샷이다. 흥미로운 것은 CPU를 부정확하게 잡아내고 있는데 이유는 확실하지 않다. 감지하는 코어의 개수(운영체제 입장에서 CPU)는 한개만 나온다. 이것은 버추얼 박스가 한 CPU만 지원하기 때문에 그런 것으로 보인다. (맨 끝 PC Wizard 결과 화면 참고)

솔라리스에서는

vaio-solaris:~ 499
$kstat cpu_info:1:cpu_info1:brand
module: cpu_info instance: 1
name: cpu_info1 class: misc
brand Intel(r) Core(tm)2 Duo CPU T7500 @ 2.20GHz

로 나오는 반면

버추얼 박스내의 PC Wizard에서는 Core2 Duo E4500@2200Mhz CPU로 감지했다. Core2 Duo면 두개의 코어인데 하나만 나오는 것도 다소 흥미롭다.

그렇다면 성능은 어떨까 ?


정말 흥미로운 성능 결과가 아닐 수 없다. 위 결과화면에서 보이는 두개의 선중 노란선이 버추얼박스의 성능 결과인 반면 파란색 선은 참고용 시스템의 결과이다. 참고용 시스템이라는 것이 보이는 데로, Core2 Duo E6600@2.4Ghz 시스템인데, 이 시스템과 비교해서 프로세서 스피드가 훨씬 뛰어나다.
메모리는 훨씬 성능이 좋다. 메모리 캐쉬는 같은 것으로 나오고. 믿을 만한 데이타인가 ? 살짝 호기심이 발동한다. Core2 Duo T7500의 native 성능 결과를 추후 올리겠다.

비디오는 당연히 느릴 것으로 예상했었고 상당히 느린 것으로 나왔다.
우측 위 태스크 관리자의 부분 이미지가 보인다. CPU가 하나만 보이는 것이 인상적이다. Core2 Duo인데, 반코어만 보인다는 얘기다. 웃긴다.

PC wizard를 수행하게 되면, 버추얼박스는 최대의 부하를 사용하게 되는데, 이와중의 솔라리스 상황을 살펴보았다.


VirtualBox가 거의 하나의 코어를 다 쓰는 것을 볼 수 있다. 49% 정도로 나오는 것은 CPU 두개짜리 박스에서 하나를 다 쓰게 되어서 나타나는 평균값이다. 그 다음에 나오는 프로세스는 Xorg인데, 3D 데스크탑을 쓰면서 버추얼 박스에서 Video Test를 하는 와중에 캡쳐한 것이라 다소 높게 나왔다. 비데오 테스트가 아닌 경우에는 이렇게 높게 나오지는 않았다. Direct3D 테스트는 실패한 것으로 보인다.

버추얼 박스는 흥미롭게 하나의 코어만을 게스트 운영체제에 보여주면서, 자신은 여러개의 스레드를 통하여 시스템의 모든 프로세스를 나름 공평하게 사용하는 것을 볼 수 있다.그렇지만, 전용 스레드 하나가 주로 사용되는 것은 어쩔 수 없다.

솔라리스에서 버추얼박스를 사용하면서 게스트 운영체제에 과부하를 걸게 되면 호스트 운영체제인 솔라리스가 뛰엄 뛰엄 실행되는 모습이 일부 보이는데, 이런 현상을 없애기 위해서 윈도우즈에서는 할 수 없는
프로세서 전용 할당과 같은 자원 분배기능을 할 수가 있다.

Core 2 Duo T7500 은 두개으 코어를 가지고 있는데 하나의 코어에서만 VirtualBox관련 프로세스들이 실행되게 하면, 나머지 프로세스에서 솔라리스가 실행되므로 매우 안정적으로 운영할 수 있다.


이렇게 하기 위해서는 프로세서 셋을 다음과 같이 구성한다.
#psrset -c 1 1
; 1번 프로세서 셋을 구성하면서 해당 셋에 1번 코어를 할당한다. 기본적으로 0번, 1번 두개의 코어가 있다.

vaio-solaris:~ 503
$psrinfo -v
Status of virtual processor 0 as of: 06/12/2008 18:03:09
온라인(06/11/2008 09:05:27 이후).
The i386 processor operates at 2200 MHz,
and has an i387 compatible floating point processor.
Status of virtual processor 1 as of: 06/12/2008 18:03:09
온라인(06/11/2008 09:05:33 이후).
The i386 processor operates at 2200 MHz,
and has an i387 compatible floating point processor.
vaio-solaris:~ 504
$psrinfo
0 온라인 06/11/2008 09:05:27 이후
1 온라인 06/11/2008 09:05:33 이후

다음은 버추얼박스가 실행하고 있는 중의 mpstat 결과이다.
$mpstat 1
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 16 0 2 466 190 709 79 36 24 0 13563 19 2 0 79
1 13 0 5 249 194 567 73 36 27 0 12633 18 4 0 78
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 1 563 210 1388 317 118 163 0 58609 30 18 0 52
1 7 1 0 573 154 1326 354 107 159 0 71542 27 26 0 48
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 2 0 0 557 200 1530 387 141 71 0 62210 27 17 0 56
1 0 0 14 583 181 1579 365 153 95 0 85893 32 22 0 45
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 0 608 206 1969 487 159 28 0 55857 25 15 0 60
1 2 0 0 625 214 1394 305 151 35 0 83667 28 21 0 51
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 4 0 555 214 1378 307 176 74 0 73979 25 18 0 57
1 1 1 0 572 198 1381 313 177 66 0 70269 24 18 0 58
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 13 0 663 303 1376 241 160 59 0 36496 20 14 0 66
1 0 6 8 550 168 1366 357 150 53 0 90470 27 30 0 44

두개의 CPU(core)가 나름 골고루 사용되고 있음을 볼 수 있다.

앞서 만든 processor set을 이용해서 1번 코어에 버추얼 박스를 바인딩 시킨 결과이다.

#psrset -b 1 `pgrep -d" " VirtualBox`
process id 4565: was not bound, now 1
process id 4560: was not bound, now 1

$mpstat 1
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 16 0 2 466 190 710 80 36 24 0 13761 19 2 0 79
1 13 0 5 250 194 568 73 36 27 0 13141 18 4 0 78
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 7 0 0 427 204 874 22 0 5 0 2141 4 1 0 95
1 0 0 14 371 108 324 65 0 6 0 165138 35 24 0 40
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 0 402 198 800 21 0 0 0 2220 6 2 0 92
1 0 0 0 367 102 321 71 0 0 0 162599 36 25 0 40
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 0 425 212 987 131 0 0 0 19995 8 2 0 90
1 0 0 0 370 99 313 74 0 1 0 160760 35 27 0 38
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 1 416 200 843 18 0 4 0 1895 4 2 0 94
1 0 0 14 382 112 313 71 0 6 0 167351 36 25 0 38
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 0 404 204 770 20 0 0 0 2015 6 3 0 91
1 0 0 0 362 101 318 67 0 0 0 161251 36 24 0 41
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 0 409 204 910 20 0 0 0 2333 5 1 0 94
1 0 0 0 379 106 320 76 0 0 0 165813 36 25 0 39


psrset으로 프로세서 관리를 한 이후에는 CPU 하나만 주로 쓰이고 있음을 알 수 있다. 이때에 버추얼 박스에서는 부하가 거의 걸려있지 않은 상태이고 아래 상태는 인터넷 익스플로러 하나에서 네이버 초기 화면을 열었을 때의 현상이다. 1번 코어가 거의 모두 사용되고 있음을 알 수 있다. 네이버는 '플래쉬'로 상당한 부하를 끊임없이 만들어 내고 있기 때문에 위와 같은 결과가 보임을 알 수 있다. 이때 0번 코어도 상당한 사용율 보이는 데 이 이유는 인터넷을 접근할때 발생하는 네트웍 트래픽의 처리를 0번 코아에서만 하기 때문에 접속 초기시 0번 코어를 상당히 사용하는 모습을 보여준다. psrset으로 cpu를 운영체제 기본 풀에서 분리해내면 그 프로세서서는 운영체제가 사용하지 않기 때문이다.


$mpstat 1
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 16 0 2 466 190 711 80 36 24 0 13753 19 2 0 79
1 13 0 5 251 193 567 73 36 27 0 13322 18 4 0 78
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 7 0 4 480 238 2132 540 0 153 0 7480 31 9 0 60
1 0 7 5 746 241 1065 497 0 219 0 55495 26 63 0 11
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 4 637 310 2125 544 0 196 0 7388 31 10 0 59
1 1 26 8 827 339 1149 529 0 245 0 31525 18 74 0 8
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 1 526 248 2628 736 0 382 0 8992 40 13 0 46
1 0 9 14 866 300 1186 576 0 491 0 18527 18 82 0 0
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 27 24 4 616 329 2632 699 0 261 0 8153 36 13 0 51
1 0 6 0 786 182 1078 522 0 376 0 42941 25 75 0 0
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 0 501 234 2258 695 0 390 0 8409 35 12 0 53
1 0 4 0 691 142 1052 497 0 508 0 44347 23 74 0 3
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 1 1 0 477 226 2151 554 0 287 0 7807 28 9 0 63
1 0 2 14 632 152 955 419 0 424 0 62805 27 63 0 10

솔라리스10 (Solaris Community Edition)에서 MySQL 사용하기

솔라리스10에는 MySQL이 이미 들어있습니다. 굳이 다운받아서 컴파일하고 할 필요가 없다는 뜻이죠.
솔라리스 10에서는 MySQL을 활성화하기 위해서는 다음과 같이 하면 됩니다.

일단 mysql의 그룹과 사용자를 만듭니다. 이렇게 하기 위해서는 수퍼유저나 혹은 사용자 생성 권한을 가지고 있어야 합니다.

1. 그룹의 생성
#/usr/sbin/groupadd mysql
2. 사용자의 생성
#/usr/sbin/useradd -g mysql -d /var/mysql mysql
;여기서 -d /var/mysql 옵션에 유념해야 합니다. -d 옵션은 사용자 디렉토리를 설정하기 위해서 필요한 옵션인데 mysql man 페이지에는 이 부분이 빠져 있는데, 이 옵션이 빠져 있으면 후에 서비스를 활성화할때(svcadm 이용) 오류가 발생합니다.
3.MySQL 데이타베이스 디렉토리의 소유권한을 설정합니다.
#chown -R mysql:mysql /var/mysql
4.서비스를 구동합니다.
#svcadm enable mysql:version_50
혹은
#svcadm enable mysql
5.구동된 서비스가 정상적으로 작동하는 지 확인합니다.
#svcs -xv mysql
svc:/application/database/mysql:version_50 (MySQL RDBMS)
상태: online(2008년 6월 11일 수요일 오후 05시 48분 06초 이후)
참조: man -M /usr/share/man -s 1 MySQL 5.0.45
참조: http://dev.mysql.com/docs
참조: /var/svc/log/application-database-mysql:version_50.log
영향: 없음
6. mysql 클라이언트로 접속해봅니다.
#mysql -u root
mysql> show databases;

이렇게 해서 성공적으로 솔라리스에서 MySQL을 활성화했습니다. 쉽죠? ^__^

이후에는 MySQL 설정을 해야 합니다.
MySQL root 패스워드도 설정해야 하고, 필요한 데이타 베이스를 생성해야 합니다.
이 부분은 MySQL 관리자 영역이므로 여기서는 언급하지 않습니다.

개발자를 위한 선택 : 솔라리스

예전에 마이크로소프트웨어에 기고했던 글입니다.

:+: 하늘을 닮은 호수 :+: » Open Solaris 1

솔라리스에서 사용자 패스워드 변경 자동화(expect 이용)

예전에는 CGI를 이용하여 웹 프로그래밍을 할 때에는 사용자 암호를 웹 인터페이스로 받아서 변경해야 하는 경우가 있었습니다.
지금의 웹 인터페이스에서는 JavaScript나 python등 고수준 스크립팅으로 백엔드 인증 서비스와 연결하는 방법을 대부분 사용합니다만 예전에는 /usr/bin/passwd라는 유틸리티를 이용하여 /etc/passwd 화일을 기반으로 패스워드를 변경해야 했습니다.

오늘날에는 필요하지 않을 듯 하고, 실제로 보안상의 이유로 권고되지 않습니다만, 간혹 시스템 마이그레이션이나 자동 업데이트를 배치로 처리하기 위해서 대량의 사용자의 암호를 임의로 변경하기 위해서는 여전히 이러한 스크립트를 통한 passwd 변경이 필요하게 됩니다.

이러한 목적으로 패스워드를 변경하기 위해서 예전에는 쉘스크립트의 표준 입출력을 조정하여 스크립트했습니다만, 솔라리스10에서는 이렇게는 안되는 것 같습니다(방법이 있는 지는 좀더 확인해봐야겠습니다)

어쨌든 오픈솔라리스에는 (솔라리스 Community Edition 03/2008. Opensolaris 05/08과는 다름)에는 expect라는 스탠다드 입출력을 전환하는 유명한 오픈 소스가 들어있습니다. 이 툴을 이용하여 패스워드 변경을 스크립팅할 수 있습니다.
다음은 mkpasswd라는 간단한 expect 스크립트 입니다. 사용방법은 다음과 같습니다.
#mkpasswd user1 oldpasswd newpasswd

#!/usr/bin/expect
#
# mkpasswd by Bonghwan Kim
#

spawn passwd [lindex $argv 0]
set new [lindex $argv 1]

expect "New Password:"
send "$new\r"
expect "Re-enter new Password:"
send "$new\r"
expect eof


mkpasswd를 실행할때 실행 아큐먼트로 구 패스워드와 새 패스워드를 주고 실행하면, 한번에 변경이 가능합니다.
여기서 두가지 중요한 것은 이 스크립트는 root 권한을 가지고 실행이 되어야 하며, 이 스크립트가 실행될때의 locale이 반드시 POSIX 'C' 이어여 합니다. 즉, 터미널에서 실행할때에는 LC_ALL=C;export LC_ALL 혹은 그에 준하는 명령어로 쉘의 로케일을 C로 전환합니다. 그 이유는 로케일이 달라지면 expect가 기대하는 문자열의 값이 로컬라이즈화 되어 스트링이 달라집니다. 예를 들어, ko 혹은 kr_KR.UTF-8으로 되어 있으면 "New Password:"라고 나오지 않고 "새 암호:" 와 같이 물어보기 때문입니다.


일반 사용자가 위와 같은 패스워드를 사용해야 하는 경우에는 위의 스크립트를 사용할 수 없습니다. 일반 사용자 특히 이미 패스워드가 설정되어 있는 경우에는 기존의 패스워드를 물어보는 과정이 추가되기 때문입니다. 일반 사용자가 자기의 패스워드를 자동으로 변경하고자 하는 경우에는 위의 스크립트를 약간 변경하여 다음과 같이 작성하면 작동합니다.

사용법은 LC_ALL=C mkpasswd jac0001 abc123 qwer123 와 같이 실행하면 됩니다.
#!/usr/bin/expect
spawn passwd [lindex $argv 0]
set old [lindex $argv 1]
set new [lindex $argv 2]

expect "Enter existing login password:"
send "$old\r"
expect "New Password:"
send "$new\r"
expect "Re-enter new Password:"
send "$new\r"
expect eof

참고로 실행하고 테스트된 플랫폼은 다음과 같습니다.
solaris:~ 522
$cat /etc/release
Solaris Express Community Edition snv_86 X86
Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 27 March 2008
solaris:~ 523
$expect -v
expect version 5.43.0

오픈 솔라리스와 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