참 놀라운 세상

우선 기본적으로 솔라리스 8에서 정확한 이유는 모르겠지만 jdk 1.7 이상이 설치가 잘 안됐다...

이유는 잘 모르지만 어쨋든.

SunStudio 11설치를 위해 1.6u45를 받아서 설치를 해봤더니 무수한 Exception 에러...

그렇다면 뭐가 문제인고 찾아보니.. 1.4.2 나 1.5 설치를 권장한단다. 1.6.10... 정도였나 12였나

어쨋든 그 이하 버전을 설치 해야 한다는데 안전하게 1.5 버전을 설치 했다.

 sparc jdk 설치를 하려면 32비트와 64비트가 있는데

jdk-1_5_0_22-solaris-sparc.tar.Z - 32비트

jdk-1_5_0_22-solaris-sparcv9.tar.Z - 64비트

두가지를 받아야 한다.

64비트 jdk 설치를 위해서는 32비트를 먼저 설치해야 하는데 처음에 Z 확장자가 뭔가해서 당황했지만..

예전 유닉스 압축 형태란다.

uncompress [파일명] 혹은 gzip 으로 평소에 압축해제 하듯이 압축을 풀면 잘 풀린다.

그 다음 나오는 SUNW 관련 패키지 들이 있는데

SUNW[version]rt

SUNW[version]dev

대충 설명을 읽어보니 두개는 필수 인 것 같다. 더불어 SUNW[version]cfg, SUNW[version]man 등도 같이 설치하자.

나머지 한개 패키지는 아마도 일본어 관련 패키지 인것 같다.

64비트 패키지도 설치

SUNW[version]rtx

SUNW[version]dvx

설치가 정상적으로 끝나면 /usr/jdk/jdk[version] 에 설치가 완료된다.

jdk 버전 확인도 잊지 말자

/usr/jdk/jdk[version]/bin/java -version

/usr/jdk/jdk[version]/bin/java -d64 -version

profile 등록

export JAVA_HOME=/usr/jdk/jdk[version]

export PATH=$JAVA_HOME/bin:$PATH

export CLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib:.:$CLASSPATH

솔라리스 8에는 기본적으로 1.2.2 인가? 로 설치되어 있는데 /usr/bin 에 모든 사용자를 위해 링크를 변경해 놓자.

ln -s /usr/jdk/jdk[version]/bin/java /usr/bin/java

ln -s /usr/jdk/jdk[version]/bin/javac /usr/bin/javac

끝.

압축파일이다.

초기 유닉스 환경에서 사용되던 것인데 이번 Solaris studio 설치를 위해 jdk 설치를 하려 보니

jdk 압축이 .gz, Z 등으로 되어 있었다.

gz 이야 그렇다 치지만 Z는 뭔가 특이한건줄 알았더만 보통 압축파일 이었다... 허허허

기본적으로 압축과 압축해제는 아래와 같다.

compress [파일명]

uncompress [파일명]

하지만 기본적으로 gzip 으로 압축해제가 가능하다.

gzip -d [파일명]

gunzip [파일명]

출처 : http://parkya.tistory.com/469

nslookup 으로 정보수집 및 IP추적

보통 해커들은 웹해킹을 수행하기 전에 정보를 수집 합니다.

그래서 기본적인 방화벽과 서버 보안설정은 필수인데 이것을 안하는 몇몇 기관들이 있어서 이번 시간에는 보안설정을 하는 방법에 대해서 알아 보도록 하겠습니다.

cmd 창에서 nslookup 명령어 입력 후 

server ns.도메인.ac.kr 을 입력해서 IP를 알아 낼 수 있습니다.

문제는 모대학의 경우 관리자가 보안설정을 허술하게 하여 문제가 될 수 있습니다.

물론 이런 정보만으로 해킹을 하는 것은 아니지만 적어도 그런 실마리를 조금이라도 주는 것은 보안적으로 좋지

않다는 것을 말씀 드리는 것입니다.

ls -t 도메인.ac.kr  을 입력하자 이렇게 서버들의 아이피 정보가 쫘~악 뿌려줍니다.

언뜻 보기엔 이걸로 뭘 하나 싶지만.. card 라던지 자세히 살펴보면 무슨업무를 수행하는 서버의 아이피 인지

유추해 낼 수 있다는 점은 자칫 해킹사고로 이어질 수도 있습니다.

특히 haksa (학사) 라고 표기되는 이 서버는 언뜻 생각해 봐도 아마 학사관리 서버.. 즉 성적관리를 담당하는

서버의 ip정보를 손에 넣을 수 있었습니다.

해킹은 크게 3가지 단계로 진행 됩니다.

(1) 정보수집 -> (2) 공격 -> (3) 사후처리: 로그삭제,백도어 설치 

여기서 첫번째 단계인 정보수집에 해당하는 것이 바로 이런 공격 대상의 서버의 아이피 정보를 수집하는

것도 포함 되는 것입니다.

이것을 막기 위해서는 보안관리자가 해당 서버의 도메인 속성에서 영역전송이 초기에는 '아무서버로 전송'

으로 되어 있는데 이것을 영역전송(이름서버 탭에 나열된 서버로만) 으로 변경 하거나 보조 DNS가 있을 경우

그쪽으로 체크를 해주어야 합니다.

이렇게 클릭한번만 해줘도 되는것은 몰라서, 또는 귀찮아서 안하게 되면 이렇게 해커의 표적이 되기 십상입니다.

윈도우7 에서 안되는 경우에는 

set type=all 이라고 옵션을 먹이고 하면 보이는 경우가 있었습니다.

* NMS (Network Management System)  에 대해서 알아 보겠습니다.

NMS는 네트워크 관리시스템을 말하며, 망을 관리하는 시스템 입니다. 대표적인 프로그램으로 솔라윈드(Solawind)가 있습니다. 

NMS는 트레이드 오프가 적용 됩니다.

즉, 편리성이 높아지고 보안성은 낮아지는 것 이런것이 대표적인 트레이드 오프 입니다.

NMS를 하기 위해서는 먼저 SNMP Protocol을 설치 해야 합니다.

- Windows 구성 요소 마법사 에서 '관리 및 모니터링 도구'를 클릭 합니다.

- SNMP(단순 네트워크 관리 프로토콜)을 체크해 주고 확인을 눌러 줍니다.

저기 윈도우 아이콘의 플러스를 눌러주면 해당 아이피의 컴퓨터의 정보를 상세히 볼 수 있습니다.

계정정보 부터 하드웨어에 대한 정보등 해당 PC의 거의 모든 정보를 수집할 수 있습니다.

* VM웨어로 실험을 할때에는 한쪽 컴퓨터에는 솔라윈드가 설치 되어 있어야 하며 다른쪽 컴퓨터는 SNMP Protocol 일 위에 설정처럼 잡아줘야 합니다.

다음으로 통신을 진행하기 위한 보안조건 2가지를 알아보도록 하겠습니다.

(1) CS(Community String)값이 일치 해야 합니다. 

기본값은 보통 public (퍼블릭) 으로 설치 되어 있습니다. 문제는 아마 전세계의 60%가 이렇게 설정 되어 있을

거라는 점입니다. 그러나 보안상 퍼블릭을 사용하면 안됩니다. 다른 CS( Community String ) 값을 사용 해야 합니다. 

(2) NMS System의 IP 주소를 지정해서 사용해야 합니다.

★ 트레이드 오프관계: 편의성이 높아지면, 보안성이 낮아 집니다.

★ UDP : 161번으로 통신을 합니다.

- 서비스에서 SNMP Service 를 클릭합니다.

- 여기 보시면 public가 기본적으로 설정 되어 있는 것을 알 수 있습니다. 이것을 

바꾸어서 설정 해 주셔야 합니다.

- 다음 호스트로부터 SNMP 패킷 받아 들이기 를 클릭 합니다.

원하는 값을 입력 합니다. 물론 여기에 설정하는 CS값(커뮤니티 스트링) 값은 NMS가 설치

되어 있는 관리자의 컴퓨터의 CS값과 일치해야 합니다.

그래서 일종의 암호의 개념으로 볼 수가 있습니다.

그후 솔라윈드로 확인해 보면 설정된 값의 시스템 정보만 확인 할 수 있습니다.

[ ICMP의 2가지 기능 ]

(1) 오류보고 (2) 질의 

[ NETSTAT 정보 ] 

netstat -na

netstat -ra  의 차이를 구별해서 알아야 합니다.

netstat는 네트워크 포트(TCP,UDP) 상태를 확인함으로서 바이러스나 해킹여부를 진단 할 수가 있죠

netstat  의 간단한 옵션을 알아보도록 하겠습니다.

-a :컴퓨터에서 수신되어 활성화 되어 있는 모든 TCP 및 UDP 포트를 표시 해줍니다

-n : 현재 다른 PC와 연결되어 있는 포트번호를 확인 할 수 있습니다 ( IP주소로 화면을 출력 )

- r : 라우팅 테이블 확인 및 연결(Connection) 되어 있는 포트번호를 확인 합니다.

- e : 랜카드에서 송수신한 패킷의 용향 및 종류를 확인합니다. -s 와 같이 사용 합니다.

- s : IP , ICMP, TCP, UDP 프로토콜의 상태를 확인 합니다.

[ 로드밸런서 (Load Balancer) ] 

: 네트워크 트래픽 Packet 들로부터 Application Port 번호를 해석하여 , Application 트래픽 부하 분산 및 우선 

순위를 관리자가 결정하고, 통제 처리할 수 있도록 해서 전체 시스템의 성능과 속도를 향상 시키는 네트워크 

장비 입니다.

[ 로드밸런싱 ]

: 클러스트의 한종류 이며, 1대의 서버 시스템에 대규모로 들어오는 요청을 여러대의 서버로 분산 처리하여

서버부하 및 트래픽 증가등의 단일서버로 인하여 발생 될 수 있는 문제점을 해결하기 위한 '부하분산서비스' 

입니다.

참고는 여러 블로그를 참고했슴

우선 Solaris에서 랜카드 종류마다 약간씩 이름이 다른데 아래와 같다.

Cpu - SPAC

scmin - 1000 baseT

bge    - 1000 baseT 

ce      - 1000 baseT

ge      - 1000 baseSX

hme    - 100  bastT

gfe     - 1000 baseT

Cpu - X86

e1000g - 1000 baseT

elx      - 100 baseT

pcn     - 1000/100 baseT

1. 우선 호스트 이름을 바꾸려면 /etc/hosts 파일을 수정해야 한다.

etc/hosts 파일은 /etc/inet/hosts 파일에 링크되어 있으며 처음에 아마 ReadOnly 일꺼니깐 chmod로 변환해서 수정해주면 되겠다.

맨 마지막 줄에 호스트 고유 정보를 추가해주면 되겠다. 구분자는 tab 키이니 유념바람.

::1    localhost

127.0.0.1        localhost

[호스트 IP]    [호스트 이름]    loghost

2. 그 다음 게이트 웨이 주소 기본 라우팅 주소를 설정해줘야 한다.

/etc/defaultrouter 에 해당 정보를 기록해주면 된다. 없으면 만들면 된다. 딱 한줄만 넣어주면 됨.

[기본 라우팅 주소]

3. 그 다음 넷마스크를 설정해주자.

/etc/netmasks의 맨 마지막 줄에 설정해주면 되는데

해당 IP 주소의 0 주소와 넷마스크를 입력

[해당 아이피 주소 4번째 자리에 xxx.xxx.xxx.0] [넷 마스크]

4. 그 다음 DNS로 사용할 nameserver 정보를 입력.

/etc/resolv.conf

nameserver 168.126.63.1

nameserver 168.126.63.2

domain kns.kornet.net

5. 마지막 dns 설정 /etc/nsswitch.conf 에서 host 엔트리에 dns를 추가해야 한다.

hosts : file dns

자 이제 추가로 하드웨어 네트워크 카드에 ifconfig 정보를 바인딩 해주는 방법인데

위에 했을시 잘 되면 추가로 설정할 필요는 없고 추가적인 팁으로 알아놓자.

plumb는 커널에 특정 네트워크 카드를 연결시킬때 사용한다. unplumb는 연결 해제시 사용.

ifconfig e1000g0 unplumb

ifconfig e1000g0 plumb

up을 이용하면 e1000g0 인터페이스에 특정 ip주소와 netmask를 올려준다.

ifconfig e1000g0 [호스트 IP 주소] netmask [넷마스크 주소] up

인터페이스가 특정 ip와 서브넷을 물고 있으려면 특정 파일을 수정해 줘야 한다.

파일 수정을 안하면 Reboot시 설정한 ip 주소가 사라지니 유의해야 한다.

1. vi /etc/hostname.[인터페이스명] 파일에 호스트 ip 주소 한줄 추가해주면 된다.

[호스트 이름]

라우팅 테이블을 확인해보자

netstat -nr

default라고 되있는 부분이 게이트 웨이 주소다. 게이트 웨이 추가 및 삭제는

route add[delete] defualt xxx.xxx.xxx.xxx

네트워크 관련 설정 파일을 다시 읽어 들이려면

svcadm -v restart svc:/milestone/network:default 네트워크 서비스 재시작

svcadm restart network/physical

솔라리스 10 u10의 경우 telnet과 ssh는 자동으로 설치된다.

하지만 처음에는 root 계정으로 터미널에 접속할 수 없는데 그 이유는 보안문제인지... 어쨋든

ssh와 telnet으로 root를 접속하고자 하면 아래의 3가지를 수정해야 한다.

---------------------------------------------------------------------------

참고 : http://wooriwil.blog.me/20105449038

1. [SSH & sFTP]

# vi /etc/ssh/sshd_config

132 PermitRootLogin yes     // no 에서 yes로 변경

#svcadm restart ssh

2. [Telnet]

# vi /etc/default/login

18 #CONSOLE=/dev/console // 주석 처리

3. [FTP]

# vi /etc/ftpd/ftpusers

5 #root                     // 주석처리

---------------------------------------------------------------------------

그 다음은 gcc를 설치해야 한다.

gcc는 libiconv 에 dependency가 걸려 있어서 libiconv 먼저 설치해야 한다.

해당 사이트에서 관련 패키지 들을 받을 수 있다. (가입해야 됨)

www.sunfreeware.com

Solaris 10의 경우

intel의 경우는 x86/Soraris

Spac의 경우 SPAC/Soraris

구분되어 있으니 잘 확인하고 받자.

gcc를 누르면 Dependencies의 libiconv를 누르고 해당 패키지 먼저 다운 받자.

뭐 시기 마다 다르니.. 일단 이 포스트를 쓸때는 libiconv-1.14-sol10-x86-local.gz 이게 최신임.

운영체제에서 직접 받던 받아서 ftp로 올리던...

어쨋든 적당한 위치에서 압축을 푼다.

gzip -d libiconv-1.14-sol10-x86-local.gz 또는 gunzip libiconv-1.14-sol10-x86-local.gz

그 다음 설치..

pkgadd -d libiconv-1.14-sol10-x86-local

엔터랑 y 잘 눌러서 설치 한다.

만약에 패키지를 한곳에 모으고 싶으면 /var/spool/pkg로 복사해서 설치할 것.

그다음 gcc를 받아 압축을 풀고 설치 한다. gcc-3.4.6-sol10-x86-local.gz

gzip -d gcc-3.4.6-sol10-x86-local.gz

pkgadd -d gcc-3.4.6-sol10-x86-local

만약 gcc를 설치했을 때 이상이 있으면 Solaris 10 설치 CD 패키지에

SUNWarc라는 패키지를 재설치 해본다. 위치는 cdrom/sol_10_811_x86/Solaris_10/Product/SUNWarc 임.

해당 패키지를 /var/spool/pkg로 옮긴 뒤

pkgadd -d /var/spool/pkg로 재설치. 잘 되어 있으면 안해도 됨.

자 그 다음 gcc의 환경 변수를 설정할 차례다.

/etc/profile에 PATH를 등록.

PATH=/usr/local/bin:$PATH 를 추가해주고. env로 확인해봤을시 현재 디렉토리가 PATH로 안 잡혀 있으면 . 추가 해줄것

ln -s /usr/local/bin /usr/bin/gcc 로 모든 사용자가 gcc를 사용할 수 있게 링크 추가.

마지막으로 설치가 잘 되었는지 확인해보려면 간단하게 하나 짜서 컴파일 해보면 된다.

#gcc

gcc : no input files

이렇게 나오면 정상이라고 할 수 있음.

---------------------------------------------------------------------------------------

자 이제 네트워크를 설정해보자.

해당 부분은 다음 글로 대체!

윈도우에서 마우스 우 클릭으로 Context Menu에 현재 폴더에서 cmd 창을 띄우는 방법 3가지를 소개합니다.

1. Shift + 우클릭으로 "여기서 명령 창 열기" 메뉴 이용. (윈도우 기본 제공)

2. 폴더 아이콘을 우 클릭하여 해당 폴더의 위치에서 관리자 cmd 콘솔 창 띄우기.(사용자 특별 설정)

3. 바탕화면에서 우 클릭하여 "c:\user\유저명\Desktop"에서 관리자 cmd 콘솔 창 띄우기.(사용자 특별 설정)

두 가지 방법 모두 regedit 부분을 수정해야 함.

우선 관리자 권한으로 띄우느냐 마느냐에 대한 부분은 선택임

1. Shift + 우클릭으로 "여기서 명령 창 여기" 메뉴 이용

윈도우에서 기본적으로 제공하는 기능입니다.

하지만 굳이 shift를 누르지 않아도 작동하게 하고자 한다면 [HKEY_CLASSES_ROOT\Directory\Backgroud\shell\cmd]의 값 중

Extended 라는 값이 있는데 이 값을 제거해주면 굳이 Shift 안 눌러도 됩니다.

2. 특정 폴더 우 클릭으로 (관리자 권환)으로 콘솔 창 띄우기

2-1. 특정 폴더 우 클릭 후 관리자 권한으로 띄우기 

[HKEY_CLASSES_ROOT\Folder\shell]에서 새로 만들기로 runas 키값을 만들고 그 하위로 command 키 값도 만듭시다.

runas를 클릭하고 기본값의 데이터를 "현 위치에서 관리자 콘솔창 띄우기" 라고 입력해 놓고 (자기 맘대로 입력하셈)

command에서 기본 값은 "c:\windows\system32\cmd.exe /s /k pushd "%V" 라고 입력

2-2. 특정 폴더 우 클릭 후 일반 사용자 권환으로 띄우기

[HKEY_CLASSES_ROOT\Folder\shell]에서 "현 위치에서 콘솔창 띄우기" 라고 키값을 만들고 그 하위로 command 키 값도 만듭시다.

그 다음 command에서 기본 값을 "c:\windows\system32\cmd.exe /s /k pushd "%V" 라고 입력

차이는 runas를 만들고 안 만들고의 차이입니다. (runas 는 관리자 UAC 창이 띄고 안 뜨고의 차이 인듯)

3. 바탕 화면에서 우 클릭하여 (관리자 권한)으로 콘솔 창 띄우기

3-1. 바탕 화면에서 우 클릭으로 관리자 권한으로 띄우기

[HKEY_CLASSES_ROOT\Directory\Backgroud\shell]에서 새로 만들기로 runas 키값을 만들고 그 하위로 command 키 값도 만듬.

runas를 클릭하고 기본값의 데이터를 "현 위치에서 관리자 콘솔창 띄우기" 라고 입력해 놓고 (자기 맘대로 입력하셈)

command에서 기본 값은 "c:\windows\system32\cmd.exe /s /k pushd "%V" 라고 입력

2-2. 바탕 화면에서 우 클릭 후 일반 사용자 권환으로 띄우기

[HKEY_CLASSES_ROOT\Directory\Backgroud\shell]에서 "현 위치에서 콘솔창 띄우기" 라고 키값을 만들고 그 하위로 command 키 값도 만듬.

그 다음 command에서 기본 값을 "c:\windows\system32\cmd.exe /s /k pushd "%V" 라고 입력

특정 폴더에서 만들기와 차이는 키 값의 생성 위치 입니다. Folder 냐 Directory 냐...

굉장히 도움이 될 것 같아서 퍼옴..

출처 : http://cafe.daum.net/oddtip/Jxkw/94?docid=1CBe5Jxkw9420081218175643]

잘 알아놓고 두고두고 써야겠당

AIX에서 사용하는 컴파일러는 기본적으로 xl c/C 인데

xlc는 c Compiler이며 xlC는 C++ Compiler가 되겠다.

리눅스는 gcc/g++ , HP-UX는 cc/aCC 와 매칭되는 컴파일러들인데

해당 시스템에 해당 컴파일러가 어디에 위치하고 설치되어 있는데 그리고 각각 어떠한 Fileset을 가지고 있는지 알아보자

우선 일반적으로 AIX 시스템에는 /usr/bin에 해당 컴파일러들의 심볼릭 링크가 걸려있는데 xlc, xlC 등의 실행은 이곳에서도 실행 시킬 수 있다.

문제는 각각 C/C++ Compiler Fileset이 설치가 되어 있는지 안 되어 있는지 확인하고자 할 때 어떻게 해야 하냐는 건데

우선 일반적으로 바이너리가 설치되는 위치를 살펴보자.

/usr/vac/bin     <- XL C Compiler Binary 설치 위치

/usr/vacpp/bin  <- XL C++ Compiler Binary 설치 위치

각각의 디렉토리에 가보면 xlc, xlc_r, xlC, xlC_r 부터 시작해서 뭐 이상한 바이너리가 잔뜩 있는데...

ls -la 해서 가만히 살펴보면 심볼릭 링크가 되어 있는 것을 따라가다 보면 신기하게도 죄다 xlc로 귀결된다.

어떤 바이너리를 실행시켜도 결국에는 xlc가 실행된다는건데, 이는 AIX의 XL 컴파일러가 내부적으로 실행 시킨 바이너리 파일을 기준으로

다른 전처리 옵션을 타는게 아닌가 싶은데.. 뭐 자세한 동작 원리는 아직 잘 모르겠다.

우선적으로 AIX 시스템의 경우 /usr/lpp에 보면 xlC 부분도 있긴 한데 이는 SW Directory로 해당 소프트웨어의 Description을 확인할 수 있는 뭐... 그런거 같다. 정확하게는 이것도 아직 공부 중임. 어쨋거나 AIX에서 소프트웨어가 설치될때 installp 를 사용하는데 이를 사용하여 설치된 소프트웨어는 /usr/lpp에서 관리된다는 사실 알아놓으면 좋을꺼 깥다.

그렇다면 IBM 공식 홈페이지에 적혀 있는 각각 Compiler의 Fileset을 살펴보자

각각의 Fileset이 현재 AIX 서버 머신에 설치되어 있는지 확인하고자 한다면

lslpp -la | grep [fileset 명] 을 입력해주면 되겠다.

(XL C/C++ V8.0 for AIX 기준)

XL C compiler filesets

The following filesets are included in the XL C compiler.

XL C++ compiler filesets

The following filesets are included in the XL C/C++ compiler.

C++ runtime filesets

The following filesets are included in the IBM XL C/C++ Enterprise Edition V8.0 for AIX compiler installation package, and must be installed with the compiler.

이번엔 AIX... Thread Dump 분석 방법이다.

최근에 발견한 최고의 포스팅.

http://blog.naver.com/bumsukoh/110114573021

안녕하세요. 이번에는 AIX에서 제공하는 Thread 모니터링 관련 툴을 소개하겠습니다.

AIX에서 가장 유용하게 사용할 수 있는 프로세스와 Thread 모니터링 툴로는 ps 명령어입니다.

"왠 ps 명령어 !" 라고 하실 수 있을텐데요.

사실 ps 명령어는 생각보다 굉장히 많은 정보를 제공하고 있습니다. man page를 보시면 더욱 실남나게 느기실텐데요.

그래도 ps 하면 가장 많이 사용하는 명령어가 "ps -ef" 정도겠죠.

AIX에서는 ps 명령어를 통해 Thread 레벨의 정보를 확인할 수 있는 기능을 제공합니다.

Solaris의 prstat이나 HP-UX의 glance처럼 막강하지는 않지만 나름대로 프로세스의 Thread레벨에 대한 정보를 확인하는데는 유용하게 사용하실 수 있습니다.

ps를 통한 Thread 레벨 모니터링 방법은 다음과 같습니다.

# ps -mp [프로세스 IDs] -o THREAD

ps 명령어는 다들 잘 아실테니 옵션부분만 설명하도록 하겠습니다.

- "m" 은 프로세스 뿐만 아니라 Kernel Thread에 대한 리스트를 출력합니다.

"-o" 옵션과 같이 사용하면 다양한 정보를 출력할 수 있습니다.

- "p" 는 프로세스 ID를 설정합니다. ","를 사용하여 여러개의 프로세스 ID를 지정할 수 있습니다.

- "o" 는 Format 지정을 지정합니다. Thread는 "THREAD"로 지정합니다.

다음은 ps -mp 명령어의 출력 결과 예입니다.

위와 같이 프로세스의 전체 정보와 그 밑으로 Thread 별(TID)로 정보가 출력됩니다.

그외 WCHAN, F, TT, BND, COMMA 정보가 있습니다.

자세한 사항은 ps man page나 메뉴얼을 참조하시기 바랍니다.

명령어 결과에서 Thread 상태 항목인 "ST" 부분과 CPU 사용율 항목인 "CP" 부분, 그리고 Thread의 Suspend 횟수 항목인 "SC" 부분을 주의깊게 볼 필요가 있습니다. 그 이유는 성능에 관련된 항목들이기 때문입니다.

위의 항목 중 Thread 상태 항목인 "ST" 부분에는 다음과 같은 상태 코드가 있습니다.

- "O" 는 Nonexistent 상태입니다.

- "R" 은 Running 상태입니다.

- "S" 는 Sleeping 상태입니다.

- "W" 는 Swapped 상태입니다.

- "Z" 는 Canceled 상태입니다.

- "T" 는 Stopped 상태입니다.

Java 프로세스의 경우 대부분이 "R" 또는 "S" 상태입니다.

TID(Thread ID)는 Java Thread dump 분석 시 Java Thread와 매핑하기 위한 key가 됩니다.

이 부분은 차후에 Thread dump 분석 시 설명드리도록 하겠습니다.

그 다음으로는 Solaris와 HP-UX에서 살펴보았던 pstack과 유사한 procstack 명령어입니다.

procstack 은 Solaris와 HP-UX에서 프로세스의 Native Stack을 확인할 수 있듯이 AIX에서 프로세스의 Native Stack을 확인하기 위한 명령어 입니다.

Solaris와 HP-UX에서는 p로 시작하는 프로세스 명령어 대신 AIX에서는 proc로 시작하는 프로세스 명령어가 있습니다. 두 종류가 거의 비슷한 기능을 제공합니다.

자세한 사항은 다음 포스트를 참고하시면 됩니다. (http://blog.naver.com/bumsukoh/110098535739)

명령어 사용법은 다음과 같습니다.

# procstack [프로세스 ID]

출력 결과는 다음과 같습니다.

위와 같이 JVM을 구현한 Native Stack 입니다. Java 1.6(64bit) 버전의 Jeus 서버에 대한 Thread Native Stack 입니다.

각 Thread 별로 tid와 pthread id 에 대한 내용이 출력되며, 여기서의 tid는 위에서 "ps -mp"의 TID와 동일한 값을 나타냅니다.

"ps -mp"의 모니터링 결과 CPU 점유가 높은 Thread에 대해 procstack으로 Native Stack 확인이 가능하게 됩니다. 물론 Java 프로세스의 경우 procstack으로 Java Stack 확인이 불가능하지만 그런데로 도움은 됩니다. 그 이후에 필요하다면 Thread dump(javacore 파일)을 생성하여 Java Stack을 확인할 수 있습니다.

위의 Native Stack은 모두 Java의 SocketInputStream의 socketread() 부분에서 대기중(상태"SLEEP")이며, 최종 Native Stack은 poll() 함수인 것을 알 수 있습니다.

poll()함수는 Thread를 즉시 "SLEEP"시키고 해당 STREAM(파일 FD)에서 Data input event가 감지되면 Thread를 wake-up시켜 데이터를 처리할 수 있도록하는 기능을 하는 함수입니다.

즉, Java의 socket read는 내부적으로 poll() 함수로 구현되었다는것을 알 수 있는 부분입니다.

그 외에 프로세스에 대한 degugging을 위한 dbx나 프로파일 툴인 tprof등을 사용할 수 있습니다.

프로파일 툴인 tprof는 java 기반(java stack 제공)의 프로파일을 할 수 있어 전문적인 프로파일링 툴이 없을 경우 유용하게 사용할 수 있습니다. (tprof 참고 : http://blog.naver.com/bumsukoh/110104594318)

이것으로 AIX에서 유용하게 사용할 수 있는 Thread 관련 명령어에 대해 알아 보았습니다.

다음 포스트에서는 본격적으로 Thread dump에 대한 내용을 설명드리도록 하겠습니다.

어제 엄청난 호우로 많은 지역이 피해를 입은 것 같습니다. 저도 어제 비와 천둥소리로 잠을 설칠 정도 였습니다. 모두들 호우에 피해를 입지 않도록 각별히 신경 쓰셔야 할 것같습니다.

그럼 이만.. 다음에 뵙겠습니다.

너무 좋은 글들... 최근 dump 분석 때문에 골머리 썩고 있었는데 완전 딱 맞는 자료를 발견했다...

http://blog.naver.com/bumsukoh/110114008655

이번 포스트에서는 Thread dump를 분석하기 전에 Thread들에 대한 정보를 확인하기 위한 유용한 OS 툴들에 대한 내용을 다루어 보겠습니다.

각 OS별로 프로세스 및 Thread 레벨로 상태를 확인하기 위한 명령어들을 제공합니다. 멀티 Thread 기반으로 운영체제들이 변해가면서 제공하는 기능들이 생겨나게 되었습니다.

여기서 설명드리는 OS 툴들은 모두 프로세스에 대한 Native Stack 정보를 출력하는 것입니다.

물론 java stack을 볼 수 없지만 문제가 발생한 Thread에 대한 Native Stack 및 Thread ID를 확인할 수 있습니다. 일부 Java Thread dump에서는 Native Thread ID를 통해 해당 Thread를 찾기도 합니다.

첫번째로 Solaris에서 제공하는 명령어에 대해 알아 보겠습니다.

Solaris에서 가장 유용하게 사용할 수 있는 프로세스와 Thread 모니터링 툴로는 prstat 이 있습니다.

prstat은 생각보다 굉장히 강력한 기능을 가지고 있습니다. 프로세스와 Thread의 CPU 자원 사용율 및 메모리 사용율을 알 수 있지만, CPU 사용율에 대한 microstat 정보를 확인 할 수 있어 굉장히 유용합니다.

저의 경우 이 prstat의 microstat정보를 유용하게 활용하여 시스템의 CPU 자원 사용의 문제점을 확인하고 디버깅한 경험이 있습니다.

prstat 명령어 사용법은 다음과 같습니다.

# prstat -L -m -p [프로세스 ID] [refresh interval]

옵션은 다음과 같습니다.

- "-L" 은 Thread 레벨의 정보를 출력합니다.

- "-m" 은 microstat 정보를 출력합니다.

- "-p" 은 모니터링할 프로세스 ID입니다.

- "refresh interval" 은 모니터링 정보 갱신 주기입니다.

다음은 prstat 출력 결과 예입니다.

==============================================================================================

PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID

----------------------------------------------------------------------------------------
24565 mspbpp 0.8 0.1 0.0 0.0 0.0 0.0 99 0.2 198 1 198 0 java/14
24565 mspbpp 0.8 0.1 0.0 0.0 0.0 0.0 99 0.2 198 1 198 0 java/19
24565 mspbpp 0.4 0.1 0.0 0.0 0.0 0.0 99 0.2 198 0 198 0 java/15
24565 mspbpp 0.4 0.1 0.0 0.0 0.0 0.0 99 0.2 198 0 198 0 java/21
24565 mspbpp 0.4 0.1 0.0 0.0 0.0 0.0 99 0.2 198 0 198 0 java/24
24565 mspbpp 0.1 0.0 0.0 0.0 0.0 100 0.0 0.0 2 0 3 0 java/2
24565 mspbpp 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 39 0 39 0 java/8
24565 mspbpp 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 2 0 4 0 java/9
24565 mspbpp 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 0 0 0 0 java/13
24565 mspbpp 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 0 0 0 0 java/12
24565 mspbpp 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 0 0 0 0 java/11
24565 mspbpp 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 0 0 0 0 java/10
24565 mspbpp 0.0 0.0 0.0 0.0 0.0 100 0.0 0.0 0 0 0 0 java/7
24565 mspbpp 0.0 0.0 0.0 0.0 0.0 100 0.0 0.0 0 0 0 0 java/6
24565 mspbpp 0.0 0.0 0.0 0.0 0.0 100 0.0 0.0 0 0 0 0 java/5
Total: 1 processes, 26 lwps, load averages: 0.15, 0.15, 0.14

==============================================================================================

위와 같이 프로세스의 Thread별(LWPID)로 CPU 사용에 대한 상세 정보가 출력됩니다.

다음은 prstat의 수행 결과 항목입니다. (여기서는 CPU에 대한 항목 만 설명합니다.)

이외 TRP, TFL, DFL, VCX, ICX, SCL, SIG 정보가 있습니다.

위의 결과 내용을 추출하여 분석한 결과 그래프(예시)를 살펴 보도록 하겠습니다.

이 그래프는 동일한 어플리케이션에 대해 사용자 수를 높이며 CPU 자원에 대한 사용 추이입니다.

눈여겨 볼 부분은 사용자가 많아 질 수록 SLP와 LCK 부분이 낮아 지며 LAT 부분이 높아 지는 것을 알 수 있습니다. 즉 사용자 량이 많아 처리량이 많아 질수록 초기에 LCK인 user locks (Java에서 object block이겠죠)과 SLP인 sleep (이 sleep도 대기상태입니다)이 높았다가 점점 낮아 집니다. 이는 Thread들이 일을 쉬지않고 열심히 더 하고 있다는 말이겠죠. 그러다 보니 LAT (CPU 할당 대기)가 점점 높아 지게 되는 것입니다.

여기에서 해당 시스템의 총 사용가능한 사용자에 대한 수치를 알 수 있습니다. 사실 이 작업을 할때는 패키지 제품에서 CPU 과부하가 있다는 것을 보여주기 위해 한것입니다. 결론적으로는 패키지의 CPU 과부하 버그를 조치한 경우입니다.

이렇게 prstat은 유용하게 사용할 수 있는 Solaris의 툴입니다.

그 다음으로는 pstack 명령어입니다.

pstack 명령어는 Solaris에서 프로세스의 Native Stack을 확인 할 수 있는 명령어입니다.(HP-UX에서도 사용합니다.)

이 pstack은 Native Stack (C 코드)만 확인 할 수 있습니다. java stack 에 대한 내용을 확인이 불가능하죠. 아예 나오지 않습니다. (Java 버전 1.5 이상에서는 pstack하고 유사한 jstack이라는 명령어가 제공됩니다. java stack을 Thread dump 없이 볼 수 있답니다.)

이러한 pstack은 JVM 내부의 흐름을 파악하기 위한 방법으로 유용하며, JVM의 Bug 같은 경우를 확인할 때 사용되기도 합니다.(사용되는 빈도는 극히 드물지만요..)

명령어 사용법은 다음과 같습니다.

# pstack [프로세스 ID]

출력 결과는 다음과 같습니다.

=============================================================================================

----------------- lwp# 25 / thread# 25 --------------------
ff2cc7f4 lwp_cond_wait (189b848, 189b830, 0, 0)
feb54b78 __1cCosNPlatformEventEpark6M_v_ (189b830, 45754, fed35879, 7c400, 189b800, fee069ec) + 108
fe5df09c __1cNObjectMonitorGEnterI6MpnGThread__v_ (323df0, 230c00, 323e00, fedb2000, 323e00, 1) + 1cc
fe53879c __1cNObjectMonitorFenter6MpnGThread__v_ (323df0, 230c00, 230c00, 2, 18a4678, 230e78) + 358
fec03c60 __1cSObjectSynchronizerKfast_enter6FnGHandle_pnJBasicLock_bpnGThread__v_ (ddbff834, ddbff908, 1, 230c00, 34800, d6a244) + a4
febad568 __1cNSharedRuntimebAcomplete_monitor_locking_C6FpnHoopDesc_pnJBasicLock_pnKJavaThread__v_ (ec450a70, ddbff908, 230c00, fede68e1, 6, fedb2000) + dc
fc055754 * weblogic/socket/SocketMuxer.readReadySocketOnce(Lweblogic/socket/MuxableSocket;Lweblogic/socket/SocketInfo;)Z+337 (line 1954)
fc63b53c * *weblogic/socket/DevPollSocketMuxer.processSockets()V [compiled] +12 (line 184)
fc005868 * weblogic/socket/SocketReaderRequest.run()V+3 (line 58)
fc005868 * weblogic/socket/SocketReaderRequest.execute(Lweblogic/kernel/ExecuteThread;)V+1 (line 84)
fc005d88 * weblogic/kernel/ExecuteThread.execute(Lweblogic/kernel/ExecuteRequest;)V+19 (line 288)
fc005868 * weblogic/kernel/ExecuteThread.run()V+32 (line 224)
fc00021c * StubRoutines (1)
fe561bdc __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_ (fc0001c0, 230c00, 1, d6a230, e11c6fd8, ddbffe78) + 208
fe90aebc __1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4pnRJavaCallArguments_pnGThread__v_ (ddbffe70, d6a234, fee07100, d6a240, ddbffda0, 230c00) + ec
fe5f0adc __1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_ (d6a234, ddbffe6c, ddbffe68, ddbffe64, ddbffe60, fee07100) + 6c
fe603350 __1cMthread_entry6FpnKJavaThread_pnGThread__v_ (dfc33688, 230c00, 54c00, fee07434, fee07100, fee06dd4) + 110
fec2318c __1cKJavaThreadRthread_main_inner6M_v_ (230c00, 16, fedee064, 19, fedb2000, 0) + 48
feb4ccbc java_start (230c00, 234e, fedb2000, fed33c51, 18a4678, fee02a2c) + 22c
ff2c8a20 _lwp_start (0, 0, 0, 0, 0, 0)

=============================================================================================

위와 같이 JVM을 구현한 Native Stack 입니다. Java 1.6 버전상의 Weblogic 10g에 대한 Thread Native Stack입니다.

lwp# 25 / thread# 25 는 Thread의 ID입니다. lwp는 Light Weight Process라 하여 경량의 프로세스라 하여 Thread에 대한 통칭입니다.

이 Thread ID는 이후에 설명드릴 Thread dump에서 thread와 매핑할 수 있는 key가 됩니다.

위의 Thread Stack에서는 Weblogic Executor Thread에서 사용자 요청을 받기 위해 대기중인 것을 알 수있습니다. 그래서 stack의 최종 frame은 "lwp_cond_wait (189b848, 189b830, 0, 0)" 입니다.

그 외에 프로세스 debug를 위한 dbx 나 Solaris의 막강 프로파일 툴인 Dtrace등을 활용할 수 있으나, 굉장히 advanced한 내용으로 많은 지식을 필요로 합니다.

대부분은 위의 내용정도만 아셔도 트러블슈팅하는데 많은 도움이 됩니다.

다음 포스트에서는 "OS 툴을 잘 활용하라 !" HP-UX 에 대해 설명드리도록 하겠습니다.

장마가 끝나니 날씨가 장난이 아니네요. 다시 장마시즌이 점점 그리워지는건 왜일까요 ^^

몸 건강들 하시고 다음 포스트에서 뵙겠습니다.

그럼 이만

살펴보다가 너무 좋은 자료가 있어서 퍼왔다..

출처 : http://blog.naver.com/bumsukoh/110114572973

이전 포스트에 이어 프로세스 Thread 정보를 확인하기 위한 OS 명령어 활용법 그 두번째로 HP-UX에서 제공하는 명령어에 대해 알아 보도록 하겠습니다.

HP-UX에서는 glance로 프로세스에 대한 모든 것을 볼 수 있습니다.

glance 툴은 굉장히 많은 유용한 정보를 제공합니다. 우선 시스템에 대한 전반적인 상태 정보, 프로세스 정보, 네트웍, DISK, 메모리등등.. HP-UX 시스템에 대한 거의 모든 것을 모니터링 할 수 있는 툴이라 할 수 있습니다.

glance에서 java 프로세스와 관련하여 보아야할 주요항목이 프로세스와 프로세스의 Thread, 프로세스 메모리 정보들입니다.

Solaris prstat의 microstat 정보만큼은 아니지만 THREAD에 대한 각종 CPU 사용 정보(System, User, Cswitch, Interrupt, Nice, Nnice, Normal등)를 제공합니다.

이러한 glance는 text 모드와 gui 모드, 그리고 advisor 모드를 제공합니다.

터미널에서 바로 사용할 수 있는 text 모드가 가장 많이 사용됩니다. gui 모드는 X-Window 환경에서 사용하며 여러가지 정보를 각각의 창에서 볼 수 있다는 장점이 있습니다. advisor 모드는 필요한 정보를 특정 시간동안 일정한 간격으로 정보를 남길수 있습니다. advisor 모드는 "HP-UX Glance advisor를 통한 CPU 자원 모니터링 방법" (http://blog.naver.com/bumsukoh/110107086979) 포스트를 참조하시면 될 것 같습니다.

glance 명령어 사용법은 다음과 같습니다.

# glance -j [갱신간격(초)]

저는 개인적으로 "-j" 옵션을 선호합니다. 갱신 간격이 기본이 5초여서 신속한 정보를 보기가 힘든점이 있어 저는 "glance -j 1" 를 통해 1초 마다 갱신하도록 하여 모니터링합니다.

그럼 glance의 프로세스 정보와 Thread 정보를 확인하는 방법에 대해 설명하겠습니다.

=========================================================================================

다음은 glance를 수행 시 첫화면입니다.

상단에 전체적인 시스템 사용율 정보(CPU, Memory, Disk, Network등)가 나옵니다.

그리고 그 아래에 각 프로세스들에 대한 리스트와 간략한 CPU. Memory, Block 정보들이 나오게됩니다(다른 프로세스명과 User ID는 일부러 삭제했습니다.). 여기서는 java 프로세스(pid 9852)에 대한 모니터링을 설명하도록 하겠습니다.

자 그럼 해당 프로세스에 대한 상세 모니터링을 위해 "S" key를 누르고 프로세스 ID를 입력합니다.

그러면 위와 같이 해당 프로세스에 대한 상세정보가 출력됩니다.

보시면 아시겠지만 프로세스에 대한 다양한 정보들이 쭉 출력됩니다. 이러한 정보 중에서 다양한 CPU사용율정보(User, System, Interrupt 등), Memory 사용율 정보(RSS/VSS, Fault 등), Wait Reason 등의 정보를 눈여겨 보시면 좋을것 같습니다. 우선은 수치가 높은 부분은 확인을 해 볼 필요가 있겠죠.

그럼 여기서 각 Thread에 대한 정보를 확인 하기 위해 "G" key를 누릅니다.

위와 같이 각 Thread에 대한 리스트와 함께 CPU, I/O, Priority, Block 정보를 볼 수가 있습니다.

CPU의 경우 현재 사용율과 누적 사용율을 보실 수가 있습니다. 아무래도 누적 사용율이 높으면 일을 많이 하는 Thread라고 판단할 수 있습니다. 그럼 해당 Thread가 무엇인지 확인할 필요가 있습니다. 이렇때 Thread dump를 통해 TID와 매핑하여 확인할 수 있습니다.

위의 그림에서는 6949836 TID가 현재 CPU 사용을 많이 하고 있으며, CPU Time 누적치도 높게 보여집니다. 참고로 CPU Util과 CPU Time의 의미는 다음과 같습니다.

- CPU Util은 해당 모니터링 시간(glance interval이 3초라면 3초동안)동안 해당 Thread가 사용한 전체 CPU 용량(100 * CORE수의 %)에 대한 비율입니다.

- CPU Time은 해당 Thread가 실제로 CPU를 점유한 시간입니다. 보통 CPU의 Scheduling 시간(보통 1 tick이라함)이 10ms이므로 Thread가 한번에 점유할 수 있는 최대 시간은 10ms라고 볼 수 있습니다. 우선순위가 높은 Thread의 경우 CPU 점유 시간이 높을 수 밖에 없겠죠.

더욱 상세한 Thread 정보를 보기 위해서는 "I" key를 누르고 TID를 입력합니다.

위와 같이 해당 TID의 Thread에 대한 상세 정보가 출력됩니다. 프로세스의 상세정보 부분과 거의 유사한 정보들이 출력됩니다.

이렇게 glance를 통해 프로세스에 대한 전반적인 모니터링 방법에 대해 알아 보았습니다.

많은 분들이 glance 라는 툴은 잘아시는데 사용법, 특히 화면 key에 대한 부분을 잘 모르시더라고요.

저도 이러한 key를 모두 알고 있지는 않습니다. 대신 key help 화면을 위한 key는 꼭 기억하고 있습니다.^^ 화면에서 "h" key를 누르게 되면 다음과

같은 help 화면을 보실 수 있습니다.

help key만 알고있으며 필요시 key를 확인하며 사용해도 아무 지장이 없습니다.

추가적으로 프로세스에 대한 Memory 정보와 Open File정보, System call 정보에 대한 화면을 보여드리도록 하겠습니다.

- Memory 정보

프로세스에 할당된 메모리 block들에 대한 메모리 Type, 참조계수, RSS, VSS, 할당 File명등에 대한 정보를 확인하실 수 있으며, 아래에는 프로세스에 대한 유형별(Text, Data, Stack, Shared, Other) 전체적인 사용량이 출력됩니다.

- Open File 정보

프로세스가 Open한 FD(File Descriptor)에 대한 정보가 출력됩니다. 실제 File의 경로와 파일명이 잘 출력되지 않지만 Volumne과 inode정보가 있어 파일을 찾는(find -inum 명령 사용)데는 문제가 없습니다.

- System call 정보

프로세스가 수행시킨 System call 함수에 대한 항목과 그에 대한 정보들입니다.

위에서는 횟수로는 gettimeofday() 함수가 가장 많이 호출되었으며, Elapsed Time은 ksleep() 함수인것을 알 수 있습니다.

해당 프로세스가 시간과 관련된 내용을 많이 처리하는 프로세스인 것을 알 수 있으며, 이 부분이 염려할 수준은 아닌것으로 보여집니다. ksleep()은 프로세스가 SLEEP으로 빠지게 되면 호출되는 함수로 CPU JOB만 수행하는 프로세스는 아니며, I/O등의 BLOCK(임의적일수도 있음)으로 인해 SLEEP으로 빠지는 경우가 있는 것으로 보여집니다.

=========================================================================================

위와 같이 glance를 사용하면 프로세스에 대해 OS가 제공하는 거의 모든 정보를 모니터링 가능합니다.

참고로 glance는 HP-UX의 kernel trace 정보를 활용하여 보여줌으로 굉장히 막강한 기능을 제공합니다.

kernel trace를 위해 caliper나 ktrace등으로 별도로 하지 않아도 어느 정도의 정보는 제공하게 되며 이러한 정보는 시스템을 튜닝 및 trace하는데 상당한 도움이 되는 것이 사실입니다.

Solaris(DTrace)나 AIX(trace, curt등) 을 사용해 보셨다면 glance가 제공하는 실시간적인 상태 정보는 거의 환상이라고 할 수 있겠죠.

그 다음으로는 pstack 명령어입니다.

이 부분은 Solaris의 pstack과 동일하기 때문에 별도로 설명은 드리지 않겠습니다.

Solaris의 ptack 부분 (http://blog.naver.com/bumsukoh/110114008655)을 참고하시면 되겠습니다.

단, pstack은 HP Itanium 에서 사용가능한 명령어입니다.

그외 pfiles, pmap등과 같은 프로세스 관련된 유용한 명령어들이 있습니다만, 여기서는 Java 프로세스와 Thread에 대한 내용에 초점이 두었기에 다루지 않도록 하겠습니다.

(다음 기회에 HP-UX의 프로세스 관련 명령어를 통한 모니터링 방법에 대해 설명드리겠습니다.)

다음은 gdb인데요. 굳이 gdb까지 사용하여 뭔가 트러블슈팅하는 경우는 그렇게 많지 않을 것 같은데요.

알고 있으면 상당히 유용한건 사실입니다. (써먹을 기회가 별로 없어서 그렇지만요 ㅠ.ㅠ!)

자, 그럼 gdb를 어디에 써먹을 것인가? gdb는 Unix 프로세스를 debugging하기 위한 툴입니다.

이 툴은 보통 C 언어의 프로그램을 디버깅하는데 사용됩니다.(물론 C++, Fortran, Ada등도 가능합니다.)

Java 기반의 시스템과 프로그램이 많아지면서 HP-UX에서는 gdb에서 Java에 대한 분석도 가능하도록 하기 위한 기능을 제공하게 됩니다.

Java Unwind LIbrary라고 하는것인데.. 자세한 사항은 "HP-0UX 에서 gdb를 이용해 Java 프로세스 core 분석하기 !!" (http://blog.naver.com/bumsukoh/110112408842) 포스트를 참고하시면 될 것 같습니다.

그 외에 프로세스 프로파일링을 위한 막강 프로파일 툴인 caliper 등을 활용할 수 있으나, 굳이 Java기반에서는 이러한 프로파일링 툴까지 쓸 필요는 없을것 같고, 대신 Java를 위한 프로파일링 툴은 알아둘 필요가 있습니다. 이 부분은 이번 연재의 뒷부분에서 다루도록 하겠습니다.

다음 포스트에서는 "OS 툴을 잘 활용하라 !" AIX 에 대해 설명드리도록 하겠습니다.

그럼 건강하시고 다음 포스트에서 뵙도록 하겠습니다.

AIX에서 각각의 라이브러리 버전을 확인하고자 할 때 어떻게 해야하는지 한참 찾다가 드디어 발견..

컴파일 후 다른 머신에서 실행시 발생하는 동적 라이브러리 버전 때문에 확인해야 할 경우 미리 확인하면 유용할 듯..

--------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------

뭐 대략 이런 에러 .... ㅡㅡ... 산산조각 깨졌네요 허허허

해당 에러가 나올 때는 AIX 라이브러리 셋 을 570+으로 업그레이드 하라는데...

5.3.7.0 이상으로 하라는건가...? 뭐 어쨋든 컴파일한 머신과 라이브러리 버전이 같다면 큰 문제는 없을듯.

근데 어디서 어떻게 라이브러리를 업데이트 받는걸까..

혹시 지나가시다가 아시는 분 생기시면 댓글 달아주시면 정말 감사드릴텐데.. ㅋ

명령어

lslpp -al

옵션은 al 정도만 사용해도 충분하게 다 커버할 수 있는 듯하다 필요하다면 man으로 자세한 내용을 확인하자

아래는 실제로 커맨드시 출력되는 내용들

우선 OSLEVEL을 확인하시려면

#> oslevel -r

5300-04

와 같이 뜨구요.

xlC 컴파일러 라이브러리 파일셋을 보려면

#> lslpp -l xlC*rte

  파일 세트                     레벨  상태       설명
  ----------------------------------------------------------------------------
경로: /usr/lib/objrepos
  xlC.aix43.rte              4.0.2.2  확정됨     C Set ++ Runtime for AIX 4.3
  xlC.aix50.rte             10.1.0.0  확정됨     XL C/C++ Runtime for AIX 5.3
  xlC.rte                     10.1.0.0  확정됨     XL C/C++ Runtime

뭐 요렇게 나오네요..

또한 해당 라이브러리의 파일셋이 어디인지 알고 싶다면 -w 옵션을 사용.

#> lslpp -w /usr/lib/libpthreads.a

  파일                                        파일 세트             유형
  ----------------------------------------------------------------------------
  /usr/lib/libpthreads.a             bos.rte.libpthreads   Symlink

해당 라이브러리의 인스톨 및 언데이트 히스토리를 알고 싶다면 -h 옵션을 사용

#> lslpp -h bos.rte.libpthreads

  파일 세트       레벨      조치         상태         날짜         시간
  ----------------------------------------------------------------------------
경로: /usr/lib/objrepos
  bos.rte.libpthreads
                  5.3.8.0   확정         완료         09/07/09     01:20:56
                  5.3.9.0   확정         완료         10/03/25     14:55:11

이것도 요렇게 친절하게 나옵니다..

-------------------------------------------------------

file [바이너리명]

: 몇 비트 파일인지 확인 할 수 있다.

-------------------------------------------------------

nm 사용법 -> 알아봅시다.

-------------------------------------------------------

- 해석되지 않은 심볼
현상 : ld: 0711-317 ERROR: Undefined symbol: .pow
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
원인 : 심볼을 해석하지 못한 에러는 다양한 경우에 발생할 수 있지만 대부분의 이유는 필요한 파일을 제대로 주지 않은 경우이다.
조치 : 라이브러리에 들어있지 않은 라이브러리 함수를 호출하는 경우 해당하는 함수가 들어있는 라이브러리를 지정해주어야 한다.

- 동일한 심볼을 중복해서 정의할 경우 프로그래밍 에러가 발생.
현상 : ld: 0711-224 WARNING: Duplicate symbol:
.A<int>::f()
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
원인 : 이 경우 링커는 첫번째 심볼 만을 인정하기 때문에 의도하지 않은 결과가 발생할 수 있다. 함수의 이름을 바꾸던가 정적(static) 함수를 사용해야 한다.
조치 : 심볼이 중복되어 똑같이 정의되어 있으므로 -bhalt:5 옵션을사용해서 링커에게 메시지를 보여주지 않도록 해야 한다.
-bhalt 링커 옵션은 링킹 과정 중 지정한 숫자보다 적은 에러메시지가 발생하면 이 메시지를 보여주지 않도록 한다.

- 링킹과정 중 메모리가 충분하지 않을 때
현상 : ld: 0711-101 fatal error, allocation of bytes fail in routine initsymtab_info.
There is not enough memory.
원인 : 대부분 원인은 페이징 공간이 너무 크기가 작거나, 링커명령을 사용한 사용자의 자원제한이 너무 낮아서 발생한다.
조치 : 위와 같은 에러가 발생하면 다음 사항을 체크해보고 가능하다면 페이징 공간을 늘리는 편이 좋다.
1.시스템 내의 가용한 페이징 공간
2.링커를 사용한 사용자가 사용할 수 있는 자원의 제한. 이 상황은 ulimit 명령으로 알아볼 수 있다.

-------------------------------------------------------

-lm

/bin/sh ./libtool --silent --tag=CC --mode=link gcc -g -O2 -Wall -W -D_THREAD_SAFE -o utilities/animate utilities/animate.o magick/libMagick.la wand/libWand.la
ld: 0711-317 ERROR: Undefined symbol: .fmod
ld: 0711-317 ERROR: Undefined symbol: .cos
ld: 0711-317 ERROR: Undefined symbol: .sin
ld: 0711-317 ERROR: Undefined symbol: .pow
ld: 0711-317 ERROR: Undefined symbol: .ceil
ld: 0711-317 ERROR: Undefined symbol: .sqrt
ld: 0711-317 ERROR: Undefined symbol: .cexp
ld: 0711-317 ERROR: Undefined symbol: .exp
ld: 0711-317 ERROR: Undefined symbol: .floor
ld: 0711-317 ERROR: Undefined symbol: .atan2
ld: 0711-317 ERROR: Undefined symbol: .hypot
ld: 0711-317 ERROR: Undefined symbol: .tan
ld: 0711-317 ERROR: Undefined symbol: .log
ld: 0711-317 ERROR: Undefined symbol: .log10
ld: 0711-317 ERROR: Undefined symbol: .acos
ld: 0711-317 ERROR: Undefined symbol: .asin
ld: 0711-317 ERROR: Undefined symbol: .atan
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
make: 1254-004 The error code from the last command is 1.

에러 제거시

You're obviously missing libm.so (or libm.a or libm.sl or whatever the
extension for (shared) libraries is on your system).

You can check config.sh to see if Configure includes -lm in the 'libs='
line

libs='-lbind -lnsl -ldbm -ldb -ldl -lld -lm -lcrypt -lc -lbsd';

if it does, check to see if libm.a is in any of the path's shown for
libs

libdirs=' /usr/local/ppc64/lib64  /lib /pro/local/lib';
libpth='/usr/local/ppc64/lib64 /lib /usr/lib /usr/ccs/lib /usr/local/lib';
libsdirs=' /lib /usr/local/ppc64/lib64';
libld.a /lib/libm.a /lib/libcrypt.a /lib/libc.a /lib/libbsd.a';
libspath=' /usr/local/ppc64/lib64 /lib /usr/lib /usr/ccs/lib /usr/local/lib';

-------------------------------------------------------