Document ID : TFKBRC00006623
Date : 2004년 03월 16일
Author :
Document Type : RCEN
Description : 시스템이 hang 된 것 같습니다
Category1 : HP-UX
Category2 : System Admin
Search String : 메모리
문]
시스템이 hang 된 것 같습니다
(ping은 되는데, telnet/rlogin, SAM과 타 어플리케이션이 hang입니다)
--> 시스템은 사용자에 의해 TOC 되었습니다!
-------------------------------------------------------------------------------
여기에서는 perl 스크립트 whathappened.pl 과 dump debugger q4를 사용하여 자동으로 만들어진
덤프 분석 출력물을 얻는 방법을 소개합니다:
1) Q4 디버거가 설치되어 있는지 확인합니다:
# swlist -l product | grep -i q4
( PHCO 패치를 리포트하게 됩니다)
이미 설치되어 있을 경우, 3단계로 갑니다), 이외에
2a) IT 리소스 센터에서 다음을 다운로드 받습니다:
http://itrc.hp.com --> Maintenance & Support --> Individual Patches
UX 10.20: PHCO_20261 (또는 보다 최신) 용으로
UX 11.00: PHCO_20262 (또는 보다 최신) 용으로
2b) 이것을 설치합니다:
# sh /tmp/PHCO_20262
# swinstall -s /tmp/PHCO_20262.depot *
3) crashdump fingerprint를 만듭니다:
# cd /usr/contrib/Q4/bin
# . ./set_env (in words: dot space dot slash set_env)
# cd /var/adm/crash/crash.0 (or other crash directory; core.0 for 10.X)
# gunzip vmunix.gz (if compressed)
# q4pxdb vmunix (preprocess the kernel)
# whathappened >wh.out (run the script)
-------------------------------------------------------------------------------
다음은 wh.out내의 세션입니다(이 문제와 관련되어 있는):
System Name: HP-UX
Node Name: greulix
Release: B.11.00
Version: U
Model: 9000/800/L2000-36
Machine ID: 128901527
Processors: 3
Architecture: PA-RISC 2.0
CPU is a: PCXW
Physical Mem: 262144 pages
This is a 64 Bit Kernel
The system had been up for 2.84 days (24564811 ticks).
Load averages: 13.21 12.43 8.60.
System went down at: Tue Mar 6 11:01:08 2001
+--------------------------------------------+
| Performance Related Globals |
+--------------------------------------------+
Physical memory in pages: 262144 1024.00 MBytes
desfree in pages : 1024 4.00 MBytes
minfree in pages : 256 1.00 MByte
freemem in pages : 1032 4.03 MBytes <<<< 메모리가 작음!!!
sleepmem in pages : 1024 4.00 MBytes
avefree in pages : 1032 4.03 MBytes
avefree30 in pages : 1026 4.01 MBytes
MP avenrun shows:
15.54 14.51 10.02
13.04 12.07 8.053
11.04 10.7 7.716
59개의 비활성화된 프로세스들이 있습니다!!!
pageoutrate: 0 curr_pgrate: 0
min_pgrate: 25 max_pgrate: 25
lowmemdeact: 0 thrashdeact: 1362
maxpendpageouts: 2
deactload shows:
58.53 56.89 46.7
CONFIGURATION
HP-UX 10.X, HP-UX 11.X
RESOLUTION
CAUSE:
이것은 분명한 메모리 부족입니다!
이유는?
kmeminfo:
----------------------------------------------------------------------
Physical memory usage summary (in pages):
Physmem = 262144 Available physical memory:
Freemem = 1032 Free physical memory
Used = 261112 Used physical memory:
System = 65088 by kernel:
Static = 11239 for text and static data
Dynamic = 43364 for dynamic data
Bufcache = 10485 for file-system buffer cache
User = 195512 by user processes
Uarea = 1544 for thread uareas
Disowned = 512 disowned pages
==> 메모리는 커널에 의한 것이 아니라 유저 프로세스에 의해 사용되고 있습니다
그럼 왜 그런가요? 공유 메모리 구성을 보십시요:
# ipcs -ma
IPC status from /dev/kmem as of Tue Mar 6 17:10:08 2001
T ID KEY MODE OWNER GROUP CREATOR CGROUP
NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
Shared Memory:
m 256 0x00000000 --rw------- unispool sys unispool sys 5
1032244 2722 3444 17:03:15 no-entry 11:16:12
m 1 0x4e0c0002 --rw-rw-rw- root root root root
2 31040 460 462 11:15:12 11:10:26 11:10:19
m 2 0x41200da3 --rw-rw-rw- root root root root
2 8192 460 462 11:15:12 11:10:19 11:10:19
m 3 0x254571e8 --rw-r----- oral11 dba oral11 dba 34
441217024 1973 3346 17:02:57 17:03:22 11:13:01
m 4 0x00004dbe --rw-rw-rw- root sapsys root sapsys 15
219344 2132 2249 15:05:24 11:13:51 11:13:51
m 261 0x00000000 --rw-rw-rw- l11adm sapsys l11adm sapsys
1 1024 2157 2157 11:13:53 no-entry 11:13:53
m 6 0x0382be84 --rw-rw-rw- l11adm sapsys l11adm sapsys
30 4096 2170 2238 11:14:07 no-entry 11:13:53
m 7 0x00002711 --rw-r----- l11adm sapsys l11adm sapsys
28 1072 2224 2238 11:14:08 no-entry 11:14:07
m 6152 0x0000271a --rw-r----- l11adm sapsys l11adm sapsys 28
431000000 2224 1259 17:09:16 17:09:16 11:14:07
m 521 0x00002724 --rw-r----- l11adm sapsys l11adm sapsys 1
2527744 2238 2238 11:14:07 no-entry 11:14:07
m 4874 0x00002738 --rw-r----- l11adm sapsys l11adm sapsys 26
44000000 2249 2264 11:14:23 no-entry 11:14:08
m 779 0x00002746 --rw-r----- l11adm sapsys l11adm sapsys
26 16384 2249 2264 11:14:23 no-entry 11:14:08
m 780 0x00002719 --rw-r----- l11adm sapsys l11adm sapsys 26
134217728 2249 2264 11:14:23 no-entry 11:14:08
m 20493 0x00000000 --rw------- unispool sys unispool sys
3 83536 2736 3444 17:03:15 17:03:15 11:16:15
m 782 0x00000000 --rw------- unispool sys unispool sys 4
202560 2735 3444 17:03:15 no-entry 11:16:16
m 527 0x00000000 --rw------- unispool sys unispool sys
2 66052 2735 2738 11:16:17 no-entry 11:16:17
sEGSZ 컬럼은 바이트 단위로 각 공유 메모리 사이즈를 보여주고 있습니다. OWNER 컬럼은 각각 세그
먼트의 소유자임을 보여줍니다.
근본 원인:
==> SAP & ORACLE의 공유 메모리 세그먼트가 총 1003MB까지 됩니다. 우리는 단지 1024MB 메모리만을
가지고 있기 때문에 이것은 공유 메모리 버퍼가 RAM에 있을 경우와 페이지 아웃이 되지 않을 경우에서만 해석이
되므로 분명히 잘못된 구성입니다. 이 경우에서는 무엇이 발생했는지를 정확하게 보여주고 있습니다.
Date : 2004년 03월 16일
Author :
Document Type : RCEN
Description : 시스템이 hang 된 것 같습니다
Category1 : HP-UX
Category2 : System Admin
Search String : 메모리
문]
시스템이 hang 된 것 같습니다
(ping은 되는데, telnet/rlogin, SAM과 타 어플리케이션이 hang입니다)
--> 시스템은 사용자에 의해 TOC 되었습니다!
-------------------------------------------------------------------------------
여기에서는 perl 스크립트 whathappened.pl 과 dump debugger q4를 사용하여 자동으로 만들어진
덤프 분석 출력물을 얻는 방법을 소개합니다:
1) Q4 디버거가 설치되어 있는지 확인합니다:
# swlist -l product | grep -i q4
( PHCO 패치를 리포트하게 됩니다)
이미 설치되어 있을 경우, 3단계로 갑니다), 이외에
2a) IT 리소스 센터에서 다음을 다운로드 받습니다:
http://itrc.hp.com --> Maintenance & Support --> Individual Patches
UX 10.20: PHCO_20261 (또는 보다 최신) 용으로
UX 11.00: PHCO_20262 (또는 보다 최신) 용으로
2b) 이것을 설치합니다:
# sh /tmp/PHCO_20262
# swinstall -s /tmp/PHCO_20262.depot *
3) crashdump fingerprint를 만듭니다:
# cd /usr/contrib/Q4/bin
# . ./set_env (in words: dot space dot slash set_env)
# cd /var/adm/crash/crash.0 (or other crash directory; core.0 for 10.X)
# gunzip vmunix.gz (if compressed)
# q4pxdb vmunix (preprocess the kernel)
# whathappened >wh.out (run the script)
-------------------------------------------------------------------------------
다음은 wh.out내의 세션입니다(이 문제와 관련되어 있는):
System Name: HP-UX
Node Name: greulix
Release: B.11.00
Version: U
Model: 9000/800/L2000-36
Machine ID: 128901527
Processors: 3
Architecture: PA-RISC 2.0
CPU is a: PCXW
Physical Mem: 262144 pages
This is a 64 Bit Kernel
The system had been up for 2.84 days (24564811 ticks).
Load averages: 13.21 12.43 8.60.
System went down at: Tue Mar 6 11:01:08 2001
+--------------------------------------------+
| Performance Related Globals |
+--------------------------------------------+
Physical memory in pages: 262144 1024.00 MBytes
desfree in pages : 1024 4.00 MBytes
minfree in pages : 256 1.00 MByte
freemem in pages : 1032 4.03 MBytes <<<< 메모리가 작음!!!
sleepmem in pages : 1024 4.00 MBytes
avefree in pages : 1032 4.03 MBytes
avefree30 in pages : 1026 4.01 MBytes
MP avenrun shows:
15.54 14.51 10.02
13.04 12.07 8.053
11.04 10.7 7.716
59개의 비활성화된 프로세스들이 있습니다!!!
pageoutrate: 0 curr_pgrate: 0
min_pgrate: 25 max_pgrate: 25
lowmemdeact: 0 thrashdeact: 1362
maxpendpageouts: 2
deactload shows:
58.53 56.89 46.7
CONFIGURATION
HP-UX 10.X, HP-UX 11.X
RESOLUTION
CAUSE:
이것은 분명한 메모리 부족입니다!
이유는?
kmeminfo:
----------------------------------------------------------------------
Physical memory usage summary (in pages):
Physmem = 262144 Available physical memory:
Freemem = 1032 Free physical memory
Used = 261112 Used physical memory:
System = 65088 by kernel:
Static = 11239 for text and static data
Dynamic = 43364 for dynamic data
Bufcache = 10485 for file-system buffer cache
User = 195512 by user processes
Uarea = 1544 for thread uareas
Disowned = 512 disowned pages
==> 메모리는 커널에 의한 것이 아니라 유저 프로세스에 의해 사용되고 있습니다
그럼 왜 그런가요? 공유 메모리 구성을 보십시요:
# ipcs -ma
IPC status from /dev/kmem as of Tue Mar 6 17:10:08 2001
T ID KEY MODE OWNER GROUP CREATOR CGROUP
NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
Shared Memory:
m 256 0x00000000 --rw------- unispool sys unispool sys 5
1032244 2722 3444 17:03:15 no-entry 11:16:12
m 1 0x4e0c0002 --rw-rw-rw- root root root root
2 31040 460 462 11:15:12 11:10:26 11:10:19
m 2 0x41200da3 --rw-rw-rw- root root root root
2 8192 460 462 11:15:12 11:10:19 11:10:19
m 3 0x254571e8 --rw-r----- oral11 dba oral11 dba 34
441217024 1973 3346 17:02:57 17:03:22 11:13:01
m 4 0x00004dbe --rw-rw-rw- root sapsys root sapsys 15
219344 2132 2249 15:05:24 11:13:51 11:13:51
m 261 0x00000000 --rw-rw-rw- l11adm sapsys l11adm sapsys
1 1024 2157 2157 11:13:53 no-entry 11:13:53
m 6 0x0382be84 --rw-rw-rw- l11adm sapsys l11adm sapsys
30 4096 2170 2238 11:14:07 no-entry 11:13:53
m 7 0x00002711 --rw-r----- l11adm sapsys l11adm sapsys
28 1072 2224 2238 11:14:08 no-entry 11:14:07
m 6152 0x0000271a --rw-r----- l11adm sapsys l11adm sapsys 28
431000000 2224 1259 17:09:16 17:09:16 11:14:07
m 521 0x00002724 --rw-r----- l11adm sapsys l11adm sapsys 1
2527744 2238 2238 11:14:07 no-entry 11:14:07
m 4874 0x00002738 --rw-r----- l11adm sapsys l11adm sapsys 26
44000000 2249 2264 11:14:23 no-entry 11:14:08
m 779 0x00002746 --rw-r----- l11adm sapsys l11adm sapsys
26 16384 2249 2264 11:14:23 no-entry 11:14:08
m 780 0x00002719 --rw-r----- l11adm sapsys l11adm sapsys 26
134217728 2249 2264 11:14:23 no-entry 11:14:08
m 20493 0x00000000 --rw------- unispool sys unispool sys
3 83536 2736 3444 17:03:15 17:03:15 11:16:15
m 782 0x00000000 --rw------- unispool sys unispool sys 4
202560 2735 3444 17:03:15 no-entry 11:16:16
m 527 0x00000000 --rw------- unispool sys unispool sys
2 66052 2735 2738 11:16:17 no-entry 11:16:17
sEGSZ 컬럼은 바이트 단위로 각 공유 메모리 사이즈를 보여주고 있습니다. OWNER 컬럼은 각각 세그
먼트의 소유자임을 보여줍니다.
근본 원인:
==> SAP & ORACLE의 공유 메모리 세그먼트가 총 1003MB까지 됩니다. 우리는 단지 1024MB 메모리만을
가지고 있기 때문에 이것은 공유 메모리 버퍼가 RAM에 있을 경우와 페이지 아웃이 되지 않을 경우에서만 해석이
되므로 분명히 잘못된 구성입니다. 이 경우에서는 무엇이 발생했는지를 정확하게 보여주고 있습니다.