glance 명령어 사용법은 다음과 같습니다.
# glance -j [갱신간격(초)]
저는 개인적으로 “-j” 옵션을 선호합니다. 갱신 간격이 기본이 5초여서 신속한 정보를 보기가 힘든점이 있어 저는 “glance -j 1” 를 통해 1초 마다 갱신하도록 하여 모니터링합니다.
그럼 glance의 프로세스 정보와 Thread 정보를 확인하는 방법에 대해 설명하겠습니다.
====================================================================
다음은 glance를 수행 시 첫화면입니다.
상단에 전체적인 시스템 사용율 정보(CPU, Memory, Disk, Network등)가 나옵니다.
그리고 그 아래에 각 프로세스들에 대한 리스트와 간략한 CPU. Memory, Block 정보들이 나오게됩니다(다른 프로세스명과 User ID는 일부러 삭제했습니다.). 여기서는 java 프로세스(pid 9852)에 대한 모니터링을 설명하도록 하겠습니다.
자 그럼 해당 프로세스에 대한 상세 모니터링을 위해 “S” key를 누르고 프로세스 ID를 입력합니다.
그러면 위와 같이 해당 프로세스에 대한 상세정보가 출력됩니다.
보시면 아시겠지만 프로세스에 대한 다양한 정보들이 쭉 출력됩니다. 이러한 정보 중에서 다양한 CPU사용율정보(User, System, Interrupt 등), Memory 사용율 정보(RSS/VSS, Fault 등), Wait Reason 등의 정보를 눈여겨 보시면 좋을것 같습니다. 우선은 수치가 높은 부분은 확인을 해 볼 필요가 있겠죠.
그럼 여기서 각 Thread에 대한 정보를 확인 하기 위해 “G” key를 누릅니다.
위와 같이 각 Thread에 대한 리스트와 함께 CPU, I/O, Priority, Block 정보를 볼 수가 있습니다.
CPU의 경우 현재 사용율과 누적 사용율을 보실 수가 있습니다. 아무래도 누적 사용율이 높으면 일을 많이 하는 Thread라고 판단할 수 있습니다. 그럼 해당 Thread가 무엇인지 확인할 필요가 있습니다. 이렇때 Thread dump를 통해 TID와 매핑하여 확인할 수 있습니다.
위의 그림에서는 6949836 TID가 현재 CPU 사용을 많이 하고 있으며, CPU Time 누적치도 높게 보여집니다. 참고로 CPU Util과 CPU Time의 의미는 다음과 같습니다.
– CPU Util은 해당 모니터링 시간(glance interval이 3초라면 3초동안)동안 해당 Thread가 사용한 전체 CPU 용량(100 * CORE수의 %)에 대한 비율입니다.
– CPU Time은 해당 Thread가 실제로 CPU를 점유한 시간입니다. 보통 CPU의 Scheduling 시간(보통 1 tick이라함)이 10ms이므로 Thread가 한번에 점유할 수 있는 최대 시간은 10ms라고 볼 수 있습니다. 우선순위가 높은 Thread의 경우 CPU 점유 시간이 높을 수 밖에 없겠죠.
더욱 상세한 Thread 정보를 보기 위해서는 “I” key를 누르고 TID를 입력합니다.
위와 같이 해당 TID의 Thread에 대한 상세 정보가 출력됩니다. 프로세스의 상세정보 부분과 거의 유사한 정보들이 출력됩니다.
이렇게 glance를 통해 프로세스에 대한 전반적인 모니터링 방법에 대해 알아 보았습니다.
많은 분들이 glance 라는 툴은 잘아시는데 사용법, 특히 화면 key에 대한 부분을 잘 모르시더라고요.
저도 이러한 key를 모두 알고 있지는 않습니다. 대신 key help 화면을 위한 key는 꼭 기억하고 있습니다.^^ 화면에서 “h” key를 누르게 되면 다음과 같은 help 화면을 보실 수 있습니다.
help key만 알고있으며 필요시 key를 확인하며 사용해도 아무 지장이 없습니다.
추가적으로 프로세스에 대한 Memory 정보와 Open File정보, System call 정보에 대한 화면을 보여드리도록 하겠습니다.
– Memory 정보
프로세스에 할당된 메모리 block들에 대한 메모리 Type, 참조계수, RSS, VSS, 할당 File명등에 대한 정보를 확인하실 수 있으며, 아래에는 프로세스에 대한 유형별(Text, Data, Stack, Shared, Other) 전체적인 사용량이 출력됩니다.
– Open File 정보
프로세스가 Open한 FD(File Descriptor)에 대한 정보가 출력됩니다. 실제 File의 경로와 파일명이 잘 출력되지 않지만 Volumne과 inode정보가 있어 파일을 찾는(find -inum 명령 사용)데는 문제가 없습니다.
– System call 정보
프로세스가 수행시킨 System call 함수에 대한 항목과 그에 대한 정보들입니다.
위에서는 횟수로는 gettimeofday() 함수가 가장 많이 호출되었으며, Elapsed Time은 ksleep() 함수인것을 알 수 있습니다.
해당 프로세스가 시간과 관련된 내용을 많이 처리하는 프로세스인 것을 알 수 있으며, 이 부분이 염려할 수준은 아닌것으로 보여집니다. ksleep()은 프로세스가 SLEEP으로 빠지게 되면 호출되는 함수로 CPU JOB만 수행하는 프로세스는 아니며, I/O등의 BLOCK(임의적일수도 있음)으로 인해 SLEEP으로 빠지는 경우가 있는 것으로 보여집니다.
=========================================================================================
위와 같이 glance를 사용하면 프로세스에 대해 OS가 제공하는 거의 모든 정보를 모니터링 가능합니다.
참고로 glance는 HP-UX의 kernel trace 정보를 활용하여 보여줌으로 굉장히 막강한 기능을 제공합니다.
kernel trace를 위해 caliper나 ktrace등으로 별도로 하지 않아도 어느 정도의 정보는 제공하게 되며 이러한 정보는 시스템을 튜닝 및 trace하는데 상당한 도움이 되는 것이 사실입니다.
Solaris(DTrace)나 AIX(trace, curt등) 을 사용해 보셨다면 glance가 제공하는 실시간적인 상태 정보는 거의 환상이라고 할 수 있겠죠.
그 다음으로는 pstack 명령어입니다.
이 부분은 Solaris의 pstack과 동일하기 때문에 별도로 설명은 드리지 않겠습니다.
Solaris의 ptack 부분 (http://blog.naver.com/bumsukoh/110114008655)을 참고하시면 되겠습니다.
단, pstack은 HP Itanium 에서 사용가능한 명령어입니다.
그외 pfiles, pmap등과 같은 프로세스 관련된 유용한 명령어들이 있습니다만, 여기서는 Java 프로세스와 Thread에 대한 내용에 초점이 두었기에 다루지 않도록 하겠습니다.
(다음 기회에 HP-UX의 프로세스 관련 명령어를 통한 모니터링 방법에 대해 설명드리겠습니다.)
다음은 gdb인데요. 굳이 gdb까지 사용하여 뭔가 트러블슈팅하는 경우는 그렇게 많지 않을 것 같은데요.
알고 있으면 상당히 유용한건 사실입니다. (써먹을 기회가 별로 없어서 그렇지만요 ㅠ.ㅠ!)
자, 그럼 gdb를 어디에 써먹을 것인가? gdb는 Unix 프로세스를 debugging하기 위한 툴입니다.
이 툴은 보통 C 언어의 프로그램을 디버깅하는데 사용됩니다.(물론 C++, Fortran, Ada등도 가능합니다.)
Java 기반의 시스템과 프로그램이 많아지면서 HP-UX에서는 gdb에서 Java에 대한 분석도 가능하도록 하기 위한 기능을 제공하게 됩니다.
Java Unwind LIbrary라고 하는것인데.. 자세한 사항은 “HP-0UX 에서 gdb를 이용해 Java 프로세스 core 분석하기 !!” (http://blog.naver.com/bumsukoh/110112408842) 포스트를 참고하시면 될 것 같습니다.
그 외에 프로세스 프로파일링을 위한 막강 프로파일 툴인 caliper 등을 활용할 수 있으나, 굳이 Java기반에서는 이러한 프로파일링 툴까지 쓸 필요는 없을것 같고, 대신 Java를 위한 프로파일링 툴은 알아둘 필요가 있습니다. 이 부분은 이번 연재의 뒷부분에서 다루도록 하겠습니다.