1. iostat
  2. 별도의 설치 필요없음, 물리적 드라이버 별로 기본적인 Disk Read/Write 볼 수 있음
  3. 한 개 이상의 디스크 드라이브에 대한 입출력 통계와 CPU 활용량

    arg-cpu
    %user
    %nice
    %system
    %iowait
    %steal
    %idle
    마지막 재부팅 이후의 평균 CPU 활용량 어플리케이션 등 사용자 모드에 소모된 시간 nice를 사용하여 스케줄링 우선순위가 바뀐 프로세스에 소모된 시간 시스템(커널)이 사용한 시간 디스크I/O 요청 때문에 CPU가 대기한 시간 다른 가상 CPU가 서비스하는 동안 비자발적으로 대기한 시간 대기한 시간
    Device
    tps
    kB_read/s
    kB_wrtn/s
    kB_read
    kB_wrtn
    디바이스 구분 초당 전송(입출력) 수 초당 읽혀진 KB (Blk일 경우 512바이트 블록수) 초당 쓰여진 KB (Blk일 경우 512바이트 블록수) 지금까지 읽혀진 KB(Blk일 경우 512바이트 블록수) 지금까지 쓰여진 KB(Blk일 경우 512바이트 블록수)
  4. vmstat
  5. 별도의 설치 필요없음, 시스템의 리소스 상황(CPU, I/O, Memory)을 모니터링 할 수 있음 (http://jikime.tistory.com/286)

  6. vmstat(옵션없음) - 마지막 부팅 이후의 평균값

  7. vmstat 2 10 => 2초 간격으로 10회 정보 갱신

    procs memory swap io system cpu
    r b w swpd free buff cache si so bi bo in cs us sy id wa
    현재 실행중인 프로세스의 수(CPU 접근 대기 중인 실행 가능 프로세스 수) 인터럽트가 불가능한 sleep 상태에 있는 프로세스의 수 (I/O 처리를 하는 동안 블럭 처리된 프로세스) 강제로 스왑아웃된 프로세스 사용하고 있는 swap 메모리 양(사용된 가상 메모리 용량) 사용가능한 메모리 양 버퍼로 사용되고 있는 메모리 양 캐시로 사용되고 있는 메모리 양 swap in(디스크에서 메모리로 스왑된 메모리 용량) swap out(디스크로 스왑되어 나간 메모리 용량) 초당 블럭 디바이스로 보내는 블럭 수(블록 장치로 보내진 블록) 초당 블럭 디바이스로부터 받은 블럭 수(블록 장치에서 받아온 블록) 초당 인터럽트 되는 양 초당 context switch되는 양 사용자의 CPU 사용 시간 비율(CPU가 사용자 수준 코드를 실행한 시간, 백분율 단위) 시스템의 CPU 사용 시간 비율(CPU가 시스템 수준 코드를 실행한 시간, 백분율 단위) CPU idle time(백분율 단위) 입출력 대기
    1. top
    2. 별도의 설치 필요없음, CPU 점유 프로세스들을 실시간으로 조회하는 명령어 (http://weezzle.net/1360)

    • 1줄 top : 시스템의 전반적 상태(가동시간 등)

    • 2줄 Tasks : 프로세스들의 상황

    • 3줄 CPU : CPU의 상황

    • 4줄 Mem : 메모리 상황

    • 5줄 Swap : 스왑 메모리 상황

    • 6줄

      PID
      USER
      PR
      NI
      VIRT
      RES
      SHR
      S
      %CPU
      %MEM
      TIME+
      COMMAND
      프로세스 ID 프로세스를 실행시킨 사용자 ID 프로세스의 우선순위 NICE 값 가상 메모리의 사용량(SWAP+RES) 현재 페이지가 상주하고 있는 크기(Resident Size) 분할된 페이지, 프로세스에 의해 사용된 메모리를 나눈 메모리의 총합 프로세스의 상태(Sleeping, Running, sWapped out process, Zombies) 프로세스가 사용하는 CPU의 사용율 프로세스가 사용하는 메모리의 사용율 CPU TIME, hundredths 실행된 명령어
    1. free
    2. 시스템의 실제메모리와 스왑메모리에 대한 사용현황을 확인할 수 있는 명령어 (http://blog.naver.com/PostView.nhn?blogId=jwmoon74&logNo=100174011942)
    • 1줄 Mem : 시스템의 물리적인 메모리에 대한 사용량을 각 필드 단위로 표시

      total
      used
      free
      shared
      buffers
      cached
      전체 메모리의 용량으 Kbyte단위(default)로 표시 현재 시스템에서 사용중인 메모리의 량을 Kbyte 단위로 표시 현재 시스템에서 사용중이지 않은 메모리의 량을 Kbyte단위로 표시 현재 시스템에서 공유한 메모리의 용량을 표시 현재 시스템에서 buffering된 메모리의 량을 표시 현재 시스템에서 caching된 ㅣ메모리의 량을 표시
    • 2줄 -/+ buffers/cache : 현재 캐시 메모리에서 버퍼링된 사용량을 표시(used/free)
    • 3줄 Swap : 서버설치 시에 결정한 스왑메모리의 량, 스왑메모리는 디스크의 일부분을 메모리로 잡아서 설정되기 때문에 스왑메모리가 많이 사용되고 있다는 것은 시스템의 전체적인 속도가 떨어진다는 것을 의미하며 지속적으로 스왑메모리가 사용된다는 것은 결국 실제 메모리를 증설해야 한다는 것이다.

      total
      used
      free
      시스템의 전체 스왑메모리의 량을 표시 전체 스왑메모리 중에서 현재 사용중인 스왑메모리의 량을 표시 전체 스왑메모리중에서 사용되지 않고 남아 있는 메모리의 량
    1. iotop
      1. 별도의 설치 필요함, Python 2.5+, linux kernel 2.6.20+ 이 2개의 프로그램이 기본적으로 설치되어 있어야 함
      TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND

     

     


    CPU - perf, top, htop

    Memory - valgrind, smem

    Disk I/O - nmon, bonnie, sysstat

    Network - netperf, iftop, netstat

     

     

    출처 : http://visu4l.tistory.com/398

    블로그 이미지

    프로그래머 지향자 RosaGigantea

    바쁜 일상 생활중의 기억 장소

    Tag Linux

    대부분의 개발자들은 버그를 없애기 위해 많은 시간과 노력을 들인다. 그럼에도 막상 소프트웨어를 출시하고 나면 미처 발견하지 못한 버그로 낭패를 당하기 십상이다. 시간과 비용의 재투자는 말할 것도 없다. 이 같은 이유에서 개발자라면 누구나 자신이 작성한 프로그램의 버그를 찾아주는 툴이 있었으면 하는 바람을 가진다.

    Sparrow는 C/C++ 프로그램의 소스를 분석하고 치명적인 오류를 찾아주는 툴이다. 테스트 케이스 실행을 통해 오류를 찾는 기존 테스팅 방법과 달리 프로그램 실행 없이 소스 코드만 분석하여 자동으로 프로그램의 오류를 찾아준다. 시간과 비용을 줄이는 완전히 다른 형태인 것이다.

    ■ 소스 코드에서 오류 검색
    Sparrow는 C/C++에서 흔히 발생하는 메모리 관련 오류를 찾아낸다. 메모리 관련 오류로는 버퍼 오버런(buffer overruns), 메모리 누수(memory leaks), 메모리 해제 후 사용(memory uses after free) 등이다. 이번 리뷰는 프로그램 소스를 쉽게 구할 수 있는 공개 소프트웨어 분석으로 진행했다. 테스트 환경은 펜티엄4 3.2GHz와 4GB 메모리가 설치된 PC와 리눅스 운영체제를 사용하였다.

    사용 방법은 간단하다. Makefile이 있는 디렉토리에서 간단한 명령어를 입력하면 분석을 시작하고, 결과까지 알려준다. 먼저 smake라는 명령어를 실행해 소스 트리의 구조를 파악하고 실행 파일이나 라이브러리를 만드는데 필요한 파일을 정리한다.

    C/C++ 환경의 메모리 오류 검색 smke 이후 생성된 분석 단위

    그리고 분석하고 싶은 실행 파일이나 라이브러리를 선택하여 분석을 하면 된다. 분석 결과는 HTML 페이지로 만들어지므로 웹 브라우저에서 확인이 가능하다. 우선 tar를 분석하는 데 걸리는 시간을 측정하였더니 100초 정도가 소요되었다. tar의 소스 크기가 28,000라인 정도 되니까 분석 속도는 매우 빠른 편이다.

    Sparrow는 tar에서 총 26개의 메모리 누수와 버퍼 오버런이 발생할 수 있다고 분석했다. 대부분의 소스 코드 분석기 툴이 그렇듯이, 여기서 알려주는 오류는 진짜 오류가 아닐 수 있다. 따라서 오류의 진위여부를 확인할 필요가 있다.

    ■ 스코어 기능, 분석 결과 진위 여부 확인
    Sparrow는 분석 결과로 알려준 오류가 진짜 오류인지 거짓 오류인지를 사용자가 쉽게 판단 할 수 있도록 두 가지 기능을 제공한다. 하나는 분석기에서 나온 오류의 형태를 보고 통계적인 방법을 사용해 오류의 여부를 점수로 매기는 스코어 기능이다. 사용자는 오류에서 스코어가 높은 순서대로 하나씩 확인하여 걸러내면 된다.

    이는 Sparrow만의 독특한 기능이라고 하겠다. 다른 한 가지는 프로그램이 실행되고 어떤 과정에서 오류가 발생하는 지를 확인할 수 있도록 오류의 근원에서 발생 시점까지 흐름을 추적해준다. 해제 후 사용 오류와 메모리 누수 오류의 경우에는 함수 호출과 리턴 등의 프로그램 실행 흐름의 큰 변화가 일어나는 지점에 한해 정보를 제공한다.

    tar 분석 결과 중 일부 버퍼 오버런 경고 화면

    버퍼 오버런의 경우는 실행 흐름의 정보가 매우 자세하다. 예를 들어, 버퍼 buf가 buf[x]라는 식을 통해 접근이 되었다면, buf와 x의 값에 영향을 주는 명령어만 링크로 연결하여 보여준다. 이러한 연결 고리를 Sparrow에서는 reason chain이라고 한다. 사용자는 오류 확인을 위해 꼭 필요한 명령문만 확인하면 된다는 얘기다.

    실제로 tar 분석으로 나온 버퍼 오버런이 진짜인지 reason chain으로 쉽게 확인할 수 있었다. 부가적으로는 매크로, 변수, 함수를 정의한 지점을 찾는 기본적인 기능과 정의된 함수가 어느 지점에서 호출되었는지 함수 포인터를 통해 호출한 곳까지 찾아 알려준다.

    ■ 프로그램 버그 해결 도우미
    Sparrow는 단순히 오류가 발생한 위치만 알려주는 툴이 아니다. 그 오류가 발생한 실행 흐름 중에서 꼭 체크해야 하는 부분을 알려주므로 라인 하나하나를 일일이 살펴볼 필요가 없다. 작업 속도가 생명인 테스트 과정에서 더없이 중요한 사항이다. 참고로 큰 규모의 프로그램 분석 성능은
    www.spa-arrow.com에서 확인할 수 있다.

    메모리 누수 경고 화면 메모리 누수가 발생한 지점 화면

    최근 들어 소프트웨어 오류에 대한 관심과 우려가 집중되고 있다. 프로그램 덩치가 거대하고 복잡해지면서 오류의 원인도 점점 찾기가 힘들어질뿐더러 숨겨진 오류가 언제 나타날지 모르기 때문이다. 더군다나 디지털화가 가속되면서 곳곳에 쓰이는 소프트웨어의 오류는 일상생활과 밀접하게 연관될 수밖에 없다. 그래서 버그 해결의 중요성은 누차 강조해도 모자람이 없다.

    Sparrow는 사용자가 분석 결과를 쉽게 확인할 수 있게끔 편의성 높은 UI와 기능을 제공한다. 누구나 사용할 수 있음을 의미한다. 오랜 기간 동안 사용되고 검증된 공개 프로그램을 분석한 탓에 리뷰 과정에선 버퍼 오버런 오류가 거의 없었다. 반면 메모리 누수 오류는 꽤 많이 발견되었다. 프로그램 버그로 인한 고민을 한다면 Sparrow가 그 대안이 될 수 있겠다.

     
    전민식 월간 마이크로소프트웨어 필자 msjin@gmail.com | 2007-05-07 13:01


    더 보기 http://www.ebuzz.co.kr/content/buzz_view.html?ps_ccid=21988#ixzz0sg5q9E5I

    블로그 이미지

    프로그래머 지향자 RosaGigantea

    바쁜 일상 생활중의 기억 장소