jino

사용중인 포트 번호를 검색하여, 해당 포트를 사용하는 PID 검색

전체
netstat -ano

특정포트
netstat -ano |findstr 34404


해당 프로세스 확인 후 프로세스 종료하기.
tasklist /fi "pid eq "3403"
taskkill /f /pid 3404

혹은 그냥 작업관리자에서 확인 후 프로세스 끝내기

A. 일반 jfs, jfs2의 경우

1. 뭔가 아주 작은 파일들이 다수 존재한다. 필요없다면 지우자.
2. chfs로 파일시스템 사이즈를 늘리자. 그래도 1과 같은 놈들이 존재한다면 공간 낭비....
3. jfs2의 경우는 allow small inode extents? 옵션을 yes로 설정하면 숨통이 트인다. 그러나 aix 5L 이하 버전에서는 접근이 안된다.
4. 기타 방법이 있다면 좀 알려주세요..ㅠㅜ

B. gpfs의 경우

1. 현재 inode 사이즈 확인
mmlsfs /dev/lv_trsysis -i

2. inode 사이즈 증가
mmchfs /dev/lv_trsysis -F 1M

C. cvfs의 경우

해당 공유파일 시스템의 경우는 메타데이터를 스토리지에 별도로 보관하기 때문에, inode값이 무의미하다. 100%가 되어도 파일을 새로 생성하는데 문제되지 않는다. 메타데이터 영역을 충분히 크게 생성해 놓았다는 전제 하에...
자세한 것은 Quantum 엔지니어에게 문의를.




D. 기타 도움이 될만한 inode 관련 developerWorks 링크.
http://www.ibm.com/developerworks/kr/library/au-speakingunix14/index.html

inode는 유닉스 운영체제에서 사용하는 자료 구조로, 파일 시스템 내부에 파일을 유지하는 중요한 정보를 담고 있다. 유닉스에서 파일 시스템을 생성할 때, 수 많은 inode 집합을 생성한다. 일반적으로 전체 파일 시스템 디스크 용량의 대략 1% 정도가 inode 테이블에 할당된다.

종종 사람들은 inode와 inumber를 섞어서 사용한다. 두 용어는 비슷하며, 서로 관련이 있지만 똑같은 개념을 나타내지는 않는다. inode는 자료 구조다. inumber는 실제 inode 인식 번호이므로 inode number나 inumber라고 부른다. inumber는 파일 정보를 담은 중요한 항목일 뿐이다. inode에서 몇 가지 다른 속성은 다음 절에서 설명한다.

inode 테이블은 개별 파일 시스템을 위한 모든 inode 숫자 목록을 포함한다. 사용자가 파일에 접근하려면, 유닉스 시스템은 올바른 inode 번호로 inode 테이블을 탐색한다. inode 번호를 발견하면, 사용자가 내린 명령이 inode에 접근해서 가능하다면 적절한 변경 작업을 진행한다.

예를 들어, vi로 파일을 변경하는 작업을 생각해보자. vi <filename>이라고 입력할 때, inode 숫자를 inode 테이블에서 찾아 inode를 연다. vi 편집 세션 중에서 몇 가지 속성이 변경되며, :wq로 작업을 종료할 때, inode가 닫히며 해제된다. 이런 식으로 사용자 두 명이 같은 파일을 동시에 편집하면, inode가 편집 세션을 연 사용자 ID에 할당되며, 다른 사용자는 inode가 해제되기를 기다려야만 한다.

inode 구조체

inode 구조체는 경험이 풍부한 유닉스 개발자나 관리자에게 상대적으로 쉽게 다가오지만, inode 내부에 대해 잘 모를 경우 깜짝 놀랄 만한 정보를 담고 있을지도 모르겠다. 다음 정의는 유닉스 사용자가 활용하는 inode에 담긴 중요한 정보 몇 가지를 설명한다.

• inode 번호
• stat C 함수에서 사용되는 파일 유형을 이해하기 위한 모드 정보
• 파일 링크 숫자
• 소유주 UID
• 소유주 GID
• 파일 크기
• 파일이 사용하는 실제 블록 개수
• 마지막으로 수정된 시각
• 마지막으로 접근한 시각
• 마지막으로 변경된 시각

기본적으로 inode는 파일의 실제 이름과 파일의 실제 내용을 제외한 파일에 대한 모든 정보를 담고 있다. 전체 inode 구조체는 AIX에서 헤더 파일인 /usr/include/jfs/ino.h에 담겨 있다. 웹 페이지인 http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/inode.h.htm에서도 확인할 수 있다.

위에서 정리한 정보는 유닉스에서 많이 사용하며 파일에 중요하다. 이런 정보 없이는 파일이 손상당하거나 사용 불가능한 상황에 놓인다.

디렉터리와 파일은 다른 운영체제와 비교해서 유닉스 시스템에서 조금 다르게 보일지도 모르겠지만 그렇지 않다. 유닉스에서 디렉터리는 실제로 inode에 몇 가지 추가 설정이 가해진 파일이다. 디렉터리는 기본적으로 다른 파일을 담고 있는 파일이다. 또한 모드 정보는 파일이 실제로 디렉터리라는 사실을 시스템에 알리는 플래그 집합을 포함한다.

위로

inode로 작업하기

유닉스에서 inode로 작업하는 방법을 익히려면 시간도 많이 필요하며 짜증도 난다. 다음에 소개하는 명령어를 활용해 inode에 대해 모를 때 겪었던 두통거리 몇 가지를 완화해보자.

df 명령어

앞서 언급했듯이, 유닉스에서 파일 시스템을 생성할 때, 전체 디스크 공간의 대략 1%가 inode 테이블에 할당된다. 파일 시스템에서 파일을 만들 때마다, inode가 해당 파일에 할당된다. 일반적으로 파일 시스템에 할당된 inode 숫자는 충분하지만 inode가 다 떨어질 가능성도 항상 고려해야 한다. 이를 감시하기 위해 df 결과를 살펴본다.

df 명령어를 사용하면 특정 파일 시스템이나 모든 마운트된 파일 시스템을 살펴볼 수 있다. 명령 결과에서 각 파일 시스템에서 사용된 inode 숫자는 물론이고 전체 파일 시스템에서 사용된 비율도 볼 수 있다. Listing 1을 살펴보자.

df로 inode 사용 감시

                # df -k|head -6Filesystem    1024-blocks      Free %Used    Iused %Iused Mounted on/dev/hd4           229376    138436   40%     4730    13% //dev/hd2          8028160    962692   89%   110034    33% /usr/dev/hd9var       1835008    366400   81%    25829    24% /var/dev/hd3           524288    523564    1%       98     1% /tmp/dev/hd1            32768     32416    2%        5     1% /home

어떤 이유에서인지 파일 시스템 inode 사용도가 100%에 다다르면 추가적인 파일, 디바이스, 디렉터리 등을 파일 시스템에 생성하지 못한다. 한 가지 해법으로 그림 1처럼 smitty chfs 명령으로 파일 시스템에 좀 더 많은 공간을 추가하면 된다.다른 해법으로 좀 더 작은 inode 확장을 만들면 된다. IBM AIX 5L은 이제 향상된 저널링 파일 시스템에서 16KB라는 기본 크기보다 좀 더 작은 inode 확장을 허용한다. 하지만 AIX 5L에서 이 옵션을 켜면, AIX 직전 버전에서 이 파일 시스템에 접근하지 못한다는 사실을 염두에 두자.

그림 1. smitty chfs 명령 결과

istat과 stat

AIX에서 inode를 검사하는 빠른 방법으로 istat 명령어 활용이 있다. 이 명령어는 특정 파일의 inumber와 (파일 유형, UID, GID, 링크 개수(심볼릭 링크 제외), 파일 크기, 마지막 갱신, 변경, 접근에 따른 타임 스탬프 등) 접근 허가 같은 다른 inode 항목을 찾아낼 수 있다.

Listing 2는 AIX에서 /usr/bin/ksh 파일에 대한 inode 정보를 보여준다.

Listing 2. /usr/bin/ksh에 대한 inode 정보

                                # istat /usr/bin/kshInode 18150 on device 10/8      FileProtection: r-xr-xr-xOwner: 2(bin)           Group: 2(bin)Link count:   5         Length 237804 bytesLast updated:   Wed Oct 24 17:37:10 EDT 2007Last modified:  Wed Apr 18 23:58:06 EDT 2007Last accessed:  Mon Apr 28 11:25:35 EDT 2008

istat에서 얻은 표준 정보 이외에 /usr/bin/ksh에 대한 inumber도 확인했다. 파일이 존재하는 논리 볼륨을 찾아낼 수 있다면, 좀 더 많은 정보를 얻을 수 있을 것이다. 이런 정보를 찾아내기 위해 df 명령으로 파일이 존재하는 마운트된 파일 시스템을 살펴본다.

                # df /usr/binFilesystem    512-blocks      Free %Used    Iused %Iused Mounted on/dev/hd2        16056320   1925384   89%   110034    33% /usr

파일 /usr/bin/ksh는 디렉터리 /usr/bin에 들어있다. df 명령 결과를 살펴보면, /usr/bin 디렉터리는 /usr/ 파일 시스템에 포함되어 있고, /usr 파일 시스템은 논리 볼륨인 /dev/hd2 내부에 들어있다. inumber와 논리 볼륨 이름을 둘 다 안다면, istat에 인수로 두 가지 정보 항목을 넘겨 파일을 구성하는 16진 디스크 블록 주소를 파악할 수 있다. Listing 3을 참조하자.

Listing 3. 파일 블록의 16진 주소를 파악하기

                                # istat 18150 /dev/hd2Inode 18150 on device 10/8      FileProtection: r-xr-xr-xOwner: 2(bin)           Group: 2(bin)Link count:   5         Length 237804 bytesLast updated:   Wed Oct 24 17:37:10 EDT 2007Last modified:  Wed Apr 18 23:58:06 EDT 2007Last accessed:  Mon Apr 28 11:44:20 EDT 2008Block pointers (hexadecimal):11620     ef8c0            

리눅스에는 독자적인 istat 버전인 stat이 있다. 리눅스 stat 명령은 비슷한 정보를 보여주며, AIX istat 명령어에 없는 몇 가지 스위치를 또한 포함한다.

                # stat /bin/bash  File: `/bin/bash'  Size: 722684          Blocks: 1432       IO Block: 4096   regular fileDevice: fd00h/64768d    Inode: 12799859    Links: 1Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)Access: 2008-04-06 19:13:50.000000000 -0400Modify: 2006-07-12 03:11:53.000000000 -0400Change: 2007-11-22 04:05:30.000000000 -0500

ls 명령어

살다보면 파일 이름이 아예 없거나 파일 이름에 특수 문자가 들어가거나 대시(-) 문자가 들어있는 파일을 제거하거나 관리하느라 혼쭐이 난 경험이 있을 것이다. 대부분 누군가 파일 이름을 잘못 붙였기 때문에 이런 곤란에 처한다.

유닉스에서 대다수 명령에는 스위치, 옵션을 허용하므로 (스위치/옵선인) -이나 --으로 시작하는 파일을 rm, mv, cp와 같은 자주 사용하는 명령에서 처리하기가 까다롭다. 다행스럽게도, 처리 대상 파일과 관련된 inode의 inumber를 보여주는 명령어 옵션이 있다. ls 명령은 다음과 같다.

                # ls       -      --     -p     fileA  fileB  fileC  fileDfileE  fileF  fileG  fileH  fileI  fileJ  fileK  fileL

Listing 4처럼 ls -i 명령을 활용해 파일 이름 다음에 inumber를 출력할 수 있다. inumber를 알면 파일을 쉽게 다룰 수 있다.

Listing 4. 파일의 inumber 보기

                                # ls -i38988        38991 -p     38984 fileC  38982 fileF  38977 fileI  38978 fileL38989 -      38980 fileA  38986 fileD  38983 fileG  38987 fileJ38990 --     38979 fileB  38976 fileE  38985 fileH  38981 fileK

find 명령어

유닉스 find 명령어를 활용하면 ls 명령어로 시작한 작업을 마무리할 수 있다. 처리해야 하는 각 파일별 inumber를 안다면, 문제는 해결된 셈이다.

이름이 없는 듯이 보이는 파일을 제거하려면 find에 -inum 스위치를 붙여서 inumber와 파일을 찾아본다. 그러고 나서 파일을 찾았다면 find에 -exec 스위치를 붙여 파일을 제거한다.

# find . -inum 38988 -exec rm {} \;

파일 이름을 바꾸려면 rm 대신 mv 명령어를 사용한다.

# find . -inum 38989 -exec mv {} fileM \;

기대했던 결과가 나오는지 비교하려면, ls -i 명령을 다시 한번 내려본다.

                # ls -i38990 --     38979 fileB  38976 fileE  38985 fileH  38981 fileK38991 -p     38984 fileC  38982 fileF  38977 fileI  38978 fileL38980 fileA  38986 fileD  38983 fileG  38987 fileJ  38989 fileM

fsck 명령어

불행히도 하드웨어는 영구적인 물건이 아니며, 시스템은 여러 해 동안 연속으로 사용하면 실패할 가능성이 있다. 이런 일이 벌어지거나 전원 문제 등으로 운영체제가 비정상적으로 종료하는 시점에서 충돌이 생기는 바람에 관리자의 도움이 필요한 경우가 생기기 마련이다. 이런 과정에서 inode를 복구할 필요가 있다거나 오류가 발생했다는 메시지가 뜰지도 모른다. 이런 메시지가 뜰 때, fsck 명령어가 바로 구명 튜브다! 시스템 복구나 심지어 운영체제 재설치 과정 없이도 fsck를 사용해 파일 시스템을 복구하거나 손상당한 inode를 수정할 수 있다.

다음 명령어는 논리 볼륨 /dev/hd1을 복구한다.

# fsck -p /dev/hd1 -y

fsck 명령을 사용해 손상당한 inode 탐색 범위도 좁힐 수 있다. 특정 inode를 탐색한다면, -ii-NodeNumber 스위치를 fsck에 붙인다.

위로

결론

파일과 디렉터리는 inode의 도움 없이는 유닉스 세상에서 거의 쓸모가 없다. 다행스럽게도 이 기사를 읽고 나면 inode의 개념, AIX에서 차지하는 중요성, 관리 기법을 좀 더 제대로 이해할 것이다. df를 다시 한번 되돌아볼지도 모르겠다.

프로세스 및 thread에 대한 추적 방법(?)을 찾아보다가 발견한 글입니다.
출처 : http://chol26.blog.me/80014785501

------------ 펌. ----------------

=== 솔라리스의 경우 ===

솔라리스에서 hang등이 발생했을때 아래와 같은 방법을 사용하면 많은 도움이 될거 같아서 작성해 보았습니다.
(실제 PT단은 약 3~4대정도 솔라리스가 AIX와 병행되어 운영되어질 것 같습니다.)

1.일단 아래와 같은 prstat명령어를 사용하여 java thread중 cpu사용이 많은 job을 구합니다.

참고적으로 prstat는 솔라리스 버전 8부터 지원되는 명령어이며, 솔라리스는 java thread와 kernel thread를
many-to-many(버전 8의 기본값) one-to-one(버전 9의 기본값)로 매핑되어 운영되는 형태입니다.
이에 각 java 스레드를 LWPID와 연계해서 확인해 볼 수 있습니다.(저는 버전 9의 기본값으로 작성했습니다.)

prstat -L -p 5227(java 프로세스 번호)
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/LWPID      
  5227 wasadm    180M  106M sleep   60    4   0:00.13 0.0% java/24
  5227 wasadm    180M  106M sleep   47    4   0:00.54 0.0% java/14
  5227 wasadm    180M  106M sleep   47    4   0:01.04 0.0% java/10
  5227 wasadm    180M  106M sleep   47    4   0:00.00 0.0% java/27
  5227 wasadm    180M  106M sleep   47    4   0:01.10 0.0% java/16
  5227 wasadm    180M  106M sleep   47    4   0:00.12 0.0% java/20
  5227 wasadm    180M  106M sleep   47    4   0:00.01 0.0% java/9
  5227 wasadm    180M  106M sleep   47    4   0:00.04 0.0% java/8
  5227 wasadm    180M  106M sleep   47    4   0:00.29 0.0% java/25
  5227 wasadm    180M  106M sleep   47    4   0:00.00 0.0% java/26
  5227 wasadm    180M  106M sleep   47    4   0:00.00 0.0% java/5
  5227 wasadm    180M  106M sleep   47    4   0:00.00 0.0% java/4
  5227 wasadm    180M  106M sleep   47    4   0:00.00 0.0% java/3
  5227 wasadm    180M  106M sleep   47    4   0:00.00 0.0% java/2
  5227 wasadm    180M  106M sleep   47    4   0:00.17 0.0% java/1

2.psstack 5227를 사용하여 lwp24가 thread 6번과 연계되어 있음을 확인합니다.

----------------  lwp# 24 / thread# 6  --------------------
 ff29f48c lwp_sema_wait (fad01e60)
 ff3596dc _park    (fad01e60, ff37c000, 0, fad01d98, 2316c, fee0bd98) + 114
 ff3593a4 _swtch   (fad01d98, 0, ff37c000, 5, 1000, 0) + 424
 ff3581ac cond_wait (fad01d98, 0, 0, ff37c000, 0, 0) + 11c
 fe512e1c __1cNObjectMonitorEwait6MxlpnGThread__v_ (fe76ba9c, bc8a0, bc888, 1, fe73a000, bc9d8) + 58c
 fe5125fc __1cSObjectSynchronizerEwait6FnGHandle_xpnGThread__v_ (fad016ec, 0, fe73a000, bbf08, 0, bc9f8) + 1d8
 fe5122d4 JVM_MonitorWait (fe74f58c, 0, 0, e8968d30, bbf08, fad017e4) + e0
 00099138 ???????? (e8968d30, 0, fad0185c, e8968d30, bbf08, 0)
 0009629c ???????? (e8968d30, fad01864, bbf08, a1814, 0, f6c3ee7b)
 fb29b30c ???????? (5, 1, 4, fe73a000, fad019e0, f6c3f120)
 fb002748 ???????? (0, 1, fe7476a0, 9e2ec, 1e, e)

3.kill -3 5227로 javacore를 생성합니다.

주의 : 솔라리스에서 javacore가 파일로 저장되어지지 않습니다. 해당 javcore는 해당 인스턴스의
native_stdout.log에 남게 되며 kill -3 PID를 하는 콘솔말고 하나더 콘솔을 open하셔서
tail -f native_stdout.log | tee javacore5227.txt와 같이 하면 콘솔상에서 떨어지는 에러와
함께 파일로도 저장할 실 수 있습니다.

파일을 여시면 nid가 16진수인데 이를 10진수로 변경해서 확인해 보시면 해당 thread가 무슨작업을
할 수 있는지 알 수 있습니다.

more javacore5227.txt

"Reference Handler" daemon prio=10 tid=0xbbf08 nid=0x6 waiting on monitor [0xfad01000..0xfad01a00]
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:415)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:105)

"VM Thread" prio=5 tid=0xbb2a0 nid=0x4 runnable

"VM Periodic Task Thread" prio=10 tid=0xbf2a0 nid=0x8 waiting on monitor
"Suspend Checker Thread" prio=10 tid=0xbf398 nid=0x9 runnable
Full thread dump:

아직 솔라리스가 서비스를 하는 형태가 없어서 실제 서비스 인스턴스가 아닌 솔라리스상의 nodeagent에
서 해당작업을 하다보니 정보가 그리 화려(?)하지 않습니다.

실제 운영상 문제되면 써먹을려고 정리한것인데, 혹 다른 솔라리스사이트에서도 도움이 되었으면....ㅎㅎㅎ

=== AIX의 경우 ===

솔라리스에서 cpu job많이 사용하는 스레드 확인하듯이 AIX에서도
비슷한 방법이 있나  함 확인해 보았습니다..

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

AIX상에서도 솔라리스처럼 CPU시간을 많이 사용하는 스레드를 확인해 볼수 있네요.
약간 부족한 점이 있긴 하지만....개인적으로는 정확한듯 한데..ㅎㅎ

아래의 명령어를 통해서 자바프로세스 내에서 운영중인 스레드정보를 추출합니다.
각 컬럼에 대한 내용은 아래의 참조나 ps 명령어에 대한 manpage를 참조해 주세요.

일단 중요한 것은 TID(커널 스레드 번화)와 ST(스레드상태 R상태인것 주의- 지금은 sleep상태.

dbxtrace결과에서는 runing인데 hang상태에서 한것이 아니라 차례로 명령어가 실행되면서 상태가 바뀐것 같습니다-참고해 주세요.)

CP(cpu사용률 - 100%를 기준으로 하는 것은아닌것같습니다.)정도를 보시면 어느 스레드가 많은 CPU시간을 사용하는지 볼 수 있습니다.

hostname>ps -p 41430 -mo THREAD

    USER   PID  PPID     TID      ST  CP PRI  SC    WCHAN        F         TT     BND    COMMAND
       -     -     -           16183   S    0   60    1 ea001fa0     8410400      -        -               -
       -     -     -           21701   Z    0   60    1        -          c00001        -        -               -
       -     -     -           32849   S    0   60    1        -          418400      -   - -
       -     -     -           37655   S    0   60    1 ea0049a0    8410400      -   - -
       -     -     -           55987   S    0   60    1 ea006d20    8410400      -   - -
       -     -     -           58693  S    0   60    1 ea0072a0    8410400      -   - -
       -     -     -           58951   S    0   60    1 ea007320    8410400      -   - -
       -     -     -           60941   S    0   60    1 ea007720    8410400      -   - -
       -     -     -           71291   Z    0   60    1        -          c00001      -   - -
       -     -     -           72107   S    0   60    1        -          418400      -   - -
       -     -     -           76345   S    0   60    1 ea009520    8410400      -   - -
       -     -     -           76613   S    0   60    1 ea0095a0    8410400      -   - -
       -     -     -           81099   S    0   60    1 ea009e20    8410400      -   - -
       -     -     -           86067   Z    0   60    1        -           c00001      -   - -
       -     -     -           92349   S    0   60    1 70730c6c      400400      -   - -

참고 : THREAD 각 컬럼 내용(좀더 자세한 것은 manpage를 참조해 주세요)

THREAD
  Indicates the following fields:
    o User name (the uname field)
    o Process and parent process IDs for processes (the pid and ppid fields)
    o Kernel thread ID for threads (the tid field)
    o The state of the process or kernel thread (the S field)
    o The CPU utilization of the process or kernel thread (the C field)
    o The priority of the process or kernel thread (the PRI field)
    o The suspend count of the process or kernel thread (the scount field)
    o The wait channel of the process or kernel thread (the WCHAN field)
    o The flags of the process or kernel thread (the F field)
    o The controlling terminal of the process (the tty field)
    o The CPU to which the process or kernel thread is bound (the bnd field)
    o The command being executed by the process (the comm field).

2. 각 TID에 매핑되는 스레드번호를 알기 위해 해당 PID에 대한 dbxtrace를 수집합니다.
hostname> dbxtrace_aix.sh -a 41430 > dbx.out
Creating subcommand file....
Running dbx...
dbx has ended with RC=0

hostname> more dbx.out
Waiting to attach to process 41430 ...
Successfully attached to java.
warning: Directory containing java could not be determined.
Apply 'use' command to initialize source path.

Type 'help' for help.
reading symbolic information ...
stopped in _event_sleep at 0xd37bcbec ($t38)
0xd37bcbec (_event_sleep+0x90) 80410014        lwz   r2,0x14(r1)
thread  state-k     wchan    state-u    k-tid   mode held scope function
 $t1     wait      0xea014120 blocked   164399     k   no   sys  _event_sleep      
 $t2     wait      0x3b3eb898 running   221359     k   no   sys  _ptrgl            
 $t3     wait      0xea00cfa0 blocked   106465     k   no   sys  _event_sleep      
 $t4     wait      0xea00bca0 blocked    96555     k   no   sys  _event_sleep      
 $t5     wait      0xea011ea0 blocked   146851     k   no   sys  _event_sleep      
 $t6     wait      0xea009e20 blocked    81099     k   no   sys  _event_sleep      
 $t8     wait      0xea00b5a0 blocked    93117     k   no   sys  _event_sleep      
 $t12    wait                 running    32849     k   no   sys  poll
 $t378   wait      0xea01c420 blocked   231561     k   no   sys  _event_sleep      
 $t11    wait                 running    72107     k   no   sys  poll              

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

  thread  state-k     wchan    state-u    k-tid   mode held scope function
 $t12    wait                 running    32849     k   no   sys  poll

      general:
         pthread addr = 0x4379db18         size         = 0x22c
         vp addr      = 0x4379fb14         size         = 0x294
         thread errno = 9
         start pc     = 0x30257d48
         joinable     = no
         pthread_t    = 70c
      scheduler:
         kernel       =
         user         = 1 (other)
      event :
         event        = 0x0
         cancel       = enabled, deferred, not pending
      stack storage:
         base         = 0x4371d000         size         = 0x80000
         limit        = 0x4379db18
         sp           = 0x4379d2ec

여기서 얻은 스레드번호를 가지고 dbxtrace하단 부분에서 관련 pthread_t번호(16진수)를 얻습니다.

여기서 javacore를 떨어뜨려서(kill -3 41430) 해당 코아 파일을 열어서 ID를 pthread_t번호와 비교해 보면
해당 스레드가 하는 작업이 무엇인지 알수 있습니다.

3XMTHREADINFO      "LT=1:P=287844:O=0:port=9830" (TID:0x32805288, sys_thread_t:0x436D4120, state:R, native ID:0x70C) prio=5
4XESTACKTRACE          at java.net.PlainSocketImpl.socketAccept(Native Method)
4XESTACKTRACE          at java.net.PlainSocketImpl.accept(PlainSocketImpl.java(Compiled Code))
4XESTACKTRACE          at java.net.ServerSocket.implAccept(ServerSocket.java(Compiled Code))
4XESTACKTRACE          at java.net.ServerSocket.accept(ServerSocket.java(Compiled Code))
4XESTACKTRACE          at com.ibm.rmi.transport.ListenerThread.run(ListenerThread.java:177)
3XHNATIVESTACK       Native Stack
NULL                 ------------
3XHSTACKLINE         at 0xD330672C in poll
3XHSTACKLINE         at 0xD0130A34 in sysTimeout
3XHSTACKLINE         at 0xD0FAB604 in JVM_Timeout
3XHSTACKLINE         at 0xD078ED38 in Java_java_net_PlainSocketImpl_socketAccept

참고 javacore에서는 16진수에서 영문을 표시할때 대문자가 되고 dbxtrace의 결과물의 pthread_t는 소문자가 되는 경우가
있으니 이점은 주의 하세요..

역시 실제 문제있는 데서 한것이 아니라 화려함(?)을 보이지는 못하지만.. 함 해보시면 바로 이해 되실듯....

(나중에 실전에서 다시 함 정리 할 예정입니다..)

http://www.j2eestudy.co.kr/lecture/lecture_read.jsp?db=lecture0401_2&table=j2ee&id=1
http://www.j2eestudy.co.kr/lecture/lecture_read.jsp?db=lecture0401_1&table=j2ee&id=1

http://www.javaservice.net/~java/bbs/read.cgi?m=etc&b=jdk&c=r_p&n=1039372188&p=2&s=t#1039372188
http://www-106.ibm.com/developerworks/eserver/articles/JavaPart2.html
http://www-106.ibm.com/developerworks/eserver/library/es-javaonaix_memory.html

>> 2.psstack 5227를 사용하여 lwp24가 thread 6번과 연계되어 있음을 확인합니다.

위 psstack라는 external command는 없습니다. 아무래도 의미상 오타(?)인 듯 합니다..

pstack으로 사용하세요.