HP ESSO Consulting Glance Manual 2018년 9월 22일 filename\location

Glance 사용방법 Glance 화면 설명 중요 항목별 점검 방법 2018년 9월 22일 filename\location

Glance를 이용하여 시스템의 사용 상태를 점검하고 이상이 있는지 여부와 시스템의 가용성을 확인 합니다. 2018년 9월 22일 filename\location

Glance 화면표시내용 Banner Line 스크린의 위에 있는 Banner Line은 product의 version, product 이름, 현재 시간, 시스템 명칭, 그리고 시스템 타입을 포함한다. 그 줄은 세가지 column heading 으로 끝나는데 Current Avg (for average), High Banner Line아래에 있는 Global Bar 섹션에서 나타나는 통계치를 지칭한다. 2018년 9월 22일 filename\location

Glance 화면표시내용 Global Bars 4개의 Global Bar는 Banner Line 바로 밑에 나타난다. 이런 bar들과 오른쪽에 있는 percentage는 네 가지 자원의 사용률을 나타낸다. CPU Disk Memory Swap Space 각 스크린에 있는 이러한 bar들은 “global” 상태를 계속적으로 기억하는데 도움이 된다 2018년 9월 22일 filename\location

Glance 화면표시내용 CPU Utilization Bar S : 시스템 Call의 수행, Interrupt의 Handling, 그리고 Context Switching과 같은 System Activity 에 소비된 시간 R : “Real-Time” Priority와 함께 실행 되는 사용자 프로세스에 소요되는 시간. Real-time priority는 일반적인 Time-Sharing 프로세스보다도 더 높은 우선순위에서 실행 되는 프로세스를 지칭합니다. U: User Code를 수행하는 것과 같은 User Activity에 소요되는 시간. 이것은 Nice Priority와 함께 실행 되는 User Code를 포함하지 않습니다. N: Nice와 Negative Nice Priority와 함께 실행 되는 User Code에 소요되는 시간. Nice Priority는 다른 프로세스보다도 더 낮은 우선순위에서 프로세스가 수행된다는 것을 의미하고, Negative Nice Priority는 더 높은 우선순위에서 수행하도록 하는 것입니다. 만약 bar의 길이가 100%보다 짧으면, CPU가 한가하다는 것을 의미하고; 만약 계속해서 100%의 CPU 사용율에 근접하면 performance상 bottleneck에 걸릴 수도 있다는 것을 의미한다. 하나이상의 CPU를 가진 시스템에서 CPU 사용율은 100% 기준으로 되어 있다. 예를 들어, 시스템이 4개의 CPU를 가지고 있고, 그것들 중 2개가 100% 사용된다면, global utilization은 200%가 아니라 50%이다. 2018년 9월 22일 filename\location

Glance 화면표시내용 Disk Utilization Bar 이 Global Bar는 주어진 Time Interval동안에 가장 바쁜 Disk Device의 사용율을 보여줍니다. 아래에 각 문자화된 Segment가 있습니다  F : User-process read와 Write Activity, 시스템 Call에 의한 File System I/O, 그리고 “raw” Disk I/O를 포함한 File System Activity. Raw disk I/O는 시스템 Buffer Cache를 사용하지 않습니다. V : Paging data에 의한 Virtual memory로 그리고 Virtual Memory에서의 Disk I/O. 만약 Bar 길이가 100%에 가까우면, 시스템의 가장 바쁜 Disk Device가 그 Queue에I/O Pending을 가지고 있다는 것을 의미한다. 이것은 Disk I/O Bottleneck 상황일 수도 있다. 만약 저 자세한 Disk 의 사용을 확인하려면 “d”,“v”, “i”, “u” 등을 실행하여 자세한 점검을 할 수 있습니다. 2018년 9월 22일 filename\location

Glance 화면표시내용 Memory Utilization Bar 이 Global Bar는 Physical Memory의 사용을 보여줍니다.   S : 시스템 Code과 데이터용으로 사용된Physical Memory U : 사용자 Code과 데이터용으로 사용된 Physical Memory 만약 bar 길이가 100%에 근접한다면, 대부분의 physical memory가 code와 data object를 저장하기 위해서 이용 되고 있다는 것입니다. 이것은 Memory bottleneck을 유발할 수 있는 Memory pressure을 의미할 수 있다. 만약 더 자세한 Memory 사용에 대한 정보를 알고 싶다면 “m”을 눌러 Memory사용을 확인할 수 있습니다. 2018년 9월 22일 filename\location

Glance 화면표시내용 Swap Utilization Bar  이 bar는 시스템에서 어떻게 swap space가 reserved되고 사용되는 지를 보여줍니다. 프로그램이 구동 될 때 마다 주 Memory 밖으로 프로그램을 바꿔주기(swap) 위해 필요 되어지는 Space가 “Reserved” 된다. Reserved Swap Space는 어떤 Disk Location에 할당되지 않고, 단순히 필요 되어 질 수 있는 Swap Space의 양을 지칭한다. 프로그램이 실제로 Swap Out 될 때 Disk Space가 할당되는데; 이것은 Reserved Space의 일부분이 된다. 이 값은 Overhead를 줄이기 위해 매 30초마다 update된다. U : 실제적으로 사용되고 있는 Reserved Swap Space. 이것은 실제적으로 쓰여진(written) Reserved Swap Space의 일부분이다. R : Reserved 되어 있지만 실제 Active 하게 사용되고 있지 않은 Swap Space; 즉 이것은 쓰이지 않았다. (not written to )   U와 R Bar의 통합된 길이는 얼마나 많은 Swap Space가 Reserved 되어 있는지를 나타낸다. 만약 Bar 길이가 100%에 도달 하면, 시스템의 free swap space가 바닥나고 프로세스가 수행을 멈출 수 도 있다는 것을 의미한다. 2018년 9월 22일 filename\location

Glance 화면표시내용 Process List 이 항목은 표시되는 항목에 따라 내용이 바뀌게 됩니다. 이곳은 최초 Glance가 실행 될 때 Global화면이 표시되게 되어 있어서 Active Process을 표시하게 됩니다. 2018년 9월 22일 filename\location

Glance 화면표시내용 Softkeys 이 항목은 Glance에서의 이동 및 특정 항목 설정을 위한 Menu로서 기본적으로 F5 Key는 다른 항목의 Menu로 이동을 의미하고 다른 Function Key들은 F5를 누를 때마다 표시되는 항목이 바뀌게 됩니다. 2018년 9월 22일 filename\location

중요항목별 점검방법 Glance를 실행하여 여러 시스템 자원을 확인하고 문제가 있는 자원에 대한 점검을 하여야 합니다. 확인된 문제는 원인을 찾아 해결 해야 합니다. 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법 (Glance : Global) CPU, Disk, Memory 및 Swap의 전반적인 사용량을 대략적으로 확인합니다. 모든 항목 (CPU, Disk, Memory, Swap)중 사용량이 80%이상 사용하는 항목에 대한 자세한 점검을 하여야 합니다. Glance가 실행 시 처음화면 입니다. 각 Global Bar들은 각각의 상태를 나타내고 있으므로 문제 해결을 위한 기본적인 출발점을 제시 합니다. 이 화면에서는 Process Threshold 에(CPU,Disk) 따라 나타나는 Top Process들의 사용을 감시하고 이를 통해 어떤 문제점이 있는가를 생각 할 수 있게 도와 줍니다. Pri 항목에서는 각 Process들이 Aging 에 의해 150 전,후의 값을 갖지 못하고 240전,후의 값을 가지고 있는것을 확인합니다. Aging이 발생했다는 것은 그 Process가 과도하게 CPU를 점유한 결과 이므로 이 프로세스에 대한 조사가 필요 합니다. CPU Util 이나 Disk IO Rate이 높은 프로세스들을 확인하여 문제점을 찾아야 합니다. 2018년 9월 22일 filename\location

Glance : Global 표시 항목 소개 Process : 이 프로세스의 수행가능한 code를load하기 위해 사용되는 이름 Name : 할당된 공간에 적합한 그 이름의 약자 PID : Process Identifier PPID : 이 프로세스를 처음으로 fork시킨 프로세스의 PID Pri : CPU에 대한 Control을 마지막으로 그만 두었을 때 이 프로세스가 가지는Priority. Priority는 더 높은 우선순위를 지칭하는 낮은 숫자를 가지고 숫자화 된다. 0 부터 127 까지는 특정 시스템 daemon 들이나 real- time process들을 위해 예약된 high priority들이다. 대부분의 프로세스들은 timeshare priority라 고려되어지는 128에서 255 사이의 priority를 가진다. 이러한 범위의dispatch priority를 가진 정상적인 timeshare 프로세스들은 프로세스의 CPU demand와 시스템의 load에 따라 달라진다. Nice priority에서 수행하는 프로세스들은 이column에서 전형적으로 더 높은 숫자를 가진다 User Name : 이 프로세스를 시작시킨 user의 로그인 이름 CPU Util : Current/Average Format으로 보여지는 CPU Usuage 일반적으로 모든 프로세스들에 대한 전체 CPU Usage는 Global Bar에서 보여지는 전체 CPU usage와 동일하지 않다. 이런 어긋남은 Kernel 그 자체 보다는 다른 특정한 프로세스들의 탓이 될 수 없는 ( hardclock interrupt과 같은) 시스템 interrupt에 소비되는 CPU time을 반영한 것이다 Interrupt를 유발하는 그 프로세스를 결정할 수 있는(can) Kkernel이 있는 곳에서, 시간(time)이 그 프로세스이 탓이 된다. 그 프로세스를 목록화한 CPU Time은 그 프로세스에 귀착된 time만을 반영하고, 반면에 Global CPU Bar는 그 시간이 귀결될 수 (attributed) 있는지에 관계 없이 모든(all) CPU time을 반영한다. 따라서 “All Processes”가 Threshold Filter Options에 의해 선택됐을 때라도 서로 동일하지 않을 것이다. Cum CPU : 그 프로세스가 fork되거나 statistics가 reset된 이래, 이 프로세스에 의해 누적된 (cumulative) CPU time이 사용된다 Disk IO Rate : current/average format으로 보여지는 physical disk I/Os의 비율 (rate) 예를 들어, 프로세스 spserver의 last interval동안 초당 1.7의 physical disk I/O와, midaemon이 시작되거나 statistics가 reset된 이후 매초당 1.1의 physical access들의 평균치를 기록했다. RSS : Resident Set Size, 즉 이 프로세스가 현재 사용하고 있는 physical RAM의 kilobytes이다. 이것은 library segments에 있는 shared memory뿐만 아니라 그 프로세스의 data, stack, 그리고 text segments로 할당된 memory를 포함한다.비록 shared regions의 전체 size가 그것을 참조하는 각 프로세스로 목록화 되어 있을지라도, 그 region은 단지 한번 physical하게 memory에 있다. statdaemon process (figure 5-2)와 같은 몇몇의 HP-UX 시스템 daemon들은 kernel memory를 사용하고 메모리의 많은 부분을 할당하지 않는다. 이러한 daemon들은 이 필드에서 na (not applicable)를 전시한다 Thread Count : 표시되고 있는 Process에서 사용하고 있는 Thread 갯수 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법 (Glance : Select Process) Global 화면에서 문제가 있어 보이는 프로세스를 “s”를 실행하여 PID를 선택하면 이 화면을 볼 수 있으며 여기에서 Softkey들을 눌러 이 프로세스의 Resource, Wait State, Memory Region 그리고 Open File들을 확인 할 수 있습니다. 선택된 프로세스의 Resource사용 현황을 확인하고 Wait Reason이 무엇인지 확인 합니다. Softkey 에서 F2(Wait State), F3(Memory Regions), F4(Open Files), F6(Process Syscalls) 등을 실행하여 이 프로세스가 어떤 상태인지를 확인할 수 있습니다. 2018년 9월 22일 filename\location

Glance : Select Process Wait State 표시 항목 소개 CACHE 프로세스가 getblk나 getnewbuf와 같은 memory buffer cache operation을 기다리면서 막혀진다(blocked) DISK ( read, write, 혹은 bufffer access, control 과 같은) disk request를 기다리면서 막혀진다. DUX ( read, write, 혹은 bufffer access, control 과 같은) diskless operation을 기다리면서 막혀진다 INODE system inode request를 기다리면서 막혀진다. IO ( HIL, SRM, VME, 혹은 GPIO와 같은) non-disk I/O requests를 기다리거나, disk ( physio )쪽으로나 부터의 raw I/O를 기다리면서 막혀진다. IPC shmat과 같은 shared-memory control operations을 기다리면서 막혀진다. LAN LAN hardware card request를 기다리면서 막혀진다. MBUF memory buffer request ( 이경우 buffer는 inbound와 outbound cluster traffic을 위해 사용되는 ) 를 기다리면서 막힌다. MESG msgrcv, msgsnd와 같은 message operation을 기다리면서 막힌다. NFS ( read, write, 혹은 control 과 같은) network file system을 기다리면서 막혀진다. PIPE pipe operation을 기다리면서 막혀진다. PRI CPU를 사용하는 다른 프로세스 때문에 프로세스가 막히는 것을 말한다. 이것은 다른 프로세스가 더 높은 우선순위를 가지거나 현재 프로세스의 이용가능한 time slice quantum이 고갈될 때 일어난다. RFA read와 같은 remote file access reequest를 기다리면서 일어난다. SEM 프로세스가 semop와 같은 semaphore operation을 기다리면서 막혀진다.(blocked) SLEEP sleep 이나 wait call을 기다리면서 막혀진다. SOCKT ( connect나 send 와 같은 ) socket operation을 기다리면서 막혀진다. SYS 이용가능하게 되기 위해서 ( audit, security, 혹 page control 과 같은 ) 일반적인 kernel resources를 기다리면서 막혀진다. TERM ( read, write, 혹은 control 과 같은 ) terminal (tty or pty) request를 기다리면서 막혀진다. VM ( page in, page out, 그리고 memory lock 과 같은 ) virtual memory operation을 기다리면서 막혀진다. OTHER 위에서 언급된 것과 관련이 없는 자원들을 기다리면서 막혀진다. 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법 (Glance : CPU Page 1/2) CPU를 차지하고 있는 각 Process 들의 상태가 어떤 상태 인지를 확인 합니다. User+Nice와 System의 비율을 확인합니다. Idle 상태와 User+Nice+System 상태의 비율을 확인합니다. “c”를 누르면 이 화면을 볼 수 있습니다. 항상 User State나 Nice State의 실행이 가장 많아야 하며 System혹은 다른 State가 많이 CPU를 점유 할 경우 성능 문제가 발생할 수 있으며 이를 예방하기 위해 적절한 튜닝을 하여야 합니다. Context Switch가 많이 발생하고 Idle State가 없다면 Active Process들이 무엇인지 확인하고 해당 프로세스가 정상 동작하는 지를 확인해야 합니다. 2018년 9월 22일 filename\location

Glance : CPU 1/2 표시 항목 소개 Current last interval 동안 이 activity에 전념된 CPU time의 percentage. Average GlancePlus가 시작되거나 Zero command ( z )에 의해 statistics가 reset된 이후 이 activity에 소비된 평균 percentage. High GlancePlus가 시작되거나 Zero command ( z )에 의해 statistics가 reset된 이후 이 activity에 사용된 최고치의 percentage time Time last interval동안 이 activity에 소비된 시간의 양. Current column에서는 percentage로 나타난다. Cum Time GlancePlus가 시작되거나 Zero command ( z )에 의해 statistics가 reset된 이후 이 activity에 할당된 축적된 CPU time User 정상적인 우선순위(priority)가 적용될 때 user program code를 수행하는데 소비되는 시간. User time의 나머지는 Nice CPU나 Real-Time CPU아래로 계산된다. Nice nice priority 값으로 user code를 구동하는데 소비되는 시간 ( see man-page nice (1)) 일반적으로 nice value는 양수이고, 그것은 일반적인 프로세스들보다도 더 낮은 priority를 준다. 하지만 super-user들은 그 code에 더 높은 CPU priority 를 주기위해 음수의 nice value로 프로세스들을 스케줄링 할 수 있다. Real Time rtprio에 의해서 dispatch된 프로세스들에 주어진 시간 ( see man-page riprio (1) ) 이러한 프로세스들은 더 높은 CPU dispatching priority를 가진다.:busy 시스템에서 그것들은 다른 프로세스들이 수행하는 것을 막는다. System ( ContSwitch와 Idle아래로 cover된 시간 이라기 보다 ) 시스템 call과 code를 수행하는데 소비되는 시간 모든 HP-UX 프로세스들은 system code에 몇몇의 수행시간 (execution time)을 소비하지만, 큰 System value는 불필요하거나 비효율적인 시스템 call을 만드는 프로그램들을 가진 문제의 지칭일 수도 있다. Interrupt code를 다루는 시스템 interrupt를 수행하는데 소비된 축적된 시간. 높은 Interrupt rate은 높은 I/O rate을 가진 시스템에서 일어난다. 비정상적이게 높은 Interrupt rate은 hardware 문제를 지칭하는 것일 수도 있다. ContSwitch프로세스들 사이에 context switching을 하는데 소비되는 시간 이것은 time alotment가 만기된 후에 구동하는 프로그램이 CPU를 포기해야만 할 것인지 어떤지를 고려하는데 소비되는 시간을 지칭한다. 이것은 idle loop에서 소비되는 시간이나 다음에 구동될 프로세스가 어느 것인지를 결정하기 위해서 시스템에 의해서 사용된 시간을 포함하지는 않는다. Idle 시스템이 프로세스 없이 idle한 상태로 있던 시간과 다음에 구동될 프로세스를 선택하는데 ( the function of the “idle loop”) 소비되는 시간의 합. 초과적인 idle time은 비효율적인 CPU power의 사용을, zero의 idle time은 CPU bottleneck 상황을 지시한다. 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법 (Glance : CPU Page 2/2) CPU의 Load Average를 확인 합니다. Syscall Rate와 Interrupt Rate을 확인하고 Context Switch Rate가 높은지 확인합니다. CPU조회 화면에서 “f”를 누르면 볼 수 있습니다. 만약 자세한 각CPU의 사용을 확인하려면 “a”를 실행하여 모든 CPU의 상태를 확인하면 됩니다. Load Average가 5 이상이면 시스템의 증설이 요구 되는 기준점이 됩니다. Active Process의 개수 가 많고 Context Switch Rate가 높으면 시스템의 성능이 저하를 알리는 신호 입니다. 2018년 9월 22일 filename\location

Glance : CPU 2/2 표시 항목 소개 Load Average CPU 스케줄링을 기다리면서 “run” state에 있는 프로세스들의 평균 수. 또한 run queue length라고도 불린다 SysCalls 모든 프로세스들에 의해 만들어진 system call들의 rate. Example: 만약 5초의 update interval에 걸쳐 SysCall rate이 2.0이라면, last screen update이후 일어난 system call은 10이다. ( 10 / 5 = 2 ) Interrupts 전 시스템에 대한 device interrupt들의 rate Cont Switches CPU가 한 프로세스를 구동시키는 것으로부터 다른 것으로 변화시킬 때의 context switch들의 rate 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법 (Glance : Memory) Memory에서 발생하는 Event 들에 대한 확인을 합니다. Page Out을 확인 합니다. Page Fault가 많은지 확인 합니다. “m”를 누르면 이 화면을 볼 수 있습니다. 만약 Page Out이 발생 한다면 Memory가 부족하여 발생하는 것이므로 Memory의 증설이 필요 합니다. Page Fault가 많이 발생하면 Application의 Debugging을 해봐야 합니다. 만약 VM을 많이 사용하고 있다면 DB나 Application에서 VM을 사용하지 않도록 구성하여야 합니다. 단. Memory의 충분한 여유가 있어야 합니다. 2018년 9월 22일 filename\location

Glance : Memory 표시 항목 소개 Page Faults 프로세스가 code 지시나 참조를 수행하려 할 때 기록된 fault의 수. Data page는 physical memory에 있지 않다. 그 virtual memory 시스템은 수행을 지속하기 위해서 missing code나 data르 page-in 할 것이다. 큰 (large) paging rate은 빈약한 data locality, 지나친 context switching, 혹은 충분치 못한 physical memory를 말한다. Paging Requests 일상적인 pagein과 pageout call들의 수. pagedaemon은 physical 과 virtual (secondary) memory 사이에 page들의 전송을 요구하기 위해서 이 count를 이용한다. KB Paged In 어떤 cache로도 해결될수 없는 page fault때문에 paged in (즉 disk storage로부터 physical memory로 전송된 ) 된 data의 kilobytes KB Paged Out paged-out된 ( 즉 physical memory로 부터 disk storage로 ) data의 kilobytes Reactivation/ Deactivation swapped in되고 out된 (즉 disk 로부터 physical mory로, 또 memory로 부터 disk로 이동된 ) 프로세스들의 수. 이것은 발생할 수 있는 memory bottleneck의 훌륭한 지침자이다. 만약 시스템이 workload를 효율적으로 수행하도록 필요한 memory를 부족해 한다면, 많은 프로세스들이 swapped in 과 swap out 할 것이다. ( be swapped into and out of memory ) 이것은 thrashing에 이를 수도 있는데, 시스템이 유용한 작업을 하는데 시간을 보내지 않고 swapping하는데 너무 많은 시간을 소비한다는 것이다. KB Deactivated Swapping된 data의 kilobytes. 이것은 memory pressure때문에 swapped out된 프로세스들이 수행해야만 할 때 발생하고, 따라서 memory로 되돌아와져야 한다. VM Reads virtual memory 서비스를 위해서 모든 disk drive들로부터의 physical reads의 총 count. 이것은 page fault가 nonmemory-resident file에 있는 data를 참조할때 일어난다. Diskless client 시스템에서 이 필드는 항상 0이다. 왜냐하면 VM read 혹은 write에 의해 발생하는 physical I/O는 서버에서만 일어나기 때문이다. VM Writes 모든 disk drive로의 virtual memory에 있는 file page들의 physical writes 총 count 이것은 다른 demand를 위한 공간을 만들기 위해 file page가 physical memory로부터 disk로 옮겨질때 발생한다. 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법 (Glance : Disk Page 1/2) Local과 Remote를 확인 합니다. “d”를 누르면 이 화면을 볼 수 있습니다. Disk Report는 전체 Utilization을 종합 표시합니다. Logical IO는 시스템에 영향을 주지 않지만 Physical IO의 경우는 성능 저하의 원인이 되므로 Buffer Cache의 사용량을 확인하여 80% 이하로 Hit Rate가 떨어질 경우 Buffer Cache의 증설을 고려해야 합니다. Disk Page 2/2에 나타나는 Buffer Cache Hit Rate를 확인하여야 합니다. 2018년 9월 22일 filename\location

Glance : Disk (1/2) 표시 항목 소개 Logl Reads disk로의 logical read의 수. 이것은 terminal과 modem으로의 read와 같은 non-file-system I/O를 포함하지 않는다. Logl Writes disk로의 logical write의 수. 이러한 logical counter들은 시스템 call들을 read하고 write하는 것과 직접적으로 관계가 있다. Phys Reads 이러한 프로세스를 대표하여 만들어진 disk device로부터의 physical read의 수. 이것은 file-system- , raw-, virtual memory-, 그리고 다른 시스템의 I/Os과 같은 모든 유형의 input을 포함한다. Physical transfer는 cache buffering때문에 logical I/Os와 직접적으로 관련이 있는 것은 아니다. Phys Writes 이 프로세스를 대표하여 만들어진 disk device로의 모든 유형의 physical write의 수. User user file system과 raw device file reads를 위한 file system device로부터의 physical read/write 의 수. 이것을 Phys Read/Write 의 subset이다. Vert Mem 이 프로세스와 관련된 disk device로부터의 virtual memory management (page ins)에 의한 physical read/write 의 수 . System 이 프로세스와 관련된 system activity로부터 결과 지어지는 file system으로의 physical read/write의 수 . Raw 프로세스와 관련된 Raw Device로의 Physical read/write 수 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법 (Glance : Disk Page 2/2) Local과 Remote를 확인 합니다 Disk 화면에서 “f”를 누르면 이 화면을 볼 수 있습니다. Read Cache Hit Rate는 평균 90% 정도 Write Cache Hit Rate는 평균 80% 정도를 유지하면 문제가 없으며 권장치 보다 적게 나타나거나 불규칙하게 나타날 경우 IO Job의 특성을 파악하여 Buffer Cache의 증설을 고려하여야 합니다. 일반적으로 DNLC Hit Rate가 90%이상이면 문제는 없습니다. 2018년 9월 22일 filename\location

Glance : Disk 2/2 표시 항목 소개 Read Cache Hits : Read IO 횟수 중 Buffer Cache 에서 읽은 수의 백분율 Write Cache Hits : Write IO 횟수 중 Buffer Cache 에서 읽은 수의 백분율 DNLC Hits Directory Name Lookup Cache 로서 Directory 및 파일에 대한 Cache의 Hit Rate 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법 (Glance : Network) Network Interface와 Loopback으로 발생하는 Pachet을 확인 합니다. “l”를 누르면 이 화면을 볼 수 있습니다. 각 Interface (100BT, Gigabit, Loopback)에서 발생하는 Packet량이 얼마나 많은지를 확인 합니다. 100BT의 경우 Packet Rate이 10000이상을 상회하면 Network Interface의 증설이 요구 됩니다. Network Interface의 증설 시 에는 Disk IO가 증가 할 수 있으므로 이에 대한 영향에 대한 조사도 병행 되어야 합니다. 각 Interface에서 Collision이 발생하면 Lanadmin 으로 Interface의 상태를 확인하여 Full-Duplex로 설정 되어 있는지 FCS Error가 발생하는 지를 확인 합니다. FCS Error가 발생하면 Lan Cable의 교체를 고려 해야 합니다. 2018년 9월 22일 filename\location

Glance : Network 표시 항목 소개 Idx Interface : Network Interfaced의 이름 Network Type : Network Interfaced의 종류 Packet In : Network Interfaced로 발생하는 Inbound Packet량 Packet Out : Network Interfaced로 발생하는 Outbound Packet량 Collisions : Network Interfaced로 발생하는 Collision량 Errors : Network Interfaced로 발생하는 Error Packet량 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법 (Glance : System Table 1/2) 중요 Kernel Parameter의 실제 사용량을 확인 합니다. “t”를 누르면 이 화면을 볼 수 있습니다. 시스템의 Kernel이 너무 크게 구성 되어 있을 경우 Performance에 문제가 발생 할 수 있습니다. 따라서 이를 예방하기 위해 각 Kernel Parameter들의 사용량을 확인하여 실제 사용하고 있는 적정치를 확인하고 최대 사용량을 확인하여 적정 수준에서 Kernel Tuning을 실시 하여야 합니다. 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법 (Glance : System Table 2/2) 시스템의 개략적인 Resource의 보유 현황과 Kernel Parameter의 일부를 확인합니다. System Table화면에서 “f”를 누르면 이 화면을 볼 수 있습니다. 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법 (Glance : Swap) 각 Swap Device의 사용량 Priority 구성정보 Memory Swap의 사용여부를 확인합니다. “w”를 누르면 이 화면을 볼 수 있습니다. Swap의 사용이 100%일 경우 시스템의 HANG이 발생할 수 있습니다. 따라서 항상 Swap의 사용량을 확인하여 적절한 시기의 증설이 필요 합니다. 일반적으로 Memory의 1.5 ~ 2배정도 크게 설정하지만 Memory가 32GB이상인 경우 작게 잡을수도 있습니다. 2nd Swap의 경우 External Disk에 설치하는 것이 좋습니다. 만약 Memory가 충분하지 못하면 Memory Swap을 사용하지 않는 것이 좋습니다. 이를 위해 Kernel을 수정해야 하므로 정확한 근거에 의해 조정해야 합니다. 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법 (Glance : Wait States) 선택된 프로세스가 어떤 Wait원인들에 의해 Block되고 있는지를 백분율로 확인합니다. “W”를 누르면 이 Select PID가 화면에 나타나고 PID를 선택하면 이 화면을 볼 수 있습니다. 한번 PID를 선택하면 다음부터는 같은 PID의 Wait State가 바로 표시 됩니다. 각각의 프로세스별로 확인할 수 있습니다. 가장 Bottleneck이 많은 부분에 Wait State가 가장 높은 비율로 나타나며, 이렇게 관측된 Wait State는 해당 시스템 자원의 자세한 사용현황 조사가 필요합니다. 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법(Glance : IO by File System) 모든 File System들의 Logical/Physical Disk IO를 확인합니다. Raw Device를 사용하는 경우에는 다음쪽의 Logical Volume IO Page를 확인합니다. “i”를 누르면 이 화면을 볼 수 있습니다 File System중 가장 IO가 많은 File System을 확인하고 그 File System이 계속 IO가 많으면 IO분산을 고려 하여 여러 Interface를 사용한 Stripping을 고려 해야 합니다. File System은 Buffer Cache를 사용하므로 Buffer Cache Hit Rate를 참고하여 확인해야 합니다. 2018년 9월 22일 filename\location

Glance Manual for HP-UX 중요 항목별 점검방법 (Glance : IO by Logical Volume) 모든 Logical Volume의 Logical/Physical Disk IO를 확인합니다 “v”를 누르면 이 화면을 볼 수 있습니다 Raw Device를 사용하는 경우에 유용한 화면 입니다. Raw Device는 Buffer Cache를 사용하지 않고 IO가 발생하므로 Buffer Cache의 조정을 통한 성능향상 효과는 없습니다. 따라서 DB에서 Raw Device를 사용할 경우에는 Buffer Cache를 지나치게 많이 설정할 필요가 없습니다. 2018년 9월 22일 filename\location