반응형
문제]
LVM: LVM 정보 수집
구성정보]
해결]
1. 이 분석을 간편하게 수행하는 데 도움이 되는 도구를 사용합니다.
shminfo 및 glance로 시작합니다.
shminfo, kmeminfo 및 procsize는 아직 지원되지 않지만 매우 유용한
HP WTEC 도구입니다.
glance 및 shminfo 정도만 사용할 수 있어도 시스템 메모리 사용량을
간단하게 분석할 수 있습니다.
glance - 시스템 메트릭 모니터링을 완전히 지원하는 HP 제품입니다.
HP-UX 응용 프로그램 미디어에서 시험용 버전 및 라이센스 버전을
사용할 수 있습니다.
shminfo - 사용 가능한 사분면의 리소스 맵을 기반으로 공유 메모리
사용량을 보고합니다.
다음 HP 외부 ftp 사이트에서 다운로드할 수도 있습니다.
ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs/shminfo/shminfo
kmeminfo - HP-UX 커널의 메모리 사용량을 자세히 표시합니다.
HP 응답 센터를 통해 얻을 수 있습니다.
procsize - 시스템에서 수행되는 모든 프로세스의 메모리 사용량을
표시합니다.
HP 응답 센터를 통해 얻을 수 있습니다.
주: hprc.external.hp.com에서 실행할 수 있는 shminfo는 최신 버전이
아닐 수도 있습니다. 지원되지 않는 각 도구의 현재 복사본 및 사용법에
대한 도움말이 필요하면 HP 응답 센터에 문의하십시오.
2. 시스템 정보를 수집합니다.
2.1.
시스템 모델을 기록합니다.
모델 번호
2.2.
OS 버전과 32비트인지 64비트인지 여부를 확인합니다.
# uname -a
#getconf KERNEL_BITS
2.3.
현재 스왑 공간(페이징 영역) 구성을 결정합니다. 계산해야 할 디스크에
페이징된 메모리가 있습니까?
# swapinfo -tm
2.4.
메모리 사용과 관련된 조정 가능한 커널 매개변수의 값을 기록합니다.
nbuf 및 bufpages: 두 값 모두 0으로 설정하면 시스템이 버퍼 캐시의
크기를 동적으로 조정합니다. 그렇지 않으면 버퍼 캐시의 크기가 고정됩니다.
dbc_min_pct 및 dbc_max_pct: 동적 버퍼 캐시 크기를 사용하는 시스템에서
이러한 매개변수는 각각 최소 및 최대 버퍼 캐시 크기를 RAM의 백분율로
설정하는 데 사용됩니다.
2.5.
응용 프로그램이 32비트와 64비트 중 어떤 것으로 실행됩니까, 아니면
둘 다입니까? 응용 프로그램 개발자 및 DBA에 확인해 보십시오.
3. 계산해야 할 현재 사용 중인 메모리가 어느 정도인지 확인합니다.
swapinfo -tm에 의해 디스크에 페이징된 메모리가 있습니까? 있다면
어느 정도입니까?
Glance 또는 dmesg 및/또는 adb와 함께 다음 절차 중 하나를 사용하여
사용 중인 실제 메모리가 어느 정도인지 확인합니다.
3.1.
glance에서 메모리 보고서로 이동합니다.
Glance의 텍스트 모드에서 "메모리 보고서"를 클릭합니다. 또는 단축 키
"m"을 입력합니다.
주: Shift-?를 클릭하면 glance의 모든 단축 키가 표시됩니다.
gpm으로 시작하는 Glance의 GUI 형식에서 "보고서" 풀다운 메뉴를 사용합니다.
"메모리 정보"를 클릭한 다음 "메모리 보고서"를 클릭합니다.
실제 메모리(Phys Mem) 및 사용 가능한 메모리(Free Mem)를 기록합니다.
사용된 RAM의 양을 확인하려면 실제 메모리에서 사용 가능한 메모리를 뺍니다.
메모리가 디스크로 페이징되면 계산할 전체 [가상] 메모리 사용량에 이
메모리 양을 추가합니다.
3.2.
Glance의 텍스트 또는 GUI 형식을 사용할 수 없는 경우에는 dmesg 및 adb와
같은 다른 도구를 사용합니다.
다음 dmesg 및 adb 예제는 98Mb RAM 중 약 88Mb가 사용 중인 모델 712/60
워크스테이션의 예입니다.
# dmesg | grep Physical
Physical: 98304 Kbytes, lockable: 64752 Kbytes, available: 77708 Kbytes
# echo freemem/D | adb /stand/vmunix /dev/kmem
freemem:
freemem: 2500
# bc <-- 명령줄 계산기 시작
2500*4096
10240000 <-- 각각 4096바이트로 된 2500 페이지에 10.24Mb의
여유 공간이 있음
qu
메시지 버퍼가 닫혀서 dmesg가 더 이상 시스템의 실제 메모리 양을 표시하지
않는 경우 ITRC 문서 UPERFKBAN00000726에서 다음 adb 절차를 사용할 수도
있습니다. 이러한 명령의 각 출력은 4096바이트 페이지입니다.
HP-UX 10.X의 경우
예제:
# echo physmem/D | adb /stand/vmunix /dev/kmem
physmem:
physmem: 24576
32비트 아키텍처에서 실행되는 HP-UX 11.X 시스템의 경우
예제:
# echo phys_mem_pages/D | adb /stand/vmunix /dev/kmem
phys_mem_pages:
phys_mem_pages: 24576
64비트 아키텍처에서 실행되는 HP-UX 11.X 시스템의 경우
예제:
# echo phys_mem_pages/D | adb64 /stand/vmunix /dev/mem
phys_mem_pages:
phys_mem_pages: 262144
예제에서는 glance 메모리 보고서에서 약 2.9Gb의 메모리가 사용 중이라고
표시하며(실제 메모리가 사용 가능한 메모리보다 작음) 메모리는 디스크로
페이징되지 않습니다.
이 시점부터는 사용 중인 서로 다른 메모리 유형의 총 사용량을 계속해서
식별합니다.
4.
동일한 glance 메모리 보고서에서 시스템/커널 및 버퍼 캐시가 사용하는
메모리 양을 확인합니다.
1500 Mbyte 버퍼 캐시 (Buf Cache)
94 Mbyte 시스템 메모리 (Sys Mem)
보고된 "시스템 메모리"의 양은 고정 시스템 메모리와 특정한 유형의 동적
시스템 메모리를 더한 값으로, 버퍼 캐시는 포함되지 않습니다. 커널이
시스템 메모리를 사용하는 방법에 대한 자세한 내용은 아직 지원되지
않지만 매우 유용한 WTEC kmeminfo 도구를 참조하십시오. 현재로서는
"Sys Mem" 값이면 충분합니다.
주: 1500Mb는 매우 큰 버퍼 캐시입니다. 기가바이트 또는 더 많은 메모리를
버퍼 캐시에서 다른 용도로 제공할 수도 있습니다.
2900Mb 중 1594Mb가 예제에서 지금까지 사용된 양이며 1306Mb는 아직
계산되지 않았습니다.
4.1.
glance, gpm 또는 kmeminfo가 시스템에 없으면 다음 adb 명령을 사용하여
버퍼 캐시에 사용된 메모리 양을 확인합니다. 출력은 4096바이트 페이지입니다.
# echo bufpages/D | adb /stand/vmunix /dev/kmem
bufpages:
bufpages: 1994
명령줄 계산기를 사용하여 4096바이트 페이지를 바이트로 변환할 수 있습니다.
# bc
1994*4096
8167424
qu
5. 시스템의 공유 메모리 사용량을 확인합니다.
예제에서 2900Mb 중 1594Mb(버퍼 캐시 + 시스템 메모리)가 계산되고 1306Mb는
아직 계산되지 않았습니다.
Unix 시스템에서 데이터베이스가 실행 중인 경우 많은 양의 공유 메모리가
사용되는 것은 일상적인 일입니다. 시스템에서 사용 중인 공유 메모리 유형은
공유 메모리 세그먼트, 공유 메모리 매핑 파일(프로세스 데이터 세그먼트에
있는 개인 메모리 매핑 파일과 반대) 및 공유 라이브러리입니다.
'ipcs -ma'를 실행하여 사용 중인 공유 메모리 세그먼트를 확인할 수 있습니다.
그런 다음 SEGSZ 열의 합계를 계산하거나 ipcs 출력을 세그먼트 크기별로
정렬합니다.
예를 들어, 공유 메모리 세그먼트를 큰 크기부터 작은 크기 순으로
나열하려면(열 번째 순위/열은 SEGSZ): 다음과 같이 입력합니다.
# ipcs -ma | sort -rnk10 | more
'ipcs -ma' 명령은 공유 메모리 세그먼트만 표시합니다. 한 보고서에서
모든 공유 메모리 유형 목록을 보려면 아직 지원되지 않지만 매우 유용한
shminfo라는 WTEC 유틸리티 복사본을 사용합니다.
기본적으로 shminfo는 32비트 전역 창을 표시합니다. -64비트 옵션을 사용하면
shminfo는 64비트 전역 창을 표시합니다.
shminfo 출력은 공유 메모리 세그먼트를 "SHMEM" 유형으로 식별하는 반면
공유 메모리 매핑 파일 및 공유 라이브러리는 "OTHER" 유형으로 식별됩니다.
shminfo 출력은 사분면 수를 포함하여 각 공유 메모리 유형의 메모리에서
위치를 식별합니다.
먼저 사분면 3(Q3) 및 4(Q4)를 확인합니다. 공유 메모리는 사분면 2(Q2)에서
발견될 수도 있지만 이는 특별히 컴파일된 프로세스(SHMEM_MAGIC 실행 가능
유형)에만 해당됩니다.
전역 창의 Q2, Q3 또는 Q4에서 발견되는 모든 공유 메모리 세그먼트(SHMEM)
및 OTHER 영역(공유 라이브러리 및 메모리 매핑 파일은 "OTHER" 유형으로
표시)의 크기를 모두 더합니다.
다음 예제에서 shminfo 발췌문은 전역 Q2 및 Q3이 전혀 사용되지 않았음을
나타냅니다. 반면 전역 Q4에는 SHMEM 유형 1364KB(1.364Mb) 및 OTHER 유형
8720KB(8.72Mb)가 포함됩니다.
전역 32비트 공유 사분면:
===============================
Space Start End Kbytes Usage
Q2 0x000009bb.0x40000000-0x7ffe6000 1048472 FREE
Q3 0x00000000.0x80000000-0xc0000000 1048576 FREE
Q4 0x00000000.0xc0000000-0xc05b9000 5860 OTHER
Q4 0x00000000.0xc05b9000-0xc06f3000 1256 SHMEM id=0
Q4 0x00000000.0xc06f3000-0xc0708000 84 OTHER
Q4 0x00000000.0xc0708000-0xc0709000 4 SHMEM id=1
Q4 0x00000000.0xc0709000-0xc0711000 32 SHMEM id=2 locked
Q4 0x00000000.0xc0711000-0xc0713000 8 SHMEM id=3
Q4 0x00000000.0xc0713000-0xc0884000 1476 OTHER
Q4 0x00000000.0xc0884000-0xc0894000 64 SHMEM id=4
Q4 0x00000000.0xc0894000-0xc08d9000 276 OTHER
Q4 0x00000000.0xc08d9000-0xc08e2000 36 FREE
Q4 0x00000000.0xc08e2000-0xc08fe000 112 OTHER
Q4 0x00000000.0xc08fe000-0xc0901000 12 FREE
Q4 0x00000000.0xc0901000-0xc09e5000 912 OTHER
Q4 0x00000000.0xc09e5000-0xc09eb000 24 FREE
시스템에서 메모리 창이 사용 중이면 이러한 창의 개별 사분면 Q2 및
Q3(shminfo 출력의 개별 섹션)에 있는 공유 메모리를 모두 더합니다.
다음 예제에서 shminfo 발췌문은 사용 가능한 두 메모리 창에서 개별 Q2
및 Q3 사분면이 전혀 사용되지 않음을 나타냅니다. max_mem_window 커널
조정 가능 매개변수를 "2"로 설정하여 전역 창뿐 아니라 메모리 창 2개를
사용할 수 있으므로 이 예제 시스템에서 사용할 수 있는 메모리 창은
2개입니다.
# kmtune | grep win
max_mem_window 2
다음은 메모리 창 정보를 나타내는 shminfo의 발췌문입니다.
Shared space from Window index 1 (unused): <-- 첫 번째 창입니다.
Space Start End Kbytes Usage
Q2 0x00007194.0x40000000-0x7ffeffff 1048512 FREE
Q3 0x00001973.0x80000000-0xbfffffff 1048576 FREE
Shared space from Window index 2 (unused): <-- 두 번째 창입니다.
Space Start End Kbytes Usage
Q2 0x00003156.0x40000000-0x7ffeffff 1048512 FREE
Q3 0x0000094e.0x80000000-0xbfffffff 1048576 FREE
이 예제에서는 shminfo에 SHMEN 유형 1000Mb, OTHER 유형 50Mb가 사용
중이라고 표시됨을 나타냅니다. 이를 다음과 같이 총 사용량에 더합니다.
2900 Mbyte 메모리 사용
1500 Mbyte 버퍼 캐시
94 Mbyte 시스템 메모리
1000 Mbyte 공유 메모리 세그먼트(shminfo의 SHMEM 유형)
50 Mbyte 메모리 매핑 파일 및 공유 라이브러리(shminfo의 OTHER 유형)
지금까지 2900Mb 중 2644Mb가 계산되었습니다. 나머지 256Mb는 다음
프로세스 메모리에서 확인합니다.
6. 시스템에서 실행 중인 개별 프로세스가 텍스트, 데이터 및 메모리 스택
영역을 어떻게 사용하는지 확인합니다.
ps 명령을 사용하여 적절한 범위를 구할 수도 있습니다. 지원되지 않는
HP WTEC procsize 유틸리티를 사용할 수도 있습니다.
ps 및 procsize 명령 사용 예제는 아래와 같습니다.
6.1.
ps -el 출력의 SZ 열은 4096바이트 페이지에서 각 프로세스 텍스트, 데이터
및 스택 영역에서 사용된 총 메모리 양을 나타냅니다.
ps -el | sort -rnk10을 실행하면 시스템에서 실행되는 모든 프로세스가
SZ 열을 기준으로 정렬되어 나열됩니다.
다음 awk 스크립트와 사용 예제는 SZ 열에서 모든 값의 합계를 내는 작업을
단순화합니다.
#!/usr/bin/awk -f
{
total=total+$1
}
END {
print total
}
이 스크립트를 다른 이름으로 저장한 경우(예: 실행 권한이 있는 "summ"이라는
파일) 다음과 같이 사용하여 ps -el 출력의 열 10(SZ 열)에 있는 모든 값의
합계를 계산할 수 있습니다. 결과는 4096바이트 페이지입니다.
예제(열 10은 SZ 데이터):
# ps -el | awk -F' ' '{print $10}' | ./summ
61048
결과에 4096바이트 페이지 크기를 곱합니다.
다른 예:
# ps -el | awk -F' ' '{print $10}' | ./summ
4.81781 E+06
<-- 결과는 4096바이트 페이지 크기에 4817810 페이지("E+06"에서 소수점이
오른쪽으로 여섯 자리 이동)를 곱한 값 또는 약 19.73Gb입니다.
19.73Gb는 큰 수치로서 허용 가능한 범위가 아닐 수도 있습니다.
다음은 추가 설명입니다.
# ps -el | wc -l
810
한 작업에 평균 24Mb 정도를 사용하는 프로세스가 시스템 전체에서
총 810개입니다. 이것은 모두 개인 메모리는 아닐 것이므로 Glance를
더 살펴보는 것이 좋습니다. 예를 들어, 한 프로세스에서 각각 동일한
2Mb 데이터 세그먼트를 공유하는 인스턴스가 700개일 수도 있습니다.
동일한 프로세스의 여러 인스턴스가 각각 많은 양의 개인 메모리를
사용하거나 이전에 알려진 것보다 더 많은 양을 사용하는 경우에는
개발자나 공급업체에 문의하여 관련 응용 프로그램의 리소스 요구사항을
설명하는 것이 좋습니다. 아니면 프로세스별 메모리 요구사항은 정상인데
단순히 더 많은 프로세스 인스턴스를 실행하는 사용자가 더 많아진
것일 수도 있습니다.
아래 설명한 대로 glance 프로세스 메모리 영역 보고서 또는 지원되지
않는 WTEC procsize 유틸리티를 사용하여 각 프로세스의 어떤 메모리
영역이 공유되며 어떤 영역이 개인 영역인지 확인할 수 있습니다.
하나 이상의 프로세스에서 공유되는 메모리는 실행 합계에서 한 번만
계산됩니다.
6.2)
Glance 프로세스 메모리 영역 보고서를 사용하려면
문제의 프로세스(실행 중인 인스턴스를 많이 포함하는 프로세스)의
PID를 기록합니다.
glance를 시작합니다.
"프로세스 선택"을 클릭하거나 "s" 선택 단축 키를 사용합니다.
프롬프트에서 PID를 입력합니다.
"메모리 영역"을 클릭하거나 "M" 프로세스 메모리 영역 단축 키를 사
용합니다.
다음은 glance 프로세스 메모리 영역 목록의 발췌문입니다.
TEXT /Shared na 404kb 444kb na <--
공유 메모리이므로 한 번만 계산됩니다.
DATA /Priv na 2.0mb 2.0mb na <--
개인 메모리이므로 실행 중인 총합에 추가합니다.
STACK /Priv na 40kb 120kb na <--
개인 메모리이므로 실행 중인 총합에 추가합니다.
시스템의 총 SZ 수가 계산할 총 수보다 크면 SZ 열에 나열되는 메모리
대부분을 프로세스에서 공유할 것입니다. 이 경우 아래 설명한 procsize
유틸리티를 사용하여 프로세스 메모리 사용량을 보다 잘 식별할 수
있습니다.
6.3.
다음은 지원되지 않는 HP WTEC procsize 유틸리티 사용 예제입니다.
주: procsize 출력에 표시된 단위는 4096바이트 페이지입니다.
다음 명령줄은 모든 프로세스의 메모리 영역을 나타내며 공유 영역은
한 번만 표시합니다. 이는 VSS(가상 집합 크기)가 아니라 메모리에
실제로 있는 RSS(상주 집합 크기)입니다. -R과 -V를 모두 지정한 경우
RSS와 VSS 데이터가 모두 표시될 수 있습니다. 기본값은 VSS입니다.
# ./procsize -Rfn
"-R"은 기본 VSS(가상 집합 크기)가 아닌 RSS(상주 집합 크기) 정보를
나타냅니다.
"-f"는 모든 프로세스에 대해 보고합니다.
"-n"은 영역을 사용하는 첫 번째 프로세스에 대해 영역을 한 번만
계산하도록 합니다. 기본 동작은 공유 영역이 발견될 때마다 보고하는
것입니다. 공유되는 영역과 공유되지 않는 영역을 확인하기 위해 이
플래그를 사용하거나 사용하지 않고 procsize를 실행할 수 있습니다.
다음은 procsize 출력의 발췌문 예제입니다. procsize 자체는 약
9.8Mb(2414 페이지)의 메모리를 사용합니다. 열 3의 "r"은 RSS 값이
표시됨을 나타냅니다.
# ./procsize -Rfn
libp4 (6.93): Opening /stand/vmunix /dev/kmem
regions set to 1000
hpux 11.00 32 bit in Narrow mode
nproc=276
pid Comm UAREA TEXT DATA STACK SHMEM IO MMAP Total
0 swapper r 0 0 0 0 0 0 0 0
1 init r 4 61 24 10 0 0 0 100
2 vhand r 4 0 0 0 0 0 0 4
...
5237 gpm r 4 218 1464 12 0 0 187 1885
23828 dtsession r 4 17 64 2 0 0 50 137
29565 procsize r 4 49 328 6 0 0 2027 2414
23876 dtfile r 0 0 0 0 0 0 0 0
5233 dtexec r 4 4 1 2 0 0 1 12
23880 dtexec r 4 0 0 0 0 0 0 4
23885 netscape r 4 47 53 1 0 0 8 113
시스템의 숫자가 사용 중인 메모리 양과 비슷하지 않은 경우에는
kmeminfo 커널 메모리 도구와 같은 도구를 사용하여 보다 자세히
확인할 수 있습니다. 다음은 자세한 내용입니다.
이 예제에서 ps 명령 SZ 열의 누적 합계는 61035 페이지 또는 약 250Mb입니다.
2900 Mbyte 메모리 사용
1500 Mbyte 버퍼 캐시
94 Mbyte 시스템 메모리
1000 Mbyte 공유 메모리
40 Mbyte 메모리 매핑 파일
10 Mbyte 공유 라이브러리
250 Mbyte 프로세스 텍스트+데이터+스택
====
2894
2900Mb 중 2894Mb가 계산되었습니다. 버퍼 캐시가 1500Mb이면 매우
큰 것이며 Gb 이상 크기를 줄일 수도 있습니다. 1000Mb 공유 메모리는
특히 데이터베이스가 실행 중인 경우 전혀 행에서 벗어나지 않을
것입니다. 또한 데이터베이스가 실행 중인 경우에는 버퍼 캐시 크기를
제한함으로써 비워지는 메모리가 데이터베이스에 의해 공유 메모리로
사용되도록 하는 방법을 고려할 수 있습니다.
250Mb 프로세스 텍스트+데이터+스택의 대부분(예: 200Mb 정도)이 실제로
공유되고 있을 것입니다. 아직 계산되지 않은 6Mb와 합치면 커널은
206Mb를 사용하는 것이 됩니다. 이 정도면 과도한 양은 아닙니다.
7. HP-UX 커널이 메모리를 어떻게 사용하는지 확인합니다.
예제에서는 다른 206Mb의 사용된 메모리가 계산되어야 합니다.
사용하기에 적합한 도구는 kmeminfo입니다.
kmeminfo를 실행하는 경우에는 kmeminfo 데이터에 대한 충분한 이해를
위해 HP 응답 센터에 도움을 청하는 것이 좋습니다.
현재 예제에서 커널이 사용하는 206Mb는 행에서 벗어나지 않을 것입니다.
시스템이 사용되는 방법에 따라 수백 Mb가 행에서 벗어나지 않을 수도
있습니다.
"커널이 사용한"이라는 말은 일반적으로 사용자 리소스를 관리하고
시스템에서 실행되는 여러 프로세스의 메모리 요청을 만족시키기 위해
커널이 처리하는 메모리를 의미합니다. 일부 커널 메모리는 부팅할 때
정적으로 크기가 조정되며 일부는 부팅 후에 동적으로 크기가 조정됩니다.
프로세스마다 서로 다른 명칭으로 메모리를 요청하는 경향이 있습니다.
예를 들어, 서로 다른 커널 메모리 "버킷" 또는 "어레나"를 사용합니다.
예를 들어, HP-UX 11.0에서 시작하면 JFS는 2Kb의 메모리를 사용하므로,
커널은 2048바이트 요청을 만족시키기 위해 4096바이트 페이지의 메모리를
축적하게 됩니다. HP-UX 10.20에서 JFS가 1Kb의 메모리를 사용했다면
kmeminfo는 이 작업을 "1Kb 커널 버킷"에 반영합니다.
HP-UX 11i에서 시작하면 기본 kmeminfo 출력은 커널 메모리 "버킷"이
아닌 "어레나"에 대한 정보를 표시합니다. 서로 다른 프로세스의 메모리
작업이 서로 다른 어레나의 증감 시에 반영됩니다.
메모리는 Super Page Pool을 사용하여 어레나를 처리합니다. 수퍼 페이지는
그 일부를 어레나가 사용하고 있는 한 Super Page Pool에 남아 있습니다.
이상적으로는 커널 버킷/어레나 또는 Super Page Pool의 메모리 양은
최소가 되어야 합니다. 그러나 특정 버킷/어레나에서 메모리 양을
확인하는 자체가 메모리 소모는 아님을 알아두어야 합니다. 메모리
소모란 무언가가 시간이 가면서 감소하지 않고 증가하고 있음을 의미합니다.
특정 버킷/어레나에서 메모리 사용량이 과도한 것은 커널 또는 응용
프로그램을 조정할 필요가 있음을 의미합니다.
Super Page Pool에서 과도한 메모리 사용은 HP-UX 패칭을 통해 해결할
문제가 있음을 의미합니다.
이와 관련된 문제나 의문점이 있으면 HP 응답 센터에 문의하십시오.
다음 kmeminfo 발췌문(4096바이트 페이지의 값)은 약 268Mb RAM의 시스템을
표시합니다. 메모리 중 232Mb가 사용 중이며 51Mb는 사용자 프로세스,
184Mb는 커널에 의해 사용됩니다. "커널"이 사용하는 184Mb 중 134Mb는
버퍼 캐시, 27Mb는 동적 커널 버킷, 22Mb는 정적 구조, 즉 시스템 테이블의
몫입니다.
실제 메모리 사용 요약(페이지):
Physmem = 65536 사용 가능한 실제 메모리:
Freemem = 8765 빈 실제 메모리
Used = 56771 사용된 실제 메모리:
System = 45015 커널에 사용:
Static = 5373 텍스트 및 정적 데이터에 사용
Dynamic = 6730 동적 데이터에 사용
Bufcache = 32768 파일 시스템 버퍼 캐시에 사용
Eqmem = 16 이에 상당하는 매핑 페이지 풀에 사용
SCmem = 128 시스템 고유의 페이지 풀에 사용
User = 12490 사용자 프로세스에 사용
Uarea = 460 스레드 영역에 사용
동일한 kmeminfo 출력의 다른 발췌문에서 27Mb의 동적 커널 메모리
사용은 다음으로 세분화됩니다. 약 11Mb는 커널 버킷에 사용되며
(2671 페이지 * 4096바이트 페이지 크기), 1Kb 크기의 버킷 10
(656 페이지 * 4096바이트 페이지 크기)에 가장 많은 약 2.7Mb의
양이 축적됩니다.
동적 메모리 사용 요약(페이지):
Dynamic = 6730 커널 동적 데이터(sysmap):
MALLOC = 2671 메모리 버킷:
bucket[ 5] = 179 size 32 bytes
bucket[ 6] = 25 size 64 bytes
bucket[ 7] = 282 size 128 bytes
bucket[ 8] = 164 size 256 bytes
bucket[ 9] = 190 size 512 bytes
bucket[10] = 656 size 1024 bytes
bucket[11] = 340 size 2048 bytes
bucket[12] = 387 size 4096 bytes
bucket[13] = 30 size 2 pages
bucket[14] = 21 size 3 pages
bucket[15] = 20 size 4 pages
bucket[16] = 5 size 5 pages
bucket[17] = 18 size 6 pages
bucket[18] = 0 size 7 pages
bucket[19] = 56 size 8 pages
bucket[20] = 298 size > 8 pages
Kalloc = 4003 kalloc()
Eqalloc = 45 eqalloc()
Reserved = 11 예약된 풀
134Mb 버퍼 캐시는 RAM의 절반입니다. 동적 버퍼 캐시 증가의
상한을 제어하는 dbc_max_pct 커널 조정 가능 매개변수의 기본값은
50 [퍼센트]입니다. 메모리가 작은 시스템에서는 이 정도면 충분할
수 있습니다. 사용 가능한 메모리는 약 36Mb입니다. 사용자 프로세스의
데이터 세그먼트와 같이 다른 위치에서 메모리가 필요한 경우 버퍼
캐시 크기를 더 작게 설정할 수도 있습니다. 이를 변경하기 전에
sar -b를 사용하거나 glance 디스크 보고서("Local" "Logl Rds" 및
"Logl Wts" 행의 백분율 열 아래)에서 버퍼 캐시 사용량을
모니터링하십시오. 또는 시스템이 디스크에 페이징되도록 할 수도
있습니다. 나중에는 커널이 최근에 사용되지 않은 메모리 페이지만
페이징하게 됩니다.
8. 아직도 시스템에서 메모리 사용을 모두 확인할 수 없습니까?
커널의 메모리 사용을 확인할 수 있는 보다 직관적인 방법이 있습니다.
위에 나열된 대로 수행한 후에도 메모리가 사용되는 정확한 위치를
확인하지 못한 경우에는 HP 응답 센터에 문의하십시오.
*************************************************************************************
.........following with all English text ....
KBRC00011764How to account for memory usage on an HP-UX system
Problem Description
How to account for memory usage on an HP-UX system
Configuration Info
Solution
1. Obtain the tools that will make this analysis easier.
Start with shminfo and glance.
shminfo, kmeminfo and procsize are unsupported yet very useful HP WTEC tools.
Having at least glance and shminfo available will simplify the analysis of
system memory usage.
glance - Fully supported HP product for monitoring system metrics.
Trial and licensed copies are available on the HP-UX application media.
shminfo - Reports shared memory usage based on the resource maps of available
quadrants. May be downloaded from the following HP external ftp site.
ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs/shminfo/shminfo
kmeminfo - Shows details of memory usage by the HP-UX kernel.
Obtain through the HP Response Center
procsize - Shows memory usage of all processes on the system.
Obtain through the HP Response Center
Note: The shminfo executable at hprc.external.hp.com may not be the latest
version. For the current copies of each unsupported tool, and for assistance
in their use, contact the HP Response Center.
2. Collect system information
2.1.
Note system model:
# model
2.2.
Identify the OS version, and whether it's 32-bit or 64-bit.
# uname -a
# getconf KERNEL_BITS
2.3.
Determine the current swap space (paging area) configuration. Is there any
memory paged out to disk that needs to be accounted for?
# swapinfo -tm
2.4.
Note the value of some tunable kernel parameters that relate to memory usage.
nbuf & bufpages: If both are set to zero then system is dynamically sizing
buffer cache - else the buffer cache is statically fixed in size.
dbc_min_pct & dbc_max_pct: On systems using dynamic buffer cache sizing
these parameters are used to set minimum and maximum buffer cache size,
respectively, as a percentage of RAM.
2.5.
Are applications running as 32-bit, 64-bit, or both? Check with application
developers and DBA's for help in determining this.
3. Determine how much memory is presently in use that needs to be accounted
for.
Is there any memory paged out to disk as per swapinfo -tm? How much?
Use one of the following procedures with either Glance, or with dmesg
and/or adb to identify how much of physical memory is in use.
3.1.
Go to the memory report in glance.
In the text mode of Glance, click on "Memory Report". Or enter the short-cut
key "m".
Note: Shift-? shows all glance short-cut keys.
In the GUI form of Glance started with gpm, use the "Reports" pull-down
menu. Click on "Memory Info", then "Memory Report".
Note the physical memory (Phys Mem) and the free memory (Free Mem).
To determine the amount of RAM used, subtract free memory from physical memory.
If any memory is paged out to disk, then add that amount to the total of
[virtual] memory usage to be accounted for.
3.2.
If the text or GUI form of Glance is not available, then use other tools such
as dmesg and adb.
The following examples of dmesg and adb are from a model 712/60
workstation where around 88 out of 98 Mb RAM is in use.
# dmesg | grep Physical
Physical: 98304 Kbytes, lockable: 64752 Kbytes, available: 77708 Kbytes
# echo freemem/D | adb /stand/vmunix /dev/kmem
freemem:
freemem: 2500
# bc
<-- Start the command line calculator
2500*4096
10240000 <-- 2500 pages of 4096 bytes each is 10.24 Mb free
qu
If the message buffer has wrapped around and dmesg is no longer
displaying the amount of physical memory on the system, then the following
adb procedures from ITRC document UPERFKBAN00000726 might be used. The
output of each of these commands will be in 4096-byte pages.
For HP-UX 10.X
Example:
# echo physmem/D | adb /stand/vmunix /dev/kmem
physmem:
physmem: 24576
For HP-UX 11.X systems running on 32 bit architecture:
Example:
# echo phys_mem_pages/D | adb /stand/vmunix /dev/kmem
phys_mem_pages:
phys_mem_pages: 24576
For HP-UX 11.X systems running on 64 bit architecture:
Example:
# echo phys_mem_pages/D | adb64 /stand/vmunix /dev/mem
phys_mem_pages:
phys_mem_pages: 262144
For the ongoing example, the glance memory report is showing around 2.9 Gb
of memory in use (Phys Mem less Free Mem), and no memory is paged out to
disk.
From this point on continue to keep a running total as the different types of
memory in use are identified.
4.
From the same glance memory report, note how much memory the system/kernel and
buffer cache are using.
1500 Mbyte buffer cache (Buf Cache)
94 Mbyte system memory (Sys Mem)
The amount of "Sys Mem" reported is static system memory plus certain types of
dynamic system memory, not including the buffer cache. For a more detailed view
of how the kernel is using system memory refer to the unsupported yet very
useful WTEC kmeminfo tool. But for now, the "Sys Mem" value is sufficient.
Note: 1500 Mb is an overly large buffer cache. Most likely, a Gigabyte or more
of memory could be freed from the buffer cache to other uses.
1594 out of 2900 Mb has been so far accounted for in the ongoing example,
leaving 1306 Mb yet to account for.
4.1.
If glance, gpm or kmeminfo are not on the system then use
the following adb command to identify the amount of memory used in the
buffer cache. The output will be in 4096-byte pages.
# echo bufpages/D | adb /stand/vmunix /dev/kmem
bufpages:
bufpages: 1994
The command line calculator may be used to convert 4096-byte pages to bytes:
# bc
1994*4096
8167424
qu
5. Look at the shared memory usage on the system.
At this point in the example 1594 Mb have been accounted for (buffer cache +
system memory) out of 2900 Mb, with 1306 Mb yet to be accounted for.
It is not uncommon to see signficant amounts of shared memory in use on a Unix
system - especially if a database is running. The types of shared memory
in use on a system may be shared memory segments, shared memory mapped files
(as opposed to private memory mapped files found in a processes data segment)
and shared libraries.
`ipcs -ma` might be run to see what shared memory segments are in use. Then
either total the SEGSZ column, or sort the ipcs output by segment
size.
For example, to simply list shared memory segments from largest to smallest
(10th rank/column is SEGSZ):
# ipcs -ma | sort -rnk10 | more
The `ipcs -ma` command just shows shared memory segments. To see a listing of
all shared memory types in one report, obtain a copy of an unsupported yet very
useful WTEC utility called shminfo.
By default, shminfo looks at the 32-bit global window. Using the -64bit option
tells shminfo to look at the 64-bit global window.
The shminfo output will identify shared memory segments as type "SHMEM", while
shared memory mapped files and shared libraries will be identified as
type "OTHER".
The shminfo output identifies the location in memory of each shared memory
type, including quadrant number.
Look primarily in quadrants 3 (Q3) and 4 (Q4). Shared memory might also be
found in quadrant 2 (Q2), but only for specially compiled processes
(SHMEM_MAGIC executable types).
Add together the size of all shared memory segments (SHMEM) and OTHER areas
(shared libraries and memory mapped files show at type "OTHER") that are found
in Q2, Q3 or Q4 of the global window.
In the following sample shminfo excerpt note that global Q2 and Q3 are
completely unused. While Global Q4 has 1364 Kbytes of type SHMEM (1.364 Mb),
and 8720 Kbytes (8.72 Mb) of type OTHER.
Global 32-bit shared quadrants:
===============================
Space Start End Kbytes Usage
Q2 0x000009bb.0x40000000-0x7ffe6000 1048472 FREE
Q3 0x00000000.0x80000000-0xc0000000 1048576 FREE
Q4 0x00000000.0xc0000000-0xc05b9000 5860 OTHER
Q4 0x00000000.0xc05b9000-0xc06f3000 1256 SHMEM id=0
Q4 0x00000000.0xc06f3000-0xc0708000 84 OTHER
Q4 0x00000000.0xc0708000-0xc0709000 4 SHMEM id=1
Q4 0x00000000.0xc0709000-0xc0711000 32 SHMEM id=2 locked
Q4 0x00000000.0xc0711000-0xc0713000 8 SHMEM id=3
Q4 0x00000000.0xc0713000-0xc0884000 1476 OTHER
Q4 0x00000000.0xc0884000-0xc0894000 64 SHMEM id=4
Q4 0x00000000.0xc0894000-0xc08d9000 276 OTHER
Q4 0x00000000.0xc08d9000-0xc08e2000 36 FREE
Q4 0x00000000.0xc08e2000-0xc08fe000 112 OTHER
Q4 0x00000000.0xc08fe000-0xc0901000 12 FREE
Q4 0x00000000.0xc0901000-0xc09e5000 912 OTHER
Q4 0x00000000.0xc09e5000-0xc09eb000 24 FREE
If memory windows are in use on the system then also add together the shared
memory found in the private quadrants Q2 and Q3 of those windows (a separate
section of shminfo output).
In the following sample shminfo excerpt note that private Q2 and Q3 quadrants
are completely unused in two available memory windows. There are two memory
windows available on this example system because the max_mem_window kernel
tunable was set to "2" (allowing two memory windows in addition to the global
window).
# kmtune | grep win
max_mem_window 2
Here's an excerpt from shminfo showing memory windows information.
Shared space from Window index 1 (unused):
<-- Here's the first window
Space Start End Kbytes Usage
Q2 0x00007194.0x40000000-0x7ffeffff 1048512 FREE
Q3 0x00001973.0x80000000-0xbfffffff 1048576 FREE
Shared space from Window index 2 (unused): <-- Here's the second window
Space Start End Kbytes Usage
Q2 0x00003156.0x40000000-0x7ffeffff 1048512 FREE
Q3 0x0000094e.0x80000000-0xbfffffff 1048576 FREE
In this running example pretend that shminfo showed a total of 1000 Mb of type
SHMEM in use, and 50 Mb of type OTHER. Add that into the running total as
follows...
2900 Mbyte memory used
1500 Mbyte buffer cache
94 Mbyte system memory
1000 Mbyte shared memory segments (type SHMEM in shminfo)
50 Mbyte memory mapped files and shared libraries (type OTHER in shminfo)
So far accounted for are 2644 out of 2900 Mb. For the remaining 256 Mb look
next at process memory.
6. See how the individual processes running on the system use text, data and
stack areas of memory.
The ps command may be used to get a decent ballpark total. The unsupported HP
WTEC procsize utility might also be used.
Examples of ps and procsize command usage are shown below.
6.1.
The SZ column in ps -el output indicates in 4096-byte pages, the total
amount of memory used in each processes text, data and stack areas.
Running ps -el | sort -rnk10 will list all processes on the system,
sorted by the SZ column.
The following awk script with usage example simplifies the task of totaling all
values in the SZ column:
#!/usr/bin/awk -f
{
total=total+$1
}
END {
print total
}
If this script were saved as, for example a file called "summ" with execute
permissions, then it could be used as follows to total all values found in
column 10 of ps -el output (the SZ column). The result is in 4096-byte
pages.
One example (column 10 is the SZ data):
# ps -el | awk -F' ' '{print $10}' | ./summ
61048
Multiply the the result by the 4096-byte page size.
Another example:
# ps -el | awk -F' ' '{print $10}' | ./summ
4.81781 E+06
<-- That's 4817810 pages (decimal point moved right six
places for "E+06") multiplied by a 4096-byte page
size, or about 19.73 Gb
19.73 Gb is a large number ie might not be an acceptable ball park number -
look further...
# ps -el | wc -l
810
That's 810 total processes on the system using an average of about 24 Mb a
piece. This is probably not all private memory, so look further with Glance eg
there might be 700 instances of a process each sharing the same 2 Mb data
segment. If many instances of the same process were each using a large amount
of private memory, or a larger amount than they had previously been known to
use, then it would be appropriate to ask the developer or vendor to explain the
resource requirements of the related application. Or perhaps the per-process
memory requirements are normal and there are simply many more users running
many more instances of the process.
Either the glance process memory region report or the unsupported WTEC procsize
utility might be used (both discussed below) to determine which memory regions
of each process are shared and which are private. Memory that is shared between
more than one process should only be counted once in the running total.
6.2)
To use the Glance process memory regions report:
Note the PID of a process in question eg one that has many running instance's.
Start glance.
Click on "Select Process" (or use the "s" select shortcut key).
When prompted, enter the PID.
Click on "Memory Regions" (or use the "M" process memory regions shortcut key).
Here's an excerpt from a glance process memory region listing:
TEXT /Shared na 404kb 444kb na <--
Shared so only count once
DATA /Priv na 2.0mb 2.0mb na
<--
Priv so add to the running total
STACK /Priv na 40kb 120kb na <--
Priv so add to the running total
If the SZ numbers on the system total much more than the total to be accounted
for, then much of the memory listed in the SZ column is probably shared between
processes. In that case, the procsize utility discussed below could be used to
better identify process memory usage.
6.3.
Here's an example of using the unsupported HP WTEC procsize utility.
Note: The displayed units in the output of procsize are in 4096 byte pages.
The following command line would show memory regions for all processes, with
shared regions only shown once. Note that it's the Resident Set Size (RSS)
that's actually in memory that is of interested and not the Virtual Set Size
(VSS). Both the RSS and VSS data could be displayed if both -R and -V are
specified. The default is VSS.
# ./procsize -Rfn
"-R" says to display the RSS (Resident Set Size) information, rather than the
default VSS (Virtual Set Size).
"-f" says to report on every process.
"-n" says to only count a region once, for the first process that uses it. The
default action is to report shared regions each time they are found. You
might run procsize with and without this flag towards gaining an
understanding of what regions are shared, and not shared.
Here's a sample excerpt of procsize output. Note procsize itself using a total
of around 9.8 Mb (2414 pages) of memory. The "r" in column 3 indicates that
RSS values are being displayed.
# ./procsize -Rfn
libp4 (6.93): Opening /stand/vmunix /dev/kmem
regions set to 1000
hpux 11.00 32 bit in Narrow mode
nproc=276
pid Comm UAREA TEXT DATA STACK SHMEM IO MMAP Total
0 swapper r 0 0 0 0 0 0 0 0
1 init r 4 61 24 10 0 0 0 100
2 vhand r 4 0 0 0 0 0 0 4
...
5237 gpm r 4 218 1464 12 0 0 187 1885
23828 dtsession r 4 17 64 2 0 0 50 137
29565 procsize r 4 49 328 6 0 0 2027 2414
23876 dtfile r 0 0 0 0 0 0 0 0
5233 dtexec r 4 4 1 2 0 0 1 12
23880 dtexec r 4 0 0 0 0 0 0 4
23885 netscape r 4 47 53 1 0 0 8 113
If the numbers on the system do not come close to the amount of memory being
utilized, then there are other tools such as the kmeminfo kernel memory tool to
help look further. More on that below.
From the current example, say that the cumulative total of the ps command SZ
column came out to 61035 pages, or about 250 Mb:
2900 Mbyte memory used
1500 Mbyte buffer cache
94 Mbyte system memory
1000 Mbyte shared memory
40 Mbyte memory mapped files
10 Mbyte shared libraries
250 Mbyte process text+data+stack
====
2894
That's 2894 of 2900 Mb accounted for. The buffer cache seems over sized at 1500
Mb, and might well be reduced in size by a Gb or more. The 1000 Mb shared
memory may not be out of line at all - especially if there is a database
running. And if a database were running then consider that any memory freed
through limiting buffer cache size might be better used as shared memory by the
database.
Perhaps a large portion of that 250 Mb process text+data+stack is actually
shared eg perhaps it's high by as much as 200 Mb, and when combined with the 6
Mb yet to be accounted for might indicate that the kernel is using 206 Mb - not
an excessive amount.
7. Look at how the HP-UX kernel is utilizing memory.
Say that in the ongoing example it was found that there was yet another 206 Mb
of used memory to account for. The appropriate tool to use would be kmeminfo.
When reaching the point of running kmeminfo, it would be a good idea to be
working with the HP Response Center to fully understand the kmeminfo data.
In the current ongoing example, 206 Mb being used by the kernel may not be out
of line. And depending upon how the system is being used, several hundred Mb
might not be out of line.
"Used by the kernel" generally means memory that is handled by the kernel as it
manages user resources, and works to satisfy the memory requests of the many
processes running on the system." Some kernel memory is statically sized at boot
time, and some dynamically sized after boot time. Different processes tend to
request memory in different denomintations ie make use of different kernel
memory "buckets" or "arena's".
For example, starting at HP-UX 11.0 JFS tends to make use of memory in 2 Kb
pieces - and so the kernel might build up an accumulation of 4096-byte pages of
memory specifically for satisfying 2048-byte requests. At HP-UX 10.20 JFS
tended to make use of memory in 1 Kb pieces, and kmeminfo would reflect that
activity in the "1 Kb kernel bucket".
Starting with HP-UX 11i default kmeminfo output displays information about
kernel memory "arena's" rather than "buckets". The memory activity of different
processes on the system is reflected in the increase and decrease of different
arena's.
Memory makes it's way to the arena's by way of the Super Page Pool. A super
page remains in the Super Page Pool so long as any portion of it is in use by
an arena.
Ideally, the amount of memory seen in any kernel bucket/arena, or in the Super
Page Pool should be minimal. But it is important to understand that seeing a
quantity of memory in a particular bucket/arena does not by itself indicate a
memory leak. A memory leak is where something continues to grow over time
without ever decreasing.
Excessive use of memory in particular buckets/arena's might be indications that
kernel or application tuning needs to take place.
Excessive use of memory in the Super Page Pool might indicate a problem that's
addressed through HP-UX patching.
Contact the HP Response Center for any concerns or questions in these areas.
The following kmeminfo excerpt (values in 4096-byte pages) shows a system with
around 268 Mb RAM. 232 Mb of that memory is in use - 51 Mb of that by user
processes and 184 Mb of that by the kernel. What's used "by the kernel" is
broken out as 134 Mb buffer cache, 27 Mb dynamic eg kernel buckets, 22 Mb
static structures eg system tables.
Physical memory usage summary (in pages):
Physmem = 65536 Available physical memory:
Freemem = 8765 Free physical memory
Used = 56771 Used physical memory:
System = 45015 by kernel:
Static = 5373 for text and static data
Dynamic = 6730 for dynamic data
Bufcache = 32768 for file-system buffer cache
Eqmem = 16 for equiv. mapped page pool
SCmem = 128 for system critical page pool
User = 12490 by user processes
Uarea = 460 for thread uareas
From another excerpt of that same kmeminfo output, usage of the 27 Mb of
dynamic kernel memory is broken out as follows. Almost 11 Mb is used in kernel
buckets (2671 pages * 4096 byte page size) with the largest accumulation of
about 2.7 Mb in bucket 10 (656 pages * 4096 byte page size), the 1 Kb bucket.
Dynamic memory usage summary (in pages):
Dynamic = 6730 Kernel dynamic data (sysmap):
MALLOC = 2671 memory buckets:
bucket[ 5] = 179 size 32 bytes
bucket[ 6] = 25 size 64 bytes
bucket[ 7] = 282 size 128 bytes
bucket[ 8] = 164 size 256 bytes
bucket[ 9] = 190 size 512 bytes
bucket[10] = 656 size 1024 bytes
bucket[11] = 340 size 2048 bytes
bucket[12] = 387 size 4096 bytes
bucket[13] = 30 size 2 pages
bucket[14] = 21 size 3 pages
bucket[15] = 20 size 4 pages
bucket[16] = 5 size 5 pages
bucket[17] = 18 size 6 pages
bucket[18] = 0 size 7 pages
bucket[19] = 56 size 8 pages
bucket[20] = 298 size > 8 pages
Kalloc = 4003 kalloc()
Eqalloc = 45 eqalloc()
Reserved = 11 Reserved pools
Note that the 134 Mb buffer cache is half of RAM. It looks like the dbc_max_pct
kernel tunable that controls the upper limit of dynamic buffer cache growth is
at it's default value of 50 [percent]. On this small memory system that may be
OK. Note that there's about 36 Mb free memory. If memory were needed elsewhere
eg in the data segments of user processes, then perhaps the buffer cache size
could be smaller. Before making such a change be sure to monitor the buffer
cache usage over time eg with sar -b or in the glance disk report (under the
percent column of the "Local" "Logl Rds" and "Logl Wts" lines). Or perhaps just
letting the system page out to disk is not a problem. After all, the kernel
will work to page out only those memory pages that have not been recently used.
8. Still unable to account for all memory utilization on the system?
There are more intrusive methods of identifying how memory is being used by the
kernel. If this point is reached and it is not yet seen where exactly memory is
being used - the HP Response Center should be involved.
Keywords
#################################################################
LVM: LVM 정보 수집
구성정보]
해결]
1. 이 분석을 간편하게 수행하는 데 도움이 되는 도구를 사용합니다.
shminfo 및 glance로 시작합니다.
shminfo, kmeminfo 및 procsize는 아직 지원되지 않지만 매우 유용한
HP WTEC 도구입니다.
glance 및 shminfo 정도만 사용할 수 있어도 시스템 메모리 사용량을
간단하게 분석할 수 있습니다.
glance - 시스템 메트릭 모니터링을 완전히 지원하는 HP 제품입니다.
HP-UX 응용 프로그램 미디어에서 시험용 버전 및 라이센스 버전을
사용할 수 있습니다.
shminfo - 사용 가능한 사분면의 리소스 맵을 기반으로 공유 메모리
사용량을 보고합니다.
다음 HP 외부 ftp 사이트에서 다운로드할 수도 있습니다.
ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs/shminfo/shminfo
kmeminfo - HP-UX 커널의 메모리 사용량을 자세히 표시합니다.
HP 응답 센터를 통해 얻을 수 있습니다.
procsize - 시스템에서 수행되는 모든 프로세스의 메모리 사용량을
표시합니다.
HP 응답 센터를 통해 얻을 수 있습니다.
주: hprc.external.hp.com에서 실행할 수 있는 shminfo는 최신 버전이
아닐 수도 있습니다. 지원되지 않는 각 도구의 현재 복사본 및 사용법에
대한 도움말이 필요하면 HP 응답 센터에 문의하십시오.
2. 시스템 정보를 수집합니다.
2.1.
시스템 모델을 기록합니다.
모델 번호
2.2.
OS 버전과 32비트인지 64비트인지 여부를 확인합니다.
# uname -a
#getconf KERNEL_BITS
2.3.
현재 스왑 공간(페이징 영역) 구성을 결정합니다. 계산해야 할 디스크에
페이징된 메모리가 있습니까?
# swapinfo -tm
2.4.
메모리 사용과 관련된 조정 가능한 커널 매개변수의 값을 기록합니다.
nbuf 및 bufpages: 두 값 모두 0으로 설정하면 시스템이 버퍼 캐시의
크기를 동적으로 조정합니다. 그렇지 않으면 버퍼 캐시의 크기가 고정됩니다.
dbc_min_pct 및 dbc_max_pct: 동적 버퍼 캐시 크기를 사용하는 시스템에서
이러한 매개변수는 각각 최소 및 최대 버퍼 캐시 크기를 RAM의 백분율로
설정하는 데 사용됩니다.
2.5.
응용 프로그램이 32비트와 64비트 중 어떤 것으로 실행됩니까, 아니면
둘 다입니까? 응용 프로그램 개발자 및 DBA에 확인해 보십시오.
3. 계산해야 할 현재 사용 중인 메모리가 어느 정도인지 확인합니다.
swapinfo -tm에 의해 디스크에 페이징된 메모리가 있습니까? 있다면
어느 정도입니까?
Glance 또는 dmesg 및/또는 adb와 함께 다음 절차 중 하나를 사용하여
사용 중인 실제 메모리가 어느 정도인지 확인합니다.
3.1.
glance에서 메모리 보고서로 이동합니다.
Glance의 텍스트 모드에서 "메모리 보고서"를 클릭합니다. 또는 단축 키
"m"을 입력합니다.
주: Shift-?를 클릭하면 glance의 모든 단축 키가 표시됩니다.
gpm으로 시작하는 Glance의 GUI 형식에서 "보고서" 풀다운 메뉴를 사용합니다.
"메모리 정보"를 클릭한 다음 "메모리 보고서"를 클릭합니다.
실제 메모리(Phys Mem) 및 사용 가능한 메모리(Free Mem)를 기록합니다.
사용된 RAM의 양을 확인하려면 실제 메모리에서 사용 가능한 메모리를 뺍니다.
메모리가 디스크로 페이징되면 계산할 전체 [가상] 메모리 사용량에 이
메모리 양을 추가합니다.
3.2.
Glance의 텍스트 또는 GUI 형식을 사용할 수 없는 경우에는 dmesg 및 adb와
같은 다른 도구를 사용합니다.
다음 dmesg 및 adb 예제는 98Mb RAM 중 약 88Mb가 사용 중인 모델 712/60
워크스테이션의 예입니다.
# dmesg | grep Physical
Physical: 98304 Kbytes, lockable: 64752 Kbytes, available: 77708 Kbytes
# echo freemem/D | adb /stand/vmunix /dev/kmem
freemem:
freemem: 2500
# bc <-- 명령줄 계산기 시작
2500*4096
10240000 <-- 각각 4096바이트로 된 2500 페이지에 10.24Mb의
여유 공간이 있음
qu
메시지 버퍼가 닫혀서 dmesg가 더 이상 시스템의 실제 메모리 양을 표시하지
않는 경우 ITRC 문서 UPERFKBAN00000726에서 다음 adb 절차를 사용할 수도
있습니다. 이러한 명령의 각 출력은 4096바이트 페이지입니다.
HP-UX 10.X의 경우
예제:
# echo physmem/D | adb /stand/vmunix /dev/kmem
physmem:
physmem: 24576
32비트 아키텍처에서 실행되는 HP-UX 11.X 시스템의 경우
예제:
# echo phys_mem_pages/D | adb /stand/vmunix /dev/kmem
phys_mem_pages:
phys_mem_pages: 24576
64비트 아키텍처에서 실행되는 HP-UX 11.X 시스템의 경우
예제:
# echo phys_mem_pages/D | adb64 /stand/vmunix /dev/mem
phys_mem_pages:
phys_mem_pages: 262144
예제에서는 glance 메모리 보고서에서 약 2.9Gb의 메모리가 사용 중이라고
표시하며(실제 메모리가 사용 가능한 메모리보다 작음) 메모리는 디스크로
페이징되지 않습니다.
이 시점부터는 사용 중인 서로 다른 메모리 유형의 총 사용량을 계속해서
식별합니다.
4.
동일한 glance 메모리 보고서에서 시스템/커널 및 버퍼 캐시가 사용하는
메모리 양을 확인합니다.
1500 Mbyte 버퍼 캐시 (Buf Cache)
94 Mbyte 시스템 메모리 (Sys Mem)
보고된 "시스템 메모리"의 양은 고정 시스템 메모리와 특정한 유형의 동적
시스템 메모리를 더한 값으로, 버퍼 캐시는 포함되지 않습니다. 커널이
시스템 메모리를 사용하는 방법에 대한 자세한 내용은 아직 지원되지
않지만 매우 유용한 WTEC kmeminfo 도구를 참조하십시오. 현재로서는
"Sys Mem" 값이면 충분합니다.
주: 1500Mb는 매우 큰 버퍼 캐시입니다. 기가바이트 또는 더 많은 메모리를
버퍼 캐시에서 다른 용도로 제공할 수도 있습니다.
2900Mb 중 1594Mb가 예제에서 지금까지 사용된 양이며 1306Mb는 아직
계산되지 않았습니다.
4.1.
glance, gpm 또는 kmeminfo가 시스템에 없으면 다음 adb 명령을 사용하여
버퍼 캐시에 사용된 메모리 양을 확인합니다. 출력은 4096바이트 페이지입니다.
# echo bufpages/D | adb /stand/vmunix /dev/kmem
bufpages:
bufpages: 1994
명령줄 계산기를 사용하여 4096바이트 페이지를 바이트로 변환할 수 있습니다.
# bc
1994*4096
8167424
qu
5. 시스템의 공유 메모리 사용량을 확인합니다.
예제에서 2900Mb 중 1594Mb(버퍼 캐시 + 시스템 메모리)가 계산되고 1306Mb는
아직 계산되지 않았습니다.
Unix 시스템에서 데이터베이스가 실행 중인 경우 많은 양의 공유 메모리가
사용되는 것은 일상적인 일입니다. 시스템에서 사용 중인 공유 메모리 유형은
공유 메모리 세그먼트, 공유 메모리 매핑 파일(프로세스 데이터 세그먼트에
있는 개인 메모리 매핑 파일과 반대) 및 공유 라이브러리입니다.
'ipcs -ma'를 실행하여 사용 중인 공유 메모리 세그먼트를 확인할 수 있습니다.
그런 다음 SEGSZ 열의 합계를 계산하거나 ipcs 출력을 세그먼트 크기별로
정렬합니다.
예를 들어, 공유 메모리 세그먼트를 큰 크기부터 작은 크기 순으로
나열하려면(열 번째 순위/열은 SEGSZ): 다음과 같이 입력합니다.
# ipcs -ma | sort -rnk10 | more
'ipcs -ma' 명령은 공유 메모리 세그먼트만 표시합니다. 한 보고서에서
모든 공유 메모리 유형 목록을 보려면 아직 지원되지 않지만 매우 유용한
shminfo라는 WTEC 유틸리티 복사본을 사용합니다.
기본적으로 shminfo는 32비트 전역 창을 표시합니다. -64비트 옵션을 사용하면
shminfo는 64비트 전역 창을 표시합니다.
shminfo 출력은 공유 메모리 세그먼트를 "SHMEM" 유형으로 식별하는 반면
공유 메모리 매핑 파일 및 공유 라이브러리는 "OTHER" 유형으로 식별됩니다.
shminfo 출력은 사분면 수를 포함하여 각 공유 메모리 유형의 메모리에서
위치를 식별합니다.
먼저 사분면 3(Q3) 및 4(Q4)를 확인합니다. 공유 메모리는 사분면 2(Q2)에서
발견될 수도 있지만 이는 특별히 컴파일된 프로세스(SHMEM_MAGIC 실행 가능
유형)에만 해당됩니다.
전역 창의 Q2, Q3 또는 Q4에서 발견되는 모든 공유 메모리 세그먼트(SHMEM)
및 OTHER 영역(공유 라이브러리 및 메모리 매핑 파일은 "OTHER" 유형으로
표시)의 크기를 모두 더합니다.
다음 예제에서 shminfo 발췌문은 전역 Q2 및 Q3이 전혀 사용되지 않았음을
나타냅니다. 반면 전역 Q4에는 SHMEM 유형 1364KB(1.364Mb) 및 OTHER 유형
8720KB(8.72Mb)가 포함됩니다.
전역 32비트 공유 사분면:
===============================
Space Start End Kbytes Usage
Q2 0x000009bb.0x40000000-0x7ffe6000 1048472 FREE
Q3 0x00000000.0x80000000-0xc0000000 1048576 FREE
Q4 0x00000000.0xc0000000-0xc05b9000 5860 OTHER
Q4 0x00000000.0xc05b9000-0xc06f3000 1256 SHMEM id=0
Q4 0x00000000.0xc06f3000-0xc0708000 84 OTHER
Q4 0x00000000.0xc0708000-0xc0709000 4 SHMEM id=1
Q4 0x00000000.0xc0709000-0xc0711000 32 SHMEM id=2 locked
Q4 0x00000000.0xc0711000-0xc0713000 8 SHMEM id=3
Q4 0x00000000.0xc0713000-0xc0884000 1476 OTHER
Q4 0x00000000.0xc0884000-0xc0894000 64 SHMEM id=4
Q4 0x00000000.0xc0894000-0xc08d9000 276 OTHER
Q4 0x00000000.0xc08d9000-0xc08e2000 36 FREE
Q4 0x00000000.0xc08e2000-0xc08fe000 112 OTHER
Q4 0x00000000.0xc08fe000-0xc0901000 12 FREE
Q4 0x00000000.0xc0901000-0xc09e5000 912 OTHER
Q4 0x00000000.0xc09e5000-0xc09eb000 24 FREE
시스템에서 메모리 창이 사용 중이면 이러한 창의 개별 사분면 Q2 및
Q3(shminfo 출력의 개별 섹션)에 있는 공유 메모리를 모두 더합니다.
다음 예제에서 shminfo 발췌문은 사용 가능한 두 메모리 창에서 개별 Q2
및 Q3 사분면이 전혀 사용되지 않음을 나타냅니다. max_mem_window 커널
조정 가능 매개변수를 "2"로 설정하여 전역 창뿐 아니라 메모리 창 2개를
사용할 수 있으므로 이 예제 시스템에서 사용할 수 있는 메모리 창은
2개입니다.
# kmtune | grep win
max_mem_window 2
다음은 메모리 창 정보를 나타내는 shminfo의 발췌문입니다.
Shared space from Window index 1 (unused): <-- 첫 번째 창입니다.
Space Start End Kbytes Usage
Q2 0x00007194.0x40000000-0x7ffeffff 1048512 FREE
Q3 0x00001973.0x80000000-0xbfffffff 1048576 FREE
Shared space from Window index 2 (unused): <-- 두 번째 창입니다.
Space Start End Kbytes Usage
Q2 0x00003156.0x40000000-0x7ffeffff 1048512 FREE
Q3 0x0000094e.0x80000000-0xbfffffff 1048576 FREE
이 예제에서는 shminfo에 SHMEN 유형 1000Mb, OTHER 유형 50Mb가 사용
중이라고 표시됨을 나타냅니다. 이를 다음과 같이 총 사용량에 더합니다.
2900 Mbyte 메모리 사용
1500 Mbyte 버퍼 캐시
94 Mbyte 시스템 메모리
1000 Mbyte 공유 메모리 세그먼트(shminfo의 SHMEM 유형)
50 Mbyte 메모리 매핑 파일 및 공유 라이브러리(shminfo의 OTHER 유형)
지금까지 2900Mb 중 2644Mb가 계산되었습니다. 나머지 256Mb는 다음
프로세스 메모리에서 확인합니다.
6. 시스템에서 실행 중인 개별 프로세스가 텍스트, 데이터 및 메모리 스택
영역을 어떻게 사용하는지 확인합니다.
ps 명령을 사용하여 적절한 범위를 구할 수도 있습니다. 지원되지 않는
HP WTEC procsize 유틸리티를 사용할 수도 있습니다.
ps 및 procsize 명령 사용 예제는 아래와 같습니다.
6.1.
ps -el 출력의 SZ 열은 4096바이트 페이지에서 각 프로세스 텍스트, 데이터
및 스택 영역에서 사용된 총 메모리 양을 나타냅니다.
ps -el | sort -rnk10을 실행하면 시스템에서 실행되는 모든 프로세스가
SZ 열을 기준으로 정렬되어 나열됩니다.
다음 awk 스크립트와 사용 예제는 SZ 열에서 모든 값의 합계를 내는 작업을
단순화합니다.
#!/usr/bin/awk -f
{
total=total+$1
}
END {
print total
}
이 스크립트를 다른 이름으로 저장한 경우(예: 실행 권한이 있는 "summ"이라는
파일) 다음과 같이 사용하여 ps -el 출력의 열 10(SZ 열)에 있는 모든 값의
합계를 계산할 수 있습니다. 결과는 4096바이트 페이지입니다.
예제(열 10은 SZ 데이터):
# ps -el | awk -F' ' '{print $10}' | ./summ
61048
결과에 4096바이트 페이지 크기를 곱합니다.
다른 예:
# ps -el | awk -F' ' '{print $10}' | ./summ
4.81781 E+06
<-- 결과는 4096바이트 페이지 크기에 4817810 페이지("E+06"에서 소수점이
오른쪽으로 여섯 자리 이동)를 곱한 값 또는 약 19.73Gb입니다.
19.73Gb는 큰 수치로서 허용 가능한 범위가 아닐 수도 있습니다.
다음은 추가 설명입니다.
# ps -el | wc -l
810
한 작업에 평균 24Mb 정도를 사용하는 프로세스가 시스템 전체에서
총 810개입니다. 이것은 모두 개인 메모리는 아닐 것이므로 Glance를
더 살펴보는 것이 좋습니다. 예를 들어, 한 프로세스에서 각각 동일한
2Mb 데이터 세그먼트를 공유하는 인스턴스가 700개일 수도 있습니다.
동일한 프로세스의 여러 인스턴스가 각각 많은 양의 개인 메모리를
사용하거나 이전에 알려진 것보다 더 많은 양을 사용하는 경우에는
개발자나 공급업체에 문의하여 관련 응용 프로그램의 리소스 요구사항을
설명하는 것이 좋습니다. 아니면 프로세스별 메모리 요구사항은 정상인데
단순히 더 많은 프로세스 인스턴스를 실행하는 사용자가 더 많아진
것일 수도 있습니다.
아래 설명한 대로 glance 프로세스 메모리 영역 보고서 또는 지원되지
않는 WTEC procsize 유틸리티를 사용하여 각 프로세스의 어떤 메모리
영역이 공유되며 어떤 영역이 개인 영역인지 확인할 수 있습니다.
하나 이상의 프로세스에서 공유되는 메모리는 실행 합계에서 한 번만
계산됩니다.
6.2)
Glance 프로세스 메모리 영역 보고서를 사용하려면
문제의 프로세스(실행 중인 인스턴스를 많이 포함하는 프로세스)의
PID를 기록합니다.
glance를 시작합니다.
"프로세스 선택"을 클릭하거나 "s" 선택 단축 키를 사용합니다.
프롬프트에서 PID를 입력합니다.
"메모리 영역"을 클릭하거나 "M" 프로세스 메모리 영역 단축 키를 사
용합니다.
다음은 glance 프로세스 메모리 영역 목록의 발췌문입니다.
TEXT /Shared na 404kb 444kb na <--
공유 메모리이므로 한 번만 계산됩니다.
DATA /Priv na 2.0mb 2.0mb na <--
개인 메모리이므로 실행 중인 총합에 추가합니다.
STACK /Priv na 40kb 120kb na <--
개인 메모리이므로 실행 중인 총합에 추가합니다.
시스템의 총 SZ 수가 계산할 총 수보다 크면 SZ 열에 나열되는 메모리
대부분을 프로세스에서 공유할 것입니다. 이 경우 아래 설명한 procsize
유틸리티를 사용하여 프로세스 메모리 사용량을 보다 잘 식별할 수
있습니다.
6.3.
다음은 지원되지 않는 HP WTEC procsize 유틸리티 사용 예제입니다.
주: procsize 출력에 표시된 단위는 4096바이트 페이지입니다.
다음 명령줄은 모든 프로세스의 메모리 영역을 나타내며 공유 영역은
한 번만 표시합니다. 이는 VSS(가상 집합 크기)가 아니라 메모리에
실제로 있는 RSS(상주 집합 크기)입니다. -R과 -V를 모두 지정한 경우
RSS와 VSS 데이터가 모두 표시될 수 있습니다. 기본값은 VSS입니다.
# ./procsize -Rfn
"-R"은 기본 VSS(가상 집합 크기)가 아닌 RSS(상주 집합 크기) 정보를
나타냅니다.
"-f"는 모든 프로세스에 대해 보고합니다.
"-n"은 영역을 사용하는 첫 번째 프로세스에 대해 영역을 한 번만
계산하도록 합니다. 기본 동작은 공유 영역이 발견될 때마다 보고하는
것입니다. 공유되는 영역과 공유되지 않는 영역을 확인하기 위해 이
플래그를 사용하거나 사용하지 않고 procsize를 실행할 수 있습니다.
다음은 procsize 출력의 발췌문 예제입니다. procsize 자체는 약
9.8Mb(2414 페이지)의 메모리를 사용합니다. 열 3의 "r"은 RSS 값이
표시됨을 나타냅니다.
# ./procsize -Rfn
libp4 (6.93): Opening /stand/vmunix /dev/kmem
regions set to 1000
hpux 11.00 32 bit in Narrow mode
nproc=276
pid Comm UAREA TEXT DATA STACK SHMEM IO MMAP Total
0 swapper r 0 0 0 0 0 0 0 0
1 init r 4 61 24 10 0 0 0 100
2 vhand r 4 0 0 0 0 0 0 4
...
5237 gpm r 4 218 1464 12 0 0 187 1885
23828 dtsession r 4 17 64 2 0 0 50 137
29565 procsize r 4 49 328 6 0 0 2027 2414
23876 dtfile r 0 0 0 0 0 0 0 0
5233 dtexec r 4 4 1 2 0 0 1 12
23880 dtexec r 4 0 0 0 0 0 0 4
23885 netscape r 4 47 53 1 0 0 8 113
시스템의 숫자가 사용 중인 메모리 양과 비슷하지 않은 경우에는
kmeminfo 커널 메모리 도구와 같은 도구를 사용하여 보다 자세히
확인할 수 있습니다. 다음은 자세한 내용입니다.
이 예제에서 ps 명령 SZ 열의 누적 합계는 61035 페이지 또는 약 250Mb입니다.
2900 Mbyte 메모리 사용
1500 Mbyte 버퍼 캐시
94 Mbyte 시스템 메모리
1000 Mbyte 공유 메모리
40 Mbyte 메모리 매핑 파일
10 Mbyte 공유 라이브러리
250 Mbyte 프로세스 텍스트+데이터+스택
====
2894
2900Mb 중 2894Mb가 계산되었습니다. 버퍼 캐시가 1500Mb이면 매우
큰 것이며 Gb 이상 크기를 줄일 수도 있습니다. 1000Mb 공유 메모리는
특히 데이터베이스가 실행 중인 경우 전혀 행에서 벗어나지 않을
것입니다. 또한 데이터베이스가 실행 중인 경우에는 버퍼 캐시 크기를
제한함으로써 비워지는 메모리가 데이터베이스에 의해 공유 메모리로
사용되도록 하는 방법을 고려할 수 있습니다.
250Mb 프로세스 텍스트+데이터+스택의 대부분(예: 200Mb 정도)이 실제로
공유되고 있을 것입니다. 아직 계산되지 않은 6Mb와 합치면 커널은
206Mb를 사용하는 것이 됩니다. 이 정도면 과도한 양은 아닙니다.
7. HP-UX 커널이 메모리를 어떻게 사용하는지 확인합니다.
예제에서는 다른 206Mb의 사용된 메모리가 계산되어야 합니다.
사용하기에 적합한 도구는 kmeminfo입니다.
kmeminfo를 실행하는 경우에는 kmeminfo 데이터에 대한 충분한 이해를
위해 HP 응답 센터에 도움을 청하는 것이 좋습니다.
현재 예제에서 커널이 사용하는 206Mb는 행에서 벗어나지 않을 것입니다.
시스템이 사용되는 방법에 따라 수백 Mb가 행에서 벗어나지 않을 수도
있습니다.
"커널이 사용한"이라는 말은 일반적으로 사용자 리소스를 관리하고
시스템에서 실행되는 여러 프로세스의 메모리 요청을 만족시키기 위해
커널이 처리하는 메모리를 의미합니다. 일부 커널 메모리는 부팅할 때
정적으로 크기가 조정되며 일부는 부팅 후에 동적으로 크기가 조정됩니다.
프로세스마다 서로 다른 명칭으로 메모리를 요청하는 경향이 있습니다.
예를 들어, 서로 다른 커널 메모리 "버킷" 또는 "어레나"를 사용합니다.
예를 들어, HP-UX 11.0에서 시작하면 JFS는 2Kb의 메모리를 사용하므로,
커널은 2048바이트 요청을 만족시키기 위해 4096바이트 페이지의 메모리를
축적하게 됩니다. HP-UX 10.20에서 JFS가 1Kb의 메모리를 사용했다면
kmeminfo는 이 작업을 "1Kb 커널 버킷"에 반영합니다.
HP-UX 11i에서 시작하면 기본 kmeminfo 출력은 커널 메모리 "버킷"이
아닌 "어레나"에 대한 정보를 표시합니다. 서로 다른 프로세스의 메모리
작업이 서로 다른 어레나의 증감 시에 반영됩니다.
메모리는 Super Page Pool을 사용하여 어레나를 처리합니다. 수퍼 페이지는
그 일부를 어레나가 사용하고 있는 한 Super Page Pool에 남아 있습니다.
이상적으로는 커널 버킷/어레나 또는 Super Page Pool의 메모리 양은
최소가 되어야 합니다. 그러나 특정 버킷/어레나에서 메모리 양을
확인하는 자체가 메모리 소모는 아님을 알아두어야 합니다. 메모리
소모란 무언가가 시간이 가면서 감소하지 않고 증가하고 있음을 의미합니다.
특정 버킷/어레나에서 메모리 사용량이 과도한 것은 커널 또는 응용
프로그램을 조정할 필요가 있음을 의미합니다.
Super Page Pool에서 과도한 메모리 사용은 HP-UX 패칭을 통해 해결할
문제가 있음을 의미합니다.
이와 관련된 문제나 의문점이 있으면 HP 응답 센터에 문의하십시오.
다음 kmeminfo 발췌문(4096바이트 페이지의 값)은 약 268Mb RAM의 시스템을
표시합니다. 메모리 중 232Mb가 사용 중이며 51Mb는 사용자 프로세스,
184Mb는 커널에 의해 사용됩니다. "커널"이 사용하는 184Mb 중 134Mb는
버퍼 캐시, 27Mb는 동적 커널 버킷, 22Mb는 정적 구조, 즉 시스템 테이블의
몫입니다.
실제 메모리 사용 요약(페이지):
Physmem = 65536 사용 가능한 실제 메모리:
Freemem = 8765 빈 실제 메모리
Used = 56771 사용된 실제 메모리:
System = 45015 커널에 사용:
Static = 5373 텍스트 및 정적 데이터에 사용
Dynamic = 6730 동적 데이터에 사용
Bufcache = 32768 파일 시스템 버퍼 캐시에 사용
Eqmem = 16 이에 상당하는 매핑 페이지 풀에 사용
SCmem = 128 시스템 고유의 페이지 풀에 사용
User = 12490 사용자 프로세스에 사용
Uarea = 460 스레드 영역에 사용
동일한 kmeminfo 출력의 다른 발췌문에서 27Mb의 동적 커널 메모리
사용은 다음으로 세분화됩니다. 약 11Mb는 커널 버킷에 사용되며
(2671 페이지 * 4096바이트 페이지 크기), 1Kb 크기의 버킷 10
(656 페이지 * 4096바이트 페이지 크기)에 가장 많은 약 2.7Mb의
양이 축적됩니다.
동적 메모리 사용 요약(페이지):
Dynamic = 6730 커널 동적 데이터(sysmap):
MALLOC = 2671 메모리 버킷:
bucket[ 5] = 179 size 32 bytes
bucket[ 6] = 25 size 64 bytes
bucket[ 7] = 282 size 128 bytes
bucket[ 8] = 164 size 256 bytes
bucket[ 9] = 190 size 512 bytes
bucket[10] = 656 size 1024 bytes
bucket[11] = 340 size 2048 bytes
bucket[12] = 387 size 4096 bytes
bucket[13] = 30 size 2 pages
bucket[14] = 21 size 3 pages
bucket[15] = 20 size 4 pages
bucket[16] = 5 size 5 pages
bucket[17] = 18 size 6 pages
bucket[18] = 0 size 7 pages
bucket[19] = 56 size 8 pages
bucket[20] = 298 size > 8 pages
Kalloc = 4003 kalloc()
Eqalloc = 45 eqalloc()
Reserved = 11 예약된 풀
134Mb 버퍼 캐시는 RAM의 절반입니다. 동적 버퍼 캐시 증가의
상한을 제어하는 dbc_max_pct 커널 조정 가능 매개변수의 기본값은
50 [퍼센트]입니다. 메모리가 작은 시스템에서는 이 정도면 충분할
수 있습니다. 사용 가능한 메모리는 약 36Mb입니다. 사용자 프로세스의
데이터 세그먼트와 같이 다른 위치에서 메모리가 필요한 경우 버퍼
캐시 크기를 더 작게 설정할 수도 있습니다. 이를 변경하기 전에
sar -b를 사용하거나 glance 디스크 보고서("Local" "Logl Rds" 및
"Logl Wts" 행의 백분율 열 아래)에서 버퍼 캐시 사용량을
모니터링하십시오. 또는 시스템이 디스크에 페이징되도록 할 수도
있습니다. 나중에는 커널이 최근에 사용되지 않은 메모리 페이지만
페이징하게 됩니다.
8. 아직도 시스템에서 메모리 사용을 모두 확인할 수 없습니까?
커널의 메모리 사용을 확인할 수 있는 보다 직관적인 방법이 있습니다.
위에 나열된 대로 수행한 후에도 메모리가 사용되는 정확한 위치를
확인하지 못한 경우에는 HP 응답 센터에 문의하십시오.
*************************************************************************************
.........following with all English text ....
KBRC00011764How to account for memory usage on an HP-UX system
Problem Description
How to account for memory usage on an HP-UX system
Configuration Info
Solution
1. Obtain the tools that will make this analysis easier.
Start with shminfo and glance.
shminfo, kmeminfo and procsize are unsupported yet very useful HP WTEC tools.
Having at least glance and shminfo available will simplify the analysis of
system memory usage.
glance - Fully supported HP product for monitoring system metrics.
Trial and licensed copies are available on the HP-UX application media.
shminfo - Reports shared memory usage based on the resource maps of available
quadrants. May be downloaded from the following HP external ftp site.
ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs/shminfo/shminfo
kmeminfo - Shows details of memory usage by the HP-UX kernel.
Obtain through the HP Response Center
procsize - Shows memory usage of all processes on the system.
Obtain through the HP Response Center
Note: The shminfo executable at hprc.external.hp.com may not be the latest
version. For the current copies of each unsupported tool, and for assistance
in their use, contact the HP Response Center.
2. Collect system information
2.1.
Note system model:
# model
2.2.
Identify the OS version, and whether it's 32-bit or 64-bit.
# uname -a
# getconf KERNEL_BITS
2.3.
Determine the current swap space (paging area) configuration. Is there any
memory paged out to disk that needs to be accounted for?
# swapinfo -tm
2.4.
Note the value of some tunable kernel parameters that relate to memory usage.
nbuf & bufpages: If both are set to zero then system is dynamically sizing
buffer cache - else the buffer cache is statically fixed in size.
dbc_min_pct & dbc_max_pct: On systems using dynamic buffer cache sizing
these parameters are used to set minimum and maximum buffer cache size,
respectively, as a percentage of RAM.
2.5.
Are applications running as 32-bit, 64-bit, or both? Check with application
developers and DBA's for help in determining this.
3. Determine how much memory is presently in use that needs to be accounted
for.
Is there any memory paged out to disk as per swapinfo -tm? How much?
Use one of the following procedures with either Glance, or with dmesg
and/or adb to identify how much of physical memory is in use.
3.1.
Go to the memory report in glance.
In the text mode of Glance, click on "Memory Report". Or enter the short-cut
key "m".
Note: Shift-? shows all glance short-cut keys.
In the GUI form of Glance started with gpm, use the "Reports" pull-down
menu. Click on "Memory Info", then "Memory Report".
Note the physical memory (Phys Mem) and the free memory (Free Mem).
To determine the amount of RAM used, subtract free memory from physical memory.
If any memory is paged out to disk, then add that amount to the total of
[virtual] memory usage to be accounted for.
3.2.
If the text or GUI form of Glance is not available, then use other tools such
as dmesg and adb.
The following examples of dmesg and adb are from a model 712/60
workstation where around 88 out of 98 Mb RAM is in use.
# dmesg | grep Physical
Physical: 98304 Kbytes, lockable: 64752 Kbytes, available: 77708 Kbytes
# echo freemem/D | adb /stand/vmunix /dev/kmem
freemem:
freemem: 2500
# bc
<-- Start the command line calculator
2500*4096
10240000 <-- 2500 pages of 4096 bytes each is 10.24 Mb free
qu
If the message buffer has wrapped around and dmesg is no longer
displaying the amount of physical memory on the system, then the following
adb procedures from ITRC document UPERFKBAN00000726 might be used. The
output of each of these commands will be in 4096-byte pages.
For HP-UX 10.X
Example:
# echo physmem/D | adb /stand/vmunix /dev/kmem
physmem:
physmem: 24576
For HP-UX 11.X systems running on 32 bit architecture:
Example:
# echo phys_mem_pages/D | adb /stand/vmunix /dev/kmem
phys_mem_pages:
phys_mem_pages: 24576
For HP-UX 11.X systems running on 64 bit architecture:
Example:
# echo phys_mem_pages/D | adb64 /stand/vmunix /dev/mem
phys_mem_pages:
phys_mem_pages: 262144
For the ongoing example, the glance memory report is showing around 2.9 Gb
of memory in use (Phys Mem less Free Mem), and no memory is paged out to
disk.
From this point on continue to keep a running total as the different types of
memory in use are identified.
4.
From the same glance memory report, note how much memory the system/kernel and
buffer cache are using.
1500 Mbyte buffer cache (Buf Cache)
94 Mbyte system memory (Sys Mem)
The amount of "Sys Mem" reported is static system memory plus certain types of
dynamic system memory, not including the buffer cache. For a more detailed view
of how the kernel is using system memory refer to the unsupported yet very
useful WTEC kmeminfo tool. But for now, the "Sys Mem" value is sufficient.
Note: 1500 Mb is an overly large buffer cache. Most likely, a Gigabyte or more
of memory could be freed from the buffer cache to other uses.
1594 out of 2900 Mb has been so far accounted for in the ongoing example,
leaving 1306 Mb yet to account for.
4.1.
If glance, gpm or kmeminfo are not on the system then use
the following adb command to identify the amount of memory used in the
buffer cache. The output will be in 4096-byte pages.
# echo bufpages/D | adb /stand/vmunix /dev/kmem
bufpages:
bufpages: 1994
The command line calculator may be used to convert 4096-byte pages to bytes:
# bc
1994*4096
8167424
qu
5. Look at the shared memory usage on the system.
At this point in the example 1594 Mb have been accounted for (buffer cache +
system memory) out of 2900 Mb, with 1306 Mb yet to be accounted for.
It is not uncommon to see signficant amounts of shared memory in use on a Unix
system - especially if a database is running. The types of shared memory
in use on a system may be shared memory segments, shared memory mapped files
(as opposed to private memory mapped files found in a processes data segment)
and shared libraries.
`ipcs -ma` might be run to see what shared memory segments are in use. Then
either total the SEGSZ column, or sort the ipcs output by segment
size.
For example, to simply list shared memory segments from largest to smallest
(10th rank/column is SEGSZ):
# ipcs -ma | sort -rnk10 | more
The `ipcs -ma` command just shows shared memory segments. To see a listing of
all shared memory types in one report, obtain a copy of an unsupported yet very
useful WTEC utility called shminfo.
By default, shminfo looks at the 32-bit global window. Using the -64bit option
tells shminfo to look at the 64-bit global window.
The shminfo output will identify shared memory segments as type "SHMEM", while
shared memory mapped files and shared libraries will be identified as
type "OTHER".
The shminfo output identifies the location in memory of each shared memory
type, including quadrant number.
Look primarily in quadrants 3 (Q3) and 4 (Q4). Shared memory might also be
found in quadrant 2 (Q2), but only for specially compiled processes
(SHMEM_MAGIC executable types).
Add together the size of all shared memory segments (SHMEM) and OTHER areas
(shared libraries and memory mapped files show at type "OTHER") that are found
in Q2, Q3 or Q4 of the global window.
In the following sample shminfo excerpt note that global Q2 and Q3 are
completely unused. While Global Q4 has 1364 Kbytes of type SHMEM (1.364 Mb),
and 8720 Kbytes (8.72 Mb) of type OTHER.
Global 32-bit shared quadrants:
===============================
Space Start End Kbytes Usage
Q2 0x000009bb.0x40000000-0x7ffe6000 1048472 FREE
Q3 0x00000000.0x80000000-0xc0000000 1048576 FREE
Q4 0x00000000.0xc0000000-0xc05b9000 5860 OTHER
Q4 0x00000000.0xc05b9000-0xc06f3000 1256 SHMEM id=0
Q4 0x00000000.0xc06f3000-0xc0708000 84 OTHER
Q4 0x00000000.0xc0708000-0xc0709000 4 SHMEM id=1
Q4 0x00000000.0xc0709000-0xc0711000 32 SHMEM id=2 locked
Q4 0x00000000.0xc0711000-0xc0713000 8 SHMEM id=3
Q4 0x00000000.0xc0713000-0xc0884000 1476 OTHER
Q4 0x00000000.0xc0884000-0xc0894000 64 SHMEM id=4
Q4 0x00000000.0xc0894000-0xc08d9000 276 OTHER
Q4 0x00000000.0xc08d9000-0xc08e2000 36 FREE
Q4 0x00000000.0xc08e2000-0xc08fe000 112 OTHER
Q4 0x00000000.0xc08fe000-0xc0901000 12 FREE
Q4 0x00000000.0xc0901000-0xc09e5000 912 OTHER
Q4 0x00000000.0xc09e5000-0xc09eb000 24 FREE
If memory windows are in use on the system then also add together the shared
memory found in the private quadrants Q2 and Q3 of those windows (a separate
section of shminfo output).
In the following sample shminfo excerpt note that private Q2 and Q3 quadrants
are completely unused in two available memory windows. There are two memory
windows available on this example system because the max_mem_window kernel
tunable was set to "2" (allowing two memory windows in addition to the global
window).
# kmtune | grep win
max_mem_window 2
Here's an excerpt from shminfo showing memory windows information.
Shared space from Window index 1 (unused):
<-- Here's the first window
Space Start End Kbytes Usage
Q2 0x00007194.0x40000000-0x7ffeffff 1048512 FREE
Q3 0x00001973.0x80000000-0xbfffffff 1048576 FREE
Shared space from Window index 2 (unused): <-- Here's the second window
Space Start End Kbytes Usage
Q2 0x00003156.0x40000000-0x7ffeffff 1048512 FREE
Q3 0x0000094e.0x80000000-0xbfffffff 1048576 FREE
In this running example pretend that shminfo showed a total of 1000 Mb of type
SHMEM in use, and 50 Mb of type OTHER. Add that into the running total as
follows...
2900 Mbyte memory used
1500 Mbyte buffer cache
94 Mbyte system memory
1000 Mbyte shared memory segments (type SHMEM in shminfo)
50 Mbyte memory mapped files and shared libraries (type OTHER in shminfo)
So far accounted for are 2644 out of 2900 Mb. For the remaining 256 Mb look
next at process memory.
6. See how the individual processes running on the system use text, data and
stack areas of memory.
The ps command may be used to get a decent ballpark total. The unsupported HP
WTEC procsize utility might also be used.
Examples of ps and procsize command usage are shown below.
6.1.
The SZ column in ps -el output indicates in 4096-byte pages, the total
amount of memory used in each processes text, data and stack areas.
Running ps -el | sort -rnk10 will list all processes on the system,
sorted by the SZ column.
The following awk script with usage example simplifies the task of totaling all
values in the SZ column:
#!/usr/bin/awk -f
{
total=total+$1
}
END {
print total
}
If this script were saved as, for example a file called "summ" with execute
permissions, then it could be used as follows to total all values found in
column 10 of ps -el output (the SZ column). The result is in 4096-byte
pages.
One example (column 10 is the SZ data):
# ps -el | awk -F' ' '{print $10}' | ./summ
61048
Multiply the the result by the 4096-byte page size.
Another example:
# ps -el | awk -F' ' '{print $10}' | ./summ
4.81781 E+06
<-- That's 4817810 pages (decimal point moved right six
places for "E+06") multiplied by a 4096-byte page
size, or about 19.73 Gb
19.73 Gb is a large number ie might not be an acceptable ball park number -
look further...
# ps -el | wc -l
810
That's 810 total processes on the system using an average of about 24 Mb a
piece. This is probably not all private memory, so look further with Glance eg
there might be 700 instances of a process each sharing the same 2 Mb data
segment. If many instances of the same process were each using a large amount
of private memory, or a larger amount than they had previously been known to
use, then it would be appropriate to ask the developer or vendor to explain the
resource requirements of the related application. Or perhaps the per-process
memory requirements are normal and there are simply many more users running
many more instances of the process.
Either the glance process memory region report or the unsupported WTEC procsize
utility might be used (both discussed below) to determine which memory regions
of each process are shared and which are private. Memory that is shared between
more than one process should only be counted once in the running total.
6.2)
To use the Glance process memory regions report:
Note the PID of a process in question eg one that has many running instance's.
Start glance.
Click on "Select Process" (or use the "s" select shortcut key).
When prompted, enter the PID.
Click on "Memory Regions" (or use the "M" process memory regions shortcut key).
Here's an excerpt from a glance process memory region listing:
TEXT /Shared na 404kb 444kb na <--
Shared so only count once
DATA /Priv na 2.0mb 2.0mb na
<--
Priv so add to the running total
STACK /Priv na 40kb 120kb na <--
Priv so add to the running total
If the SZ numbers on the system total much more than the total to be accounted
for, then much of the memory listed in the SZ column is probably shared between
processes. In that case, the procsize utility discussed below could be used to
better identify process memory usage.
6.3.
Here's an example of using the unsupported HP WTEC procsize utility.
Note: The displayed units in the output of procsize are in 4096 byte pages.
The following command line would show memory regions for all processes, with
shared regions only shown once. Note that it's the Resident Set Size (RSS)
that's actually in memory that is of interested and not the Virtual Set Size
(VSS). Both the RSS and VSS data could be displayed if both -R and -V are
specified. The default is VSS.
# ./procsize -Rfn
"-R" says to display the RSS (Resident Set Size) information, rather than the
default VSS (Virtual Set Size).
"-f" says to report on every process.
"-n" says to only count a region once, for the first process that uses it. The
default action is to report shared regions each time they are found. You
might run procsize with and without this flag towards gaining an
understanding of what regions are shared, and not shared.
Here's a sample excerpt of procsize output. Note procsize itself using a total
of around 9.8 Mb (2414 pages) of memory. The "r" in column 3 indicates that
RSS values are being displayed.
# ./procsize -Rfn
libp4 (6.93): Opening /stand/vmunix /dev/kmem
regions set to 1000
hpux 11.00 32 bit in Narrow mode
nproc=276
pid Comm UAREA TEXT DATA STACK SHMEM IO MMAP Total
0 swapper r 0 0 0 0 0 0 0 0
1 init r 4 61 24 10 0 0 0 100
2 vhand r 4 0 0 0 0 0 0 4
...
5237 gpm r 4 218 1464 12 0 0 187 1885
23828 dtsession r 4 17 64 2 0 0 50 137
29565 procsize r 4 49 328 6 0 0 2027 2414
23876 dtfile r 0 0 0 0 0 0 0 0
5233 dtexec r 4 4 1 2 0 0 1 12
23880 dtexec r 4 0 0 0 0 0 0 4
23885 netscape r 4 47 53 1 0 0 8 113
If the numbers on the system do not come close to the amount of memory being
utilized, then there are other tools such as the kmeminfo kernel memory tool to
help look further. More on that below.
From the current example, say that the cumulative total of the ps command SZ
column came out to 61035 pages, or about 250 Mb:
2900 Mbyte memory used
1500 Mbyte buffer cache
94 Mbyte system memory
1000 Mbyte shared memory
40 Mbyte memory mapped files
10 Mbyte shared libraries
250 Mbyte process text+data+stack
====
2894
That's 2894 of 2900 Mb accounted for. The buffer cache seems over sized at 1500
Mb, and might well be reduced in size by a Gb or more. The 1000 Mb shared
memory may not be out of line at all - especially if there is a database
running. And if a database were running then consider that any memory freed
through limiting buffer cache size might be better used as shared memory by the
database.
Perhaps a large portion of that 250 Mb process text+data+stack is actually
shared eg perhaps it's high by as much as 200 Mb, and when combined with the 6
Mb yet to be accounted for might indicate that the kernel is using 206 Mb - not
an excessive amount.
7. Look at how the HP-UX kernel is utilizing memory.
Say that in the ongoing example it was found that there was yet another 206 Mb
of used memory to account for. The appropriate tool to use would be kmeminfo.
When reaching the point of running kmeminfo, it would be a good idea to be
working with the HP Response Center to fully understand the kmeminfo data.
In the current ongoing example, 206 Mb being used by the kernel may not be out
of line. And depending upon how the system is being used, several hundred Mb
might not be out of line.
"Used by the kernel" generally means memory that is handled by the kernel as it
manages user resources, and works to satisfy the memory requests of the many
processes running on the system." Some kernel memory is statically sized at boot
time, and some dynamically sized after boot time. Different processes tend to
request memory in different denomintations ie make use of different kernel
memory "buckets" or "arena's".
For example, starting at HP-UX 11.0 JFS tends to make use of memory in 2 Kb
pieces - and so the kernel might build up an accumulation of 4096-byte pages of
memory specifically for satisfying 2048-byte requests. At HP-UX 10.20 JFS
tended to make use of memory in 1 Kb pieces, and kmeminfo would reflect that
activity in the "1 Kb kernel bucket".
Starting with HP-UX 11i default kmeminfo output displays information about
kernel memory "arena's" rather than "buckets". The memory activity of different
processes on the system is reflected in the increase and decrease of different
arena's.
Memory makes it's way to the arena's by way of the Super Page Pool. A super
page remains in the Super Page Pool so long as any portion of it is in use by
an arena.
Ideally, the amount of memory seen in any kernel bucket/arena, or in the Super
Page Pool should be minimal. But it is important to understand that seeing a
quantity of memory in a particular bucket/arena does not by itself indicate a
memory leak. A memory leak is where something continues to grow over time
without ever decreasing.
Excessive use of memory in particular buckets/arena's might be indications that
kernel or application tuning needs to take place.
Excessive use of memory in the Super Page Pool might indicate a problem that's
addressed through HP-UX patching.
Contact the HP Response Center for any concerns or questions in these areas.
The following kmeminfo excerpt (values in 4096-byte pages) shows a system with
around 268 Mb RAM. 232 Mb of that memory is in use - 51 Mb of that by user
processes and 184 Mb of that by the kernel. What's used "by the kernel" is
broken out as 134 Mb buffer cache, 27 Mb dynamic eg kernel buckets, 22 Mb
static structures eg system tables.
Physical memory usage summary (in pages):
Physmem = 65536 Available physical memory:
Freemem = 8765 Free physical memory
Used = 56771 Used physical memory:
System = 45015 by kernel:
Static = 5373 for text and static data
Dynamic = 6730 for dynamic data
Bufcache = 32768 for file-system buffer cache
Eqmem = 16 for equiv. mapped page pool
SCmem = 128 for system critical page pool
User = 12490 by user processes
Uarea = 460 for thread uareas
From another excerpt of that same kmeminfo output, usage of the 27 Mb of
dynamic kernel memory is broken out as follows. Almost 11 Mb is used in kernel
buckets (2671 pages * 4096 byte page size) with the largest accumulation of
about 2.7 Mb in bucket 10 (656 pages * 4096 byte page size), the 1 Kb bucket.
Dynamic memory usage summary (in pages):
Dynamic = 6730 Kernel dynamic data (sysmap):
MALLOC = 2671 memory buckets:
bucket[ 5] = 179 size 32 bytes
bucket[ 6] = 25 size 64 bytes
bucket[ 7] = 282 size 128 bytes
bucket[ 8] = 164 size 256 bytes
bucket[ 9] = 190 size 512 bytes
bucket[10] = 656 size 1024 bytes
bucket[11] = 340 size 2048 bytes
bucket[12] = 387 size 4096 bytes
bucket[13] = 30 size 2 pages
bucket[14] = 21 size 3 pages
bucket[15] = 20 size 4 pages
bucket[16] = 5 size 5 pages
bucket[17] = 18 size 6 pages
bucket[18] = 0 size 7 pages
bucket[19] = 56 size 8 pages
bucket[20] = 298 size > 8 pages
Kalloc = 4003 kalloc()
Eqalloc = 45 eqalloc()
Reserved = 11 Reserved pools
Note that the 134 Mb buffer cache is half of RAM. It looks like the dbc_max_pct
kernel tunable that controls the upper limit of dynamic buffer cache growth is
at it's default value of 50 [percent]. On this small memory system that may be
OK. Note that there's about 36 Mb free memory. If memory were needed elsewhere
eg in the data segments of user processes, then perhaps the buffer cache size
could be smaller. Before making such a change be sure to monitor the buffer
cache usage over time eg with sar -b or in the glance disk report (under the
percent column of the "Local" "Logl Rds" and "Logl Wts" lines). Or perhaps just
letting the system page out to disk is not a problem. After all, the kernel
will work to page out only those memory pages that have not been recently used.
8. Still unable to account for all memory utilization on the system?
There are more intrusive methods of identifying how memory is being used by the
kernel. If this point is reached and it is not yet seen where exactly memory is
being used - the HP Response Center should be involved.
Keywords
#################################################################
| Document Id | : KBRC00012760 |
| Date | : 2005년 05월 24일 |
| Author | : |
| Document Type | : RCEN |
| Description | : 프로세스당 메모리 사용량을 확인하기 위한 간편한 명령 |
| Category1 | : HP-UX |
| Category2 | : HP-UX System Admin |
| Search String | : |
|
문] 실행 중인 각 프로세스에 대한 가상 메모리 크기를 표시하려면 어떻게 해야 합니까? 구성 정보: 답] 프로세스당 총 메모리 사용량을 확인하려면 다음을 사용합니다. # UNIX95= ps -e -o ruser,vsz,pid,ppid,args|sort -rnk2 |more 다음과 같은 형식의 내용이 출력됩니다. # UNIX95= ps -e -o ruser,vsz,pid,ppid,args|sort -rnk2 |more RUSER VSZ PID PPID COMMAND root 20096 13271 1 /opt/mx/lbin/mxagent root 6736 1693 1 /opt/pd/lbin/pdclientd root 5468 1520 1 /opt/dce/sbin/rpcd root 4280 1683 1 basicdsd root 3528 1899 1 /usr/sbin/swagentd -r root 1972 1883 1 /opt/perf/bin/pvalarmd root 1788 12650 1 /opt/wbem/sbin/cimserver root 1764 2198 1 /etc/opt/resmon/lbin/fsmond root 1504 842 1 /opt/ssh/sbin/sshd root 1320 1364 1 /usr/sbin/snmpdm root 1016 1329 1 sendmail: accepting connections on port 25 root 944 868 1 /usr/sbin/rpcbind root 940 955 1 /usr/sbin/rpc.lockd root 724 949 1 /usr/sbin/rpc.statd 각 열은 다음을 나타냅니다. ruser = 프로세스 소유자 vsz = 가상 메모리 사용량(실제 메모리 사용량을 기준으로 한 크기) pid = 프로세스 ID ppid = 상위 프로세스 ID args = 프로세스 작성 시 명령줄 인수 명령줄 옵션 sort -rnk2 = 가장 큰 프로세스부터 내림차순으로 정렬 ****************************************************** KBRC00012760 .........following with all English text .... Problem Description How can the virtual memory size for each running process be listed? Configuration Info Solution To obtain the total memory usage per process, use: # UNIX95= ps -e -o ruser,vsz,pid,ppid,args|sort -rnk2 |more The format of the output will be similar to: # UNIX95= ps -e -o ruser,vsz,pid,ppid,args|sort -rnk2 |more RUSER VSZ PID PPID COMMAND root 20096 13271 1 /opt/mx/lbin/mxagent root 6736 1693 1 /opt/pd/lbin/pdclientd root 5468 1520 1 /opt/dce/sbin/rpcd root 4280 1683 1 basicdsd root 3528 1899 1 /usr/sbin/swagentd -r root 1972 1883 1 /opt/perf/bin/pvalarmd root 1788 12650 1 /opt/wbem/sbin/cimserver root 1764 2198 1 /etc/opt/resmon/lbin/fsmond root 1504 842 1 /opt/ssh/sbin/sshd root 1320 1364 1 /usr/sbin/snmpdm root 1016 1329 1 sendmail: accepting connections on port 25 root 944 868 1 /usr/sbin/rpcbind root 940 955 1 /usr/sbin/rpc.lockd root 724 949 1 /usr/sbin/rpc.statd Columns represent the following: ruser = owner of the proces vsz = virtual memory usuage (vs. sz which is the actual memory usage) pid = process id ppid = parent process id args = command line arguments when the process was created Command line options sort -rnk2 = largest processes filter to the top Keywords memory leak, performance, memory per process |
#################################################################
| Document Id | : UNX1000043 |
| Date | : 2005년 06월 01일 |
| Author | : |
| Document Type | : RCEN |
| Description | : 호스트 이름과 IP 주소 변경 및 저장 위치 |
| Category1 | : HP-UX |
| Category2 | : SystemAdmin |
| Search String | : |
|
문제] 9.X에서는 호스트 이름 또는 IP 주소를 변경할 때 `set_parms'를 실행했습니다. 10.0에서는 어떻게 해야 합니까? 호스트 이름 정보는 어디에 저장됩니까(이전에는 "/etc/src.sh"에 저장)? 구성 정보] 해결] SAM은 기본적인 네트워크 매개변수를 수정하는 데 유용합니다. 1. 시스템 이름을 변경하려면 a. SAM의 "네트워킹 및 통신" 영역으로 갑니다. b. "네트워크 서비스" 섹션으로 갑니다. c. 메뉴 항목 `동작: 구성'을 선택합니다. 2. 시스템의 IP 주소를 변경하려면 a. "네트워크 인터페이스 카드" 섹션으로 갑니다("네트워킹 및 통신" 영역에서, 또는 이미 "네트워크 서비스"에 있는 경우에는 '목록: 네트워크 인터페이스 카드' 메뉴 항목 선택). b. 원하는 카드가 있는 행을 선택합니다. c. 메뉴 항목 `동작: 구성'을 선택합니다. 기본 설정을 변경하는 두 번째 방법은 /sbin/set_parms를 실행하는 것입니다. 시스템을 처음 작동하여 네트워크를 구성한 경우 시스템은 set_parms 명령을 실행하며 사용자는 언제든지 직접 실행할 수 있습니다. # /sbin/set_parms hostname 및 # /sbin/set_parms ip_address 및 # /sbin/set_parms addl_netwrk addl_network 설정을 통해 하위 네트워크 마스크, 기본 게이트웨이 도메인 이름 시스템(DNS) 및 네트워크 정보 서비스(NIS)를 설정합니다. 변경할 수 있는 내용을 보려면 인수 없이 /sbin/set_parms를 실행합니다. 네트워킹 구성을 위한 세 번째 방법은 /etc/rc.config.d/*에서 구성 파일을 직접 편집한 다음 재부팅하는 것입니다. 호스트 이름 및 IP 주소의 경우에는 /etc/rc.config.d/netconf를 참조하십시오. 일반적으로 시작 매개변수의 설정 위치를 찾으려면 /etc/rc.config.d/*를 확인합니다. $ grep -i hostname /etc/rc.config.d/* 시스템은 시작할 때 이 구성 파일을 읽고 /sbin/init.d/에서 이름이 유사한 읽기 전용 스크립트를 실행합니다. 시스템 시작 파일의 보관 위치 및 이들 파일의 사용 방법에 대한 일반적인 지침은 "/usr/share/doc/filesys.ps"에 함께 제공되는 파일 시스템 백서를 참조하십시오. ************************************************************************************* .........following with all English text .... UNX1000043How do I change hostname and IP address? Where is it stored? Problem Description At 9.X, we ran `set_parms' to change our hostname or IP address. What do wedo now at 10.0? Where is the hostname info saved (it used to go in "/etc/src.sh")? Configuration Info Solution SAM can help you modify fundamental network parameters:1. To change your system's name: a. Get into SAM's "Networking and Communications" area. b. Go to the "Network Services" section. c. Choose the menu item `Actions: Modify System Name'. 2. To change your system's IP address: a. Go to the "Network Interface Cards" section (either from the "Networking and Communications" area, or if you're already in "Network Services", choose the `List: Network Interface Cards' menu item). b. Select the line with the desired card on it. c. Choose the menu item `Actions: Configure'. A second way to change fundamental settings is by running /sbin/set_parms. When you brought up the system for the first time and configured the network, the system ran the set_parms command, and you can run it by hand at any time: # /sbin/set_parms hostname and # /sbin/set_parms ip_address and # /sbin/set_parms addl_netwrk Through the addl_network setting you set the subnetwork mask, default gateway, Domain Name System (DNS), and Network Information Service (NIS). Run /sbin/set_parms with no arguments to see what you can change. A third way to configure networking is to edit the configuration files in /etc/rc.config.d/* directly and then reboot. See /etc/rc.config.d/netconf in particular for hostname and IP address. In general, to find out where a startup parameter is set, grep for it in /etc/rc.config.d/*: $ grep -i hostname /etc/rc.config.d/* The system reads these configuration files at startup and executes a similarly-named (read-only) script in /sbin/init.d/. For general principles about where system startup files are kept and how these files are used, see the file system white paper shipped in "/usr/share/doc/filesys.ps". Keywords 10.0 |
#################################################################
| Document Id | : KBRC00011918 |
| Date | : 2005년 03월 08일 |
| Author | : |
| Document Type | : RCEN |
| Description | : /etc/hosts를 검색하도록 /etc/nsswitch.conf 구성 후 DNS 조회 |
| Category1 | : HP-UX |
| Category2 | : Networking |
| Search String | : |
|
문] /etc/hosts를 먼저 검색하도록 /etc/nsswitch.conf를 구성한 후에 telnet(1), ftp(1), ssh 등을 비롯한 여러 명령에서 여전히 DNS를 통해 조회합니다. /etc/nsswitch.conf 파일을 검사하여 다음과 같은 내용을 발견했습니다. cat /etc/nsswitch.conf hosts: files [NOTFOUND=continue] dns 서버에서 nslookup(1)을 실행하면 다음과 같은 내용이 출력됩니다. root on server1 -# nslookup server1 Using /etc/hosts on: server1 looking up FILES Name: server1.atl.hp.com Address: 11.222.33.44 <- 이 주소는 /etc/hosts의 IP입니다. Aliases: server1 이는 올바른 정보입니다. 창 하나에서 서버에 대해 telnet(1)을 시도하고 # telnet server1 trying... 다른 창에서 netstat(1)을 실행하면 netstat -an | grep 23 server1의 IP 주소가 *이전* DNS IP로 표시됩니다. 이 출력은 올바르지 않습니다. 이 IP 주소는 어디에서 찾을 수 있습니까? 구성 정보: 답] 이 경우 공용 도메인 유틸리티 tusc를 사용하여 프로세스를 추적했습니다. tusc -a -e -f -k -l -p -r all -w all -o outputfile_1 telnet server1 tusc 출력을 살펴보면 telnet(1)으로 시스템에서 /dev/ip6이 발견된 것을 확인할 수 있습니다. . . ... [16854]{4049461} stat("/dev/ip6", 0x680f0590) ........................................................ = 0 이 문제를 해결하려면 /etc/nsswitch.conf에 다음을 추가합니다. ipnodes: files [NOTFOUND=continue] dns 주: tusc는 HP에서 지원하지 않는 공용 도메인 유틸리티입니다. 이 유틸리티는 http://software.hp.com에서 다운로드할 수 있습니다. 1. "related links"에서 "hp-ux public domain software"를 누릅니다. 2. 'Package Search:' 필드에 "tusc"를 입력합니다(인용 부호 제외). 3. 'Search'를 누르거나 'Enter' 키를 누릅니다. ****************************************************** KBRC00011918 .........following with all English text .... Problem Description After configuring /etc/nsswitch.conf to search /etc/hosts first, commands such as telnet(1), ftp(1), ssh, and others still resolve through DNS? When checking the /etc/nsswitch.conf file, the following is seen: cat /etc/nsswitch.conf hosts: files [NOTFOUND=continue] dns When running nslookup(1) on a server, the following output is seen: root on server1 -# nslookup server1 Using /etc/hosts on: server1 looking up FILES Name: server1.atl.hp.com Address: 11.222.33.44 <- this is the IP in /etc/hosts, which is Aliases: server1 correct. When attempting to telnet(1) to the server from one window: # telnet server1 trying... and running netstat(1) from another: netstat -an | grep 23 It shows the IP address of server1 as the *old* DNS IP. This is incorrect. Where is this IP address being found? Configuration Info Solution In this instance, the public domain utility tusc was used to trace the process: tusc -a -e -f -k -l -p -r all -w all -o outputfile_1 telnet server1 Looking at the tusc output, we can see that telnet(1) has detected /dev/ip6 on the system: . . ... [16854]{4049461} stat("/dev/ip6", 0x680f0590) ........................................................ = 0 To correct this issue, add the following to /etc/nsswitch.conf: ipnodes: files [NOTFOUND=continue] dns NOTE: The tusc is a public domain utility that is not supported by HP. You can download it at http://software.hp.com: Click on "hp-ux public domain software" under "related links" Type "tusc" (without quotes) in the 'Package Search:' field Click on 'Search', or press the 'Enter' key Keywords |
#################################################################
| Document Id | : k1048150 |
| Date | : 2001 Mar 23 |
| Author | : |
| Document Type | : RCEN |
| Description | : POSIX shell (/usr/bin/sh)에서 한글 입력이 지원되나? |
| Category1 | : HP-UX |
| Category2 | : HP-UX System Admin |
| Search String | : |
|
문] POSIX shell (/usr/bin/sh)에서 한글 입력이 지원되나? 답] 경우가 따라 한글을 사용할 수 있습니다. 모든 경우에도 한글 입력이 가능하도록 patch를 준비중에 있습니다. 한글을 입력하기 위해서는 # stty cs8 -parenb -ixany -istrip와 # LANG=ko_KR.eucKR;export LANG 은 필수입니다. case 1: 환경변수 EDITOR=vi command를 입력할 때 위의 변수가 설정되어 있으면 command변경이 용이하고 앞서 실행했던 명령어을 불어 낼 수 있지만 이 변수가 지정이 되어 있으면 한글 입력이 안됩니다. case 2: POSIX shell patch shell script의 몇가지 문제로 인해 POSIX shell에 patch을 해야 되는 경우가 있습니다. patch가 없으면 login이후 /usr/bin/sh를 한 번 더 실행하면 이후 한글 입력이 됩니다. shell patch가 있으면 /usr/bin/sh를 실행되지 않고 coredump되기 때문에 한글 입력을 할 수 없습니다. |
#################################################################
| Document Id | : 1200345439 |
| Date | : 2004년 08월 31일 |
| Author | : |
| Document Type | : RCEN |
| Description | : HP-UX 시스템 디스크를 mirror 하려 할 때 |
| Category1 | : hp-ux |
| Category2 | : System admin |
| Search String | : |
|
문] HP-UX 시스템 디스크를 mirror 하려 할 때 다음오류가 ISL에서 발생합니다: ----------------------------------------------------------- ISL booting hpux -lq (;0)/stand/vmunix Boot: disk(10/0/15/1.5.0.0.0.0.0;0)/stand/vmunixdisk (10/0/15/1.5.0.0.0.0.0;0)/stand/vmunix: cannot open, or not executable ----------------------------------------------------------- 어떻게 이 문제를 해결 할 수 있습니까? 구성 정보: 운영 체제 - HP-UX Subsystem - SYS ADM 답] 다음 과정을 수행하여 HP-UX 시스템 디스크를 mirror 하고, 위에 나타난 오류를 고칩니다: 1. root로 로그인 합니다. 2. 어떤 디스크가 vg00에 의해 사용되는지 확인합니다: # vgdisplay -v vg00 | grep 'PV Name' | awk '{ print $NF }' 3. mirror 디스크로 동작하는 남는 디스크가 어떤 것인지 확인합니다: # ioscan -nfC disk | grep dev | grep -v `vgdisplay -v vg00 | grep 'PV Name' | awk '{ print $NF }?` 4. 예전 LVN 구조를 모두 삭제합니다: # /usr/sbin/insf -eH 10/0/15/1.5.0 # /sbin/pvcreate -f /dev/rdsk/c3t5d0 # /sbin/vgextend vg00 /dev/dsk/c3t5d0 # /sbin/vgreduce vg00 /dev/dsk/c3t5d0 5. 디스크를 초기화 하여 LVM 부팅디스크로 사용 될 수 있게 합니다: # /sbin/pvcreate -B /dev/rdsk/c3t5d0 # /sbin/vgextend vg00 /dev/dsk/c3t5d0 6. LIF 정보를 디스크에 넣습니다: # /usr/sbin/mkboot /dev/rdsk/c3t5d0 # /usr/sbin/mkboot -a "hpux -lq (;0)/stand/vmunix" /dev/rdsk/c3t5d0 7. primary swap logical volume의 이름을 찾습니다: # swapinfo Kb Kb Kb PCT START/ Kb TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME dev 8388608 0 8388608 0% 0 - 1 /dev/vg00/lvol2 reserve - 110980 -110980 memory 5771732 117052 5654680 2% 8. root(/stand) logical volume와 primary swap logical volume을 mirror 합니다: # lvextend -m 1 /dev/vg00/lvol1 /dev/dsk/c0t3d0 # lvextend -m 1 /dev/vg00/lvol2 /dev/dsk/c3t5d0 9. 부팅 정보가 mirror 된 디스크에 있는지 확인합니다: # lvlnboot -R -v 10. maintenance/single-user 모드로 재부팅 한 후, 다음 작업을 primary swap/dump logical volume에 수행합니다: (다음 메시지가 나오면 재부팅하고 부팅프로세스를 종료합니다: To discontinue, press any key within 10 seconds.) Main Menu: Enter command > boot Interact with IPL (Y, N, Q)?> y ISL> hpux -lm -is INIT: SINGLE USER MODE INIT: Running /sbin/sh 프롬프트가 나오면: # vgchange -a y vg00 # lvchange -M n -c n /dev/vg00/lvol2 # reboot 11. root로 로그인합니다. 12. 어떤 디스크가 vg00에 의해 사용되는지 확인합니다: 13. 모든 File 시스템과 Swap/Dump의 root-vg logical volume을 mirror 합니다: # id # tcsh # foreach i (`swapinfo | grep dev | awk '{ print $NF }' ; bdf | grep dev | awk '{ print $1 }'`) foreach? lvextend -m 1 $i /dev/dsk/c3t5d0 foreach? end # !/bin/csh -f set lvdisplay=/usr/sbin/lvdisplay foreach i ( `swapinfo | grep dev | awk '{ print $NF }'` ) /usr/sbin/lvextend -m 1 $i end foreach i ( `bdf | grep dev | awk '{ print $1 }'` ) echo `bdf $i | grep $i | awk '{ print $6 }'` " " '('"$i"')' `$lvdisplay $i | grep 'Mirror copies'` if ( `$lvdisplay $i | grep 'Mirror copies' | awk '{ print $NF }'` == "0") then /usr/sbin/lvextend -m 1 $i echo `bdf $i | grep $i | awk '{ print $6 }' ` " " '('"$i"')' `$lvdisplay $i | grep 'Mirror copies'` endif end .........following with all English text .... 1200345439 ISL error occurs when attempting to mirror HP-UX system disk Problem Description The following error occurs from ISL when attempting to mirror an HP-UX system disk: ----------------------------------------------------------- ISL booting hpux -lq (;0)/stand/vmunix Boot: disk(10/0/15/1.5.0.0.0.0.0;0)/stand/vmunixdisk (10/0/15/1.5.0.0.0.0.0;0)/stand/vmunix: cannot open, or not executable ----------------------------------------------------------- How can this problem be resolved? Configuration Info Operating System - HP-UX Subsystem - SYS ADM Solution Perform the following steps to successfully mirror an HP-UX system disk and avoid the error referenced above: 1. Log in as root. 2. Check which disk is currently occupied by "vg00": # vgdisplay -v vg00 | grep 'PV Name' | awk '{ print $NF }' 3. Check which is the free disk that will serve as the mirror disk: # ioscan -nfC disk | grep dev | grep -v `vgdisplay -v vg00 | grep 'PV Name' | awk '{ print $NF }?` 4. Clear this disk of all previous LVN structures: # /usr/sbin/insf -eH 10/0/15/1.5.0 # /sbin/pvcreate -f /dev/rdsk/c3t5d0 # /sbin/vgextend vg00 /dev/dsk/c3t5d0 # /sbin/vgreduce vg00 /dev/dsk/c3t5d0 5. Initialise the disk so it can be used as an LVM boot disk: # /sbin/pvcreate -B /dev/rdsk/c3t5d0 # /sbin/vgextend vg00 /dev/dsk/c3t5d0 6. Place the LIF information on the disk: # /usr/sbin/mkboot /dev/rdsk/c3t5d0 # /usr/sbin/mkboot -a "hpux -lq (;0)/stand/vmunix" /dev/rdsk/c3t5d0 7. Find the name of the primary swap logical volume: # swapinfo Kb Kb Kb PCT START/ Kb TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME dev 8388608 0 8388608 0% 0 - 1 /dev/vg00/lvol2 reserve - 110980 -110980 memory 5771732 117052 5654680 2% 8. Mirror the root (/stand) logical volume and the primary swap logical volume: # lvextend -m 1 /dev/vg00/lvol1 /dev/dsk/c0t3d0 # lvextend -m 1 /dev/vg00/lvol2 /dev/dsk/c3t5d0 9. Verify that the boot information resides on the mirror disk: # lvlnboot -R -v 10. Reboot to maintenance/single-user mode, and do the following on the primary swap/dump logical volume: (Reboot and stop the boot process at the following message: To discontinue, press any key within 10 seconds.) Main Menu: Enter command > boot Interact with IPL (Y, N, Q)?> y ISL> hpux -lm -is INIT: SINGLE USER MODE INIT: Running /sbin/sh When you get the prompt do: # vgchange -a y vg00 # lvchange -M n -c n /dev/vg00/lvol2 # reboot 11. Login as root. 12. Check which is the disk currently occupied by "vg00". 13. Mirror all Files-Systems' and Swap/Dump's root-vg logical volumes: # id # tcsh # foreach i (`swapinfo | grep dev | awk '{ print $NF }' ; bdf | grep dev | awk '{ print $1 }'`) foreach? lvextend -m 1 $i /dev/dsk/c3t5d0 foreach? end # !/bin/csh -f set lvdisplay=/usr/sbin/lvdisplay foreach i ( `swapinfo | grep dev | awk '{ print $NF }'` ) /usr/sbin/lvextend -m 1 $i end foreach i ( `bdf | grep dev | awk '{ print $1 }'` ) echo `bdf $i | grep $i | awk '{ print $6 }'` " " '('"$i"')' `$lvdisplay $i | grep 'Mirror copies'` if ( `$lvdisplay $i | grep 'Mirror copies' | awk '{ print $NF }'` == "0") then /usr/sbin/lvextend -m 1 $i echo `bdf $i | grep $i | awk '{ print $6 }' ` " " '('"$i"')' `$lvdisplay $i | grep 'Mirror copies'` endif end Keywords |
#################################################################
| Document Id | : A4693053 |
| Date | : 2005년 05월 24일 |
| Author | : |
| Document Type | : RCEN |
| Description | : NTP의 기본 구성 예제 |
| Category1 | : HP-UX |
| Category2 | : HP-UX System Admin |
| Search String | : |
|
문] HP-UX클라이언트에 시간을 제공할 수 있게 HP-UX시스템을 이용하여 네트워크에 NTP(Network Time Protocol)구성을 위해 요구되는 것은 무엇입니까? 이 작업을 위한 기본 절차를 제공할 수 있습니까? 구성 정보: Operating System - HP-UX Version -10.10 Hardware System - HP 9000 Series -E45 답] 다른 단일 UX 호스트와 xntpd를 통해 sync하기 위한 단일 호스트를 얻는 기본 지침 기능을 포함하는 문서입니다. 서버로써의 계획된 시스템 주의: 서버로써 시스템 역활은 클라이언트가 날자 정보를 얻기 전에 자신과 또는 다른 서버와 sync해야 합니다. 1. 서버에 어떤 버전의 NTP가 실행되는지 다음의 명령어로 확인합니다: what /usr/sbin/xntpd 만약 바이너리에서 버전 정보를 보고하기 위한 이 명령어가 실패 한다면 다음을 실행합니다: a) xntpd 데몬을 시작합니다: /usr/sbin/xntpd b) 방금 시작한 xntpd 데몬을 킬합니다. c) grep xntpd /var/adm/syslog/syslog.log 다음과 같은 버젼 정보를 찾습니다: Jun 4 12:38:42 tuco xntpd[882]: xntpd version=3.5f... 2. 절차 1로부터 버젼 출력을 기반으로 다음의 줄을 /etc/ntp.conf화일에 추가합니다. server 127.127.1.10 버전 3.5 그리고 그 이후의: server 127.127.1.1 3. xntpd를 시작합니다.. a) /etc/rc.config.d/netdaemons를 편집 그리고 아래 본 것처럼 다음의 라인를 설정합니다: XNTPD=1 b) /sbin/init.d/xntpd를 시작합니다. 4. sync를 위해 5분 정도 대기 후 다음의 명령어로 상태를 확인합니다: ntpq -c rv 'reftime=' 필드의 값을 찾습니다. 만약 필드가 모두 0 이면 서버로부터 동기화가 끝나지 않았으며, hex로 대체되었다면 클라이언트에 시간정보를 제공하기 위한 준비가 된 상태입니다. 1. /etc/ntp.conf화일를 수정하여 다음 줄를 추가 합니다: > server 2. 초기의 클락 동기화를 수행하기위해 ntpdate를 실행합니다. (주의,이 명령어가 들어왔을 때 클라이언트에서는 nxtpd가 실행되면 안됩니다.) ntpdate 3. xntpd 시작합니다. a) /etc/rc.config.d/netdaemons를 수정하여 아래를 설정합니다: XNTPD=1 클라이언트로 인식되는 시스템에서: On the system intended as the client: 버전 3.4 그리고 이전: b) /sbin/init.d/xntpd start 4. 다음의 명령어로 서버를 볼 수 있는지 확인합니다: ntpq -p 주의: NTP가 느려집니다... 그리고 이 명령어가 어떤 유용한 정보를 보고하기 전에 몇 분 정도 연기 할 수도 있습니다. 5. 5분 정도 대기 후 다음의 명령어로 상태를 확인합니다: ntpq -c rv 'reftime=' 필드 값을 찾습니다. 만약 이 필드가 모드 제로이면 시스템은 아직 서버에 동기화를 하지못한 상태입니다. 제로가 헥사 값으로 대체되었다면, 시스템은 클라이언트에 시간정보를 제공할 준비가 되었습니다. 주의: 가장 정확한 동기화를 가져오기 위해 클라이언트에 xntpd가 실행 되도록 하십시요. 그러나 어떤 환경에서는 성능 문제, 네트워크 부화때문에 피하기도 합니다. 최소한 ntpdate명령어는 클론 잡을 통해 매 12시간마다 시간 통기화 보장을 위해 클라이어트에서 실행되어야 합니다. .........following with all English text .... A4693053Basic configuration example for NTP Problem Description What is required to configure NTP (Network Time Protocol)on my network using an HP-UX system as the clock serving an HP-UX client? Can you provide the basic steps to get this working? Configuration Info Operating System - HP-UX Version -10.10 Hardware System - HP 9000 Series -E45 Solution This document is intended to function as a basic guidelinesto get a single UX host to sync via xntpd with another single UX host. On the system intended as the server: NOTE: The system acting as the server must sync to itself or to another server before clients can gain date information from it. 1. Verify which version of NTP your system is running with the what command: what /usr/sbin/xntpd If this command fails to report the version information (patch PHNE_9056 released v3.5f without what information) in the binary, complete the following: a) Start the xntpd daemon: /usr/sbin/xntpd b) Kill the xntpd daemon you just started. c) grep xntpd /var/adm/syslog/syslog.log Look for the version information such as: Jun 4 12:38:42 tuco xntpd[882]: xntpd version=3.5f... 2. Based on the version output from step 1, add the following line to the /etc/ntp.conf file. server 127.127.1.10 For version 3.5 and later: server 127.127.1.1 3. Start xntpd. a) Edit /etc/rc.config.d/netdaemons and set the following line as shown: XNTPD=1 b) /sbin/init.d/xntpd start 4. Give the system about 5 minutes to sync and check the status with the command: ntpq -c rv Look for the value of the field 'reftime='. If the field is all zeros the system has not yet synced to a server. Once a hex value replaces the zeros, the system is ready to provide time information to clients. 1. Edit the /etc/ntp.conf file and add the following line: > server 2. Run ntpdate to perform initial clock syncronization (note, xntpd must NOT be running on the client when this command is entered). ntpdate 3. Start xntpd. a) Edit /etc/rc.config.d/netdaemons and set the following line as shown: XNTPD=1 On the system intended as the client: For version 3.4 and older: b) /sbin/init.d/xntpd start 4. Verify the client can see the server with the command: ntpq -p Note: NTP is slow... and so there may be a delay of a couple of minutes before this command reports any useful information. 5. Give the system about 5 minutes to sync and check the status with the command: ntpq -c rv Look for the value of the field 'reftime='. If the field is all zeros the system has not yet synced to a server. Once a hex value replaces the zeros, the system is ready to provide time information to clients. Note: It is recommended to leave xntpd running on the client to gain the most exact syncronization however, some environments prefer to avoid the network traffic due to performance reasons. At a minimum, the ntpdate command should be run every 12 hours on the client via a cron job to ensure time syncronization. |
반응형