2009.02.04 09:32

http://www-933.ibm.com/support/fixcentral/
Posted by saudades

댓글을 달아 주세요

2009.02.03 17:46

From : http://www.ibm.com/developerworks/kr/library/au-aix5_cpu/

CPU 모니터링과 튜닝 (한글)

CPU 병목 현상 제거하고 성능 향상하기

developerWorks


난이도 : 초급

Wayne Huang, Senior Consultant, IBM
Lee Cheng, Senior Consultant, IBM
Matthew Accapadi, Senior Software Engineer, IBM
Nam Keung, Senior Programmer, IBM

2006 년 12 월 12 일
2006 년 12 월 12 일 수정

표준 AIX® 툴로 CPU 병목 현상을 진단하는 방법을 배워봅시다. IBM 성능 전문가가 CPU 활용, 쓰레드 우선순위,스케줄링을 위한 툴에서 생성된 리포트를 해석하여 성능을 높일 수 있는 방법을 설명합니다. 실제 예제에 기반한 두 개의 케이스스터디도 있습니다.

머리말

AIX5L™Version 5.3은 eServer™ p5 시스템에서 동시 멀티 쓰레딩(SMT)으로 높은 쓰루풋과 성능을 제공하는AIX® 운영 체계의 최신 버전이다. 고급 가상화 지원을 통해, AIX 5L Version 5.3은 서버 활용도를 획기적으로높이고, 보다 효율적인 관리를 위해 워크로드를 통합한다.

컴퓨팅과 운영 체계의 역사를 돌아보면, 컴퓨터공학자들은 많은 CPU 스케줄링 정책들을 개발해왔다는 것을 알 수 있다. First-in, first-out (FIFO),shortest job first, round robin을 비롯하여, 이외에도 많은 것들이 있다. 한 가지 정책이 모든애플리케이션에 딱 맞는 것은 아니기 때문에 스케줄링 정책은 중요하다. 특정 워크로드를 지닌 어떤 애플리케이션은 디폴트 스케줄링정책으로도 잘 실행될 수 있다. 하지만, 다른 워크로드를 가진 같은 애플리케이션이 최적의 성능을 이룩하기 위해서는 스케줄링 정책조정을 해야 한다.

: 이 글은 AIX 5.3 성능에 초점을 맞춘다. 고급 가상화는 이 글에서는 설명하지 않겠다. AIX 5L Version 5.3 특징, 툴, 기능을 위주로 설명하도록 하겠다.




위로


SMT란 무엇인가?

SMT는 한 개 이상의 하드웨어 쓰레드에서 명령어들을 동시에 내보낼 수 있는 물리적 프로세스의 기능이다. AIX 5L Version5.3에서, 하나의 물리적 프로세스로 구현된 전용 파티션은 기본적으로 논리적 2-way로 설정된다. 두 개의 하드웨어 쓰레드가한 개의 물리적 프로세서에서 동시에 실행될 수 있다. SMT는 개별 쓰레드의 쓰루풋 보다 전체 쓰루풋이 더 중요할 경우에 더효과적이다. 예를 들어, 웹 서버와 데이터베이스 서버는 SMT의 대상이 된다.

프로세서와 애트리뷰트 정보 보기

SMT는 기본으로 실행된다. (Listing 1)


Listing 1. SMT
# smtctl

This system is SMT capable.

SMT is currently enabled.

SMT threads are bound to the same physical processor.

Proc0 has 2 SMT threads

Bind processor 0 is bound with proc0

Bind processor 2 is bound with proc0

Proc2 has 2 SMT threads

Bind processor 1 is bound with proc2

Bind processor 3 is bound with proc2

# lsattr -El proc0

frequency 1656376000 Processor Speed False

smt_enabled true Processor SMT enabled False

smt_threads 2 Processor SMT threads False

state enable Processor state False

type PowerPC_POWER5 Processor type False

smtctl 명령어는 권한이 있는 사용자와 애플리케이션에 SMT 지원으로 프로세서의 사용을 제어할 수 있는 기능을 제공한다. 이 명령어를 사용하여 SMT를 켜거나 끌 수 있다. smtctl 명령어 신택스는 다음과 같다:

smtctl [-m off | on [ -w boot | now] ]

공유 프로세서란 무엇인가?

공유 프로세서는 타임슬라이스 기반으로 파티션에 할당된 물리적 프로세서들이다. 공유 프로세서 풀에서 물리적 프로세서를 사용하여 공유프로세서 풀을 사용하는 파티션의 실행 요구를 채울 수 있다. eServer p5 시스템에는 공유 파티션과 전용 파티션이 혼합되어포함된다. 파티션은 모두 전용 또는 공유여야 하고, 이 두 가지를 변경하기 위해 동적 LPAR(DLPAR) 명령어를 사용할 수없다. 파티션의 실행을 중지하고, 전용에서 공유로, 또는 그 반대로 변환해야 한다.

프로세싱 단위

파티션이 설정된 후에는 여기에 프로세싱 단위들을 할당할 수 있다. 하나의 파티션은 최소 10분의 1 프로세서를 가져야 한다. 요구사항에 맞춘 후에, 프로세싱 단위를 프로세서의 100분의 1 세분성으로 설정한다. 공유 프로세서를 사용하는 파티션을 공유파티션이라고 한다. 전용 파티션은 전용 프로세서를 사용한다.

각 파티션은 10 밀리초(MS) 타임슬라이스 동안 실행 디스패치 시간(백분율)으로 설정된다. 예를 들어:

  • 0.2 프로세싱 단위를 가진 파티션에는 각 타임슬라이스 동안 20 퍼센트의 용량이 할당된다.
  • 1.8 프로세싱 단위를 가진 파티션에는 10ms 타임슬라이스 동안(멀티 프로세서 사용) 18ms 프로세싱 타임이 할당된다.

사용되지 않는 사이클들은 누적되지 않는다. 파티션이 할당된 프로세싱 용량을 사용하지 않으면 초과 프로세싱 시간은 공유 프로세싱 풀로 양도된다.

공유 프로세서를 가진 파티션들은 Capped 또는 Uncapped 된다. Capped 파티션에는 정해진 제한 용량이 할당된다.파티션이 추가 CPU 사이클(총 프로세싱 단위 이상)을 요구하면, 공유 풀에서 사용되지 않은 용량을 활용할 수 있다.




위로


스케줄링 알고리즘

AIX5는 FIFO, round robin, fair round robin 등의 스케줄링 정책을 구현한다: FIFO 정책은 세 개의다른 구현을 갖고 있다: FIFO, FIFO2, FIFO3. Round Robin 정책의 이름은 AIX에서는SCHED_RR이고, fair round robin은 SCHED_OTHER이다. 다음 섹션에서 이러한 정책들을 보다 자세히설명하겠다.

스케줄링 정책들은 이들을 어떻게 할당하고 관리하느냐에 따라서, 시스템 성능에 큰 영향을끼친다. 예를 들어, FIFO는 많은 CPU를 사용하는 작업에는 유용하지만, 라인에서 대기하는 다른 모든 작업들을 체크아웃 할수 있다. 기본적인 Round Robin은 “타임슬라이스” 또는 “퀀텀”을 시간 공유 방식으로 각 작업에 제공한다. 결과적으로,I/O 중심의 태스크를 위주로 구분하게 된다. 그러한 태스크들은 I/O 대기 때문에 CPU를 자발적으로 포기한다. 작업은 실행동안 CPU 시간의 퀀텀을 누적하면서 스케줄링 우선 순위가 변하기 때문에 “공정(fair)”하다. 운영 체계는 CPU를 잡고있는 것을 강등시켜서, I/O 관련 작업들이 CPU 리소스를 사용하는데 공정한 기회를 가질 수 있도록 한다.

스케줄링에 대해 자세히 알기 전에 두 개의 중요한 개념을 파악해야 한다. nice 값과 AIX 우선순위 및 실행 큐 구조이다.

nice와 renice 명령어

AIX에는 두 개의 중요한 스케줄링 명령어가 있다: nicerenice이다. AIX에서 사용자 작업은 기본 우선순위 레벨 40과 기본 nice 값 20을 수행한다. 이 두 가지 숫자는 기본 우선 순위 레벨 60을 형성한다. 이 값은 시스템의 대부분의 작업들에 적용된다.

nice -n 10 myjob 같은 nice 명령어로 작업을 시작하면, 10은 delta_NICE이다. 이 숫자는 기본 20에 더해져서 30이라는 새로운 nice 값을 만들어 낸다. AIX에서, 수가 높을수록, 우선 순위는 낮아진다. 이 예제를 사용하여, 여러분의 작업은 우선순위 70으로 시작하는데, 기본 우선순위 보다 10 레벨이나 더 아래로 내려갔다.

renice 명령어는 이미 시작된 작업에 적용된다. 예를 들어, renice -n 5 -p 2345 명령어는 2345 프로세스가 nice 값 25를 갖게끔 한다. renice 값은, 현재 프로세스의 nice 값에 상관 없이, 기본 nice인 20에 적용된다.

AIX 우선 순위와 실행 큐 구조

하나의 쓰레드는 0부터 255까지의 우선 순위 범위를 수행한다. (AIX 5L 이전의 시스템에서는 1에서 127이였다.) 우선순위0은 가장 높은 우선순위이고, 255는 가장 낮은 우선순위이다. AIX는 256 우선 순위 레벨의 쓰레드들을 효율적으로 지원하기위해 256-레벨 우선순위 큐의 형태로 실행 큐를 관리한다.

AIX는 256-비트 어레이를 구현하여256 레벨의 큐에 매핑한다. 특정 큐 레벨이 비어있다면 상응하는 비트는 0으로 설정된다. 이렇게 설계한 이유는 AIX스케줄러가 최초의 비어있지 않은 레벨을 빠르게 찾아서, 그 레벨에서 실행할 준비가 된 작업을 시작할 수 있도록 하기 위해서이다.아래 그림 1의 AIX 실행 큐 구조를 보자.


그림 1. 스케줄러 실행 큐
Scheduler run queue

그림 1에서, 스케줄러는 출발 할 준비가 된 모든 쓰레드의 실행 큐를 관리한다. 각각의 우선순위를 지진 모든 출발 준비가 된 쓰레드들은 실행 큐에서 연속적인 위치를 차지하고 있다.

AIX5L은 각 CPU에 대한 하나의 실행 큐와 하나의 글로벌 큐를 구현한다. 예를 들어, eServer pSeries® p590머신에는 32개의 실행 큐와 한 개의 글로벌 큐가 있다. CPU 당 실행 큐로, 쓰레드는 선점 후에 같은 CPU로 돌아갈 수있는 더 나은 기회를 갖게 된다. 또한, 실행 큐 구조를 잠그게 되는 결과를 야기하는 CPU들 간 경쟁도 다중 실행 큐들로 인해훨씬 줄어든다.

하지만, 어떤 상황에서는, 다중 실행 큐 구조가 알맞지 않다. 시스템 환경 변수RT_GRQ=ON를 반출하면, 쓰레드가 글로벌 실행 큐에 배치되어 실행 가능 상태가 될 수도 있다. 이는 인터럽트 중심SCHED_OTHER인 쓰레드의 성능을 높일 수 있다. schedo –o fixed_pri_global =1이 AIX 5L™ Version 5.2 및 이후 버전에서 실행되면, 고정된 우선 순위로 실행되는 쓰레드는 글로벌 실행 큐에 배치된다.

로컬 실행 큐의 경우, 디스패처(dispatcher)는 CPU를 사용할 수 있을 때 실행 큐에서 우선 순위가 가장 높은 쓰레드를선택한다. 쓰레드가 CPU에서 실행되고 있을 때, CPU의 실행 큐에 머무르는 경향이 있다. 그 CPU가 바쁜(busy)상태이면, 쓰레드는 또 다른 유휴 CPU로 보내지고, 그 CPU의 실행 큐로 할당된다.

FIFO

FIFO 정책은 가장 단순하지만, 비 선점(non-preemptive) 속성 때문에 거의 사용되지 않는다. 스케줄링 정책을 갖고 있는 쓰레드는, 다음과 같은 상황이 발생하지 않는다면, 항상 실행된다:

  • sleep() 또는 select()등, 쓰레드를 수면 상태로 두는 함수를 실행하여 CPU를 자발적으로 포기한다.
  • 리소스 경쟁으로 인해 차단된다.
  • I/O 완료까지 기다려야 한다.

식품점의 체크아웃 레인(lane)은 전형적인 FIFO 정책을 사용한다. 당신이 (배고플 때) 하나의 음식을 싣고 와서 체크아웃레인에 서 있는데, 앞에 있는 사람이 카트에 한 가득 짐을 실었다고 생각해 보라. 여러분은 어떻게 하겠는가? 선택권이 없다.이것은 FIFO이기 때문에 자신의 차례를 묵묵히 기다려야 한다.

마찬가지로, 여러 태스크들이 AIX에서 FIFO 모드로 실행된다면 작업 응답 시간 때문에 심각한 문제가 발생될 것이다. 따라서, FIFO는 AIX에서는 사용되지 않는다. 루트가 소유한 단 하나의 프로세스 또는 thread_setsched() 시스템 호출로 또 다른 쓰레드가 설정될 수 있다.

FIFO 정책에는 두 개의 변이가 있다. FIFO2와 FIFO3이다. FIFO2는, 사전 정의된 틱(affinity_lim ticks. schedo -p 명령어로 튜닝함) 보다 짧은 시간 동안 슬립(sleep) 상태에 있을 경우에, 하나의 쓰레드가 실행 큐의 앞에 놓인다고 정의하고 있다. FIFO3의 경우, 쓰레드는 실행할 수 있는 상태가 되면 언제나 큐의 앞에 놓인다.

Round robin

잘알려진 Round Robin 스케줄링 정책은 UNIX® 보다도 오래되었다. AIX 5L은 256 레벨의 멀티 레벨 우선 순위큐에 Round Robin을 구현한다. 주어진 우선 순위 레벨에서, Round Robin 쓰레드는 CPU 타임슬라이스를 같은우선 순위의 다른 엔트리들과 공유한다. 쓰레드는 다음 사항들 중 하나가 발생하기 전까지 실행되도록 스케줄링 된다.

  • CPU를 다른 태스크에 양도한다.
  • I/O가 차단된다.
  • 타임슬라이스를 다 써버린다.

타임슬라이스를 다 써버릴 때, 동등한 또는 더 나은 우선순위의 쓰레드가 그 CPU에서 실행될 수 있다면, 현재 실행되는 쓰레드는큐의 끝에 배치되어 다음 순서가 프로세서를 소유하도록 한다. 쓰레드는 더 높은 우선 순위 또는 디바이스 인터럽트(I/O가 끝난후)로 인해 선점될 수 있다.

Round Robin 태스크 전용일 경우, 선점된 쓰레드는 큐 레벨의시작에 배치된다. AIX는 Round Robin 체인의 끝으로 이동되기 전에, Round Robin 작업이 완전한 타임슬라이스를갖고 있는지를 확인해야 하기 때문이다. Round Robin 쓰레드의 우선순위는 고정되고, 시간이 흐른다고 변하지 않는다.따라서, Round Robin 태스크는 영속적이고(fair Round Robin의 가변 우선 순위와는 반대 개념이다.) 보다예견 가능하다.

Round Robin이 특별한 상태이기 때문에, 루트만이 쓰레드가 Round Robin 스케줄링 정책으로 실행되도록 설정할 수 있다. 쓰레드에 SCHED_RR을 설정하려면, 애플리케이션 프로그래밍 인터페이스(API), thread_setsched() 또는 setpri() 중 하나를 사용한다.

SCHED_OTHER

마지막 스케줄링 정책 역시 디폴트이다. 태스크들에 가장 공정한 정책을 적용하는, 혁신적인 SCHED_OTHER 알고리즘은 그렇게 혁신적이지 않은 POSIX™- 이름으로 만들어진다. AIX SCHED_OTHER의핵심은 우선 순위-큐 Round Robin 디자인이지만, 한 가지 중요한 차이가 있다. 우선 순위가 고정되어 있지 않다.태스크가 과도한 CPU 시간을 사용한다면, 우선 순위 레벨은 강등되어 다른 작업들이 CPU에 액세스 할 수 있도록 한다.

한 태스크에 실행할 기회를 갖지 못하는 너무 낮은(높은 숫자) 우선 순위가 매겨지면, 우선 순위가 더 높은 레벨(낮은 숫자)로 업그레이드 되어 실행을 끝마쳐야 한다. nice 값의 효과를 향상시키기 위해 새로운 개념도 추가되었다: 태스크가 처음에 nice (유닉스 nice 값)이면, 시스템은 언제나 이것을 nice 로 유지한다. 나중에 이 부분을 설명하겠다.

전통적인 CPU 활용

AIX 5L Version 5.3 이전 또는 SMT가 실행 불가 상태에서, AIX 프로세서 활용은 샘플-기반 방식을 사용한다:

  • 사용자 프로그램을 실행하는데 걸린 프로세서 시간의 백분율
  • 시스템 코드
  • 디스크 I/O 대기
  • 유휴 시간
AIX는 샘플을 취하는데 초당 100개의 인터럽트를 만든다. 각 인터럽트에서, 로컬 타이머 틱(10ms)는 타이머 인터럽트에 의해선점된 현재 실행 쓰레드에 부과된다. 다음 활용 카테고리들 중 하나가 인터럽트 된 쓰레드의 상태에 기반하여 선택된다:
  • 쓰레드가 시스템 호출을 사용하여 커널에 있는 코드를 실행했다면, 전체 틱은 프로세스 시스템 시간에 부과된다.
  • 쓰레드가 애플리케이션 코드를 실행했다면, 전체 틱은 프로세스 사용자 시간에 부과된다. 현재 실행 쓰레드가 운영 체계의 유휴프로세스였다면, 틱은 개별 변수에서 변한다. 이 방법의 문제점은, 틱을 받는 프로세스가 전체 타이머 기간 동안에는 실행되지 않고타이머가 종료될 때 실행된다는 점이다. AIX 5.3 SMT가 실행된 상태에서, 전통적인 활용 메트릭은 두 개의 논리적프로세서들 때문에 잘못 다루어진다.
  • 한 개의 쓰레드가 100퍼센트 busy 상태라면, 한 개의유휴 쓰레드는 50 퍼센트 활용 상태가 된다. 실제로, SMT 쓰레드가 모든 CPU 리소스를 사용한다면, CPU는 새로운Processor Utilization Resource Register- (PURR) 기반 메소드를 사용하여 리포트 된 대로,100 퍼센트 busy 상태가 된다.

PURR

AIX5.3 시작 시, 각 쓰레드의 디스패치 사이클의 수는 PURR라는 새로운 레지스터를 사용하여 측정된다. 각각의 물리적 프로세서는두 개의 PURR 레지스터를 갖고 있다. (각각의 하드웨어 쓰레드에 하나씩). PURR는 POWER5 프로세서에서 제공하는새로운 레지스터로서, 논리적 프로세서가 사용했던 물리적 프로세싱 시간 단위의 실제 카운트를 제공한다. 모든 성능 툴과 API는이 PURR 값을 사용하여 SMT 시스템의 CPU 활용 메트릭을 보고한다. 이 레지스터는 POWER™ Hypervisor™가읽고 작성할 수 있는 특별한 용도의 레지스터이다; 하지만, 운영 체계에서는 읽기 전용이다. PURR에 대한 하드웨어 증가는 각쓰레드가 프로세서의 리소스를 사용하는 방법에 기반한다. 각 쓰레드에 할당된 디스패치 사이클도 포함된다. 어떤 명령어도 디스패치되지 않은 사이클의 경우, 명령어를 마지막으로 보낸 쓰레드의 PURR가 증가된다. 레지스터는 자동으로 향상되어, 운영 체계가언제나 최신 값을 얻을 수 있도록 한다.

프로세서가 싱글-쓰레드 모드에 있을 때, PURR는 여덟 개의프로세서 클락 사이클씩 증가한다. 프로세서가 SMT 모드에 있으면, 한 사이클의 명령어 그룹을 내보내는 쓰레드는 그 사이클에서1/8씩 카운터를 늘린다. 어떤 그룹 디스패치도 주어진 사이클에서 발생하지 않는다면, 쓰레드는 1/16씩 PURR를 늘린다. 그시간이 지나면, 두 개의 PURR 레니스터의 합은, SMT 모드에서 실행될 때, 거의 같아지지만, 타임베이스 틱의 수 보다는크지 않다.

AIX 5.3 CPU 활용

AIX5L Version 5.3에서, 샘플 기반 방식이 아닌 상태 기반의 커널에 의해 모아진 새로운 메트릭이 있다. 상태기반(State-based)은 10ms라는 설정 시간 보다는 PURR 증가에 기반한 정보의 컬렉션이다. AIX 5.3은 프로세스어카운팅에 PURR를 사용한다. 인터럽트 된 전체 10 ms 클락 틱을 부과하는 대신, 마지막 인터벌 이후 하드웨어 쓰레드용PURR 델타에 프로세스가 부과된다. 각 인터럽트 시:

  • 경과된 PURR는 현재 샘플 기간 동안 계산된다.
  • 이 값은, 이전에 추가된 고정된 크기로 증가(10 ms)하는 대신, 적절한 활용 카테고리 (user, sys, iowait, idle)에 추가된다.
두 개의 측정 방법이 있다. 쓰레드의 프로세서 시간과 경과된 시간이다. 경과된 시간을 측정하려면, 타임 기반 레지스터(TB)가 사용된다. 논리적 프로세서에 대한 물리적 리소스 활용 식은:
  • (delta PURR/delta TB): 논리적 프로세서에 의해 소비된 물리적 프로세서의 비율을 나타낸다.
  • (delta PURR/delta TB) * 100: 논리적 프로세서에 주어진 디스패치 사이클의 백분율을 나타낸다.

CPU 활용 예제

SMT를 실행하고 있는, 하나의 물리적 프로세서에서 두 개의 쓰레드가 실행된다고 가정해 보자. 한 개의 물리적 CPU에 있는 두 개의SMT 쓰레드는 모두 busy 상태이다. 오래된 틱 기반 방식을 사용하여, 두 개의 SMT 쓰레드는 100 퍼센트 busy로리포트 되지만, 현실적으로는, CPU 리소스를 공평하게 공유하고 있다. 새로운 PURR 기반 메소드가 각 SMT 쓰레드를 50퍼센트 busy로 보여준다.

PURR 메소드를 사용하면, 각각의 논리적 프로세서는 사용되는 물리적 프로세서 리소스의 비율을 50 퍼센트로 나타내면서, 물리적 프로세서 리소스가 두 개의 하드웨어 쓰레드에 공평하게 배분되고 있음을 알려준다.

기타 CPU 활용 식

다음 식은 쓰레드의 프로세서 시간을 측정하는 쓰레드당 PURR 메소드를 사용하고, TB 레지스터를 사용하여 경과된 시간을 측정한다.


표 1. 쓰레드당 PURR 메소드
기타 CPU 활용 식 제공된 정보
%sys=(deltaPURR in system mode/entitled PURR) * 100 where entitled PURR – (ENT *delta TB), and ENT is entitlement in # of processors (entitlement/100) 물리적 CPU 활용 메트릭은 PURR 기반 샘플과 할당을 사용하여 계산된다.
sum (delta PURR/delta TB) for each logical processor in a partition 인터벌 후에 소비된 물리적 프로세서
(PPC/ENT) * 100 소비된 할당의 백분율
(delta PIC/delta TB) where PIC is the Pool Idle count, which represents the clock ticks where POWER Hypervisor was idle 프로세서의 가용 풀을 제공한다.
Sum of traditional 10ms tic-based %sys and %user 논리적 프로세서 활용도는 더 많은 가상 프로세서들이 파티션에 추가되어야 하는지를 결정하는데 도움이 된다.



위로


AIX 5.3 명령어 변화

AIX에 SMT가 실행될 때, vmstat, iostat, topas, sar 같은 CPU 정보를 디스플레이 하는 명령어는 전통적인 샘플 기반 통계 보다는, PURR 기반 통계를 디스플레이 한다. SMT 모드에서, 추가 정보 칼럼들이 디스플레이 된다. (표 2)


표 2. SMT 모드
칼럼 설명
pc 또는 physc 파티션 별 Physical Processor Consumed
pec 또는 %entc 파티션 별 Entitlement Consumed 백분율

수정이 필요한 또 다른 툴은 trace/trcrpt와, 트레이스 유틸리티에 기반한 기타 여러 툴들이다. SMT 환경에서,trace는 각 트레이스 hook에서 PURR 레지스터 값을 모으고, trcrpt는 경과된 PURR를 디스플레이 한다.

표 3은 SMT의 인자를 보여준다.


표 3. SMT용 인자
인자 설명
trace - r PURR PURR 레지스터 값을 모은다. 트레이스에 유효한 것만 64-bit 커널에서 실행된다.
trcrpt -O PURR=[on|off] PURR와 함께 타임스탬프를 보여 줄 것을 trcrpt에 명령한다.
netpmon -r PURR 퍼센트로 된 타임베이스와 CPU 계산 대신 PURR 시간을 사용한다. 경과된 시간 계산은 적용되지 않는다.
pprof -r PURR 퍼센트로 된 타임베이스와 CPU 계산 대신 PURR 시간을 사용한다. 경과된 시간 계산은 적용되지 않는다.
gprof GPROF는 SMT를 지원하는 새로운 환경 변수이다.
curt -r PURR CPU 시간을 계산 할 PURR 레지스터를 지정한다.
splat -p CPU 시간을 계산 할 PURR 레지스터를 지정한다.



위로


쓰레드 우선 순위 식

아래 Listing 2의 식을 사용하여 쓰레드의 우선 순위를 계산한다. 이것은 nice 값의 함수, CPU 사용도를 나타내는 c, 튜닝 요소 r이다.




위로


AIX가 새로운 우선 순위를 계산하는 방법

클락 타이머 인터럽트는 각 CPU에서 10ms 또는 1 틱씩 발생한다. CPU의 클락 타이머가 또 다른 CPU의 클락 타이머와동시에 실행되지 않도록 타이머의 시차를 둔다. CPU 클락 타이머 인터럽트가 발생하면(쓰레드가 전체 10ms에 대해 실행되기전에), 이 쓰레드는 하나씩 증가하여 최대 120까지 증가한 CPU 사용 값(CPU 양)을 갖게 된다. 작업이 전체 10ms슬라이스를 얻지 못하고 RR 정책을 실행하면, 시스템 디스패처는 실행 큐에서 쓰레드 우선 순위를 변경하여 이것이 곧 다시실행되도록 한다.

대부분의 사용자 프로세스들의 우선 순위가 프로세스가 최근에 사용했던 CPU 시간에 따라 변한다. CPU 스케줄러의 우선순위 계산은 schedo, sched_R, sched_D로 설정된 두 개의 매개변수에 기반한다. sched_Rsched_D 값은 1/32 초이다. 이 스케줄러는 다음 식을 사용하여 최근 CPU 사용에 대한 패널티로서 프로세스의 우선 순위 값에 추가할 양을 계산한다.

CPU penalty = (recently used CPU value of the process) * (r/32)

각 프로세스의 최근에 사용된 CPU 값의 재 계산(초 당)은:

New recently used CPU value = (old recently used CPU value of the process) * (d/32)

r (sched_R 매개변수)와 d (sched_D 매개변수)는 디폴트 값 16을 갖고 있다.

최근의 CPU 양인 C는 우선 순위 패널티를 결정하고, 새로운 쓰레드 우선 순위를 재계산 하는데 사용된다. 레퍼런스로서 첫 번째 식을 사용하면서(Listing 2), 새롭게 시작된 사용자 태스크-기본 우선 순위 40, 디폴트 nice 값 20, 아직까지 CPU를 부과하지 않은 것(C=0)을 실행함-는 우선 순위 레벨 60으로 시작한다.

또한, 첫 번째 식에서, r 값은 0에서 32까지, 패널티 비율을 결정한다. r 값이 0이라면, CPU에 어떤 패널티도 없는 것이다. 이것은 언제나 제로(C*r/32)이기 때문이다. r=32일 경우, CPU에 가장 높은 패널티를 부과한다. CPU 사용의 각 틱(10ms) 마다 우선 순위 한 레벨씩 강등된다.

대부분의 경우, r 값은 0과 32 사이 중간에 가깝다. AIX에서 r은 16이다. CPU의 두 틱이 우선 순위 패널티의 한 레벨이 된다는 의미이다. r 값이 높으면, nice 값의 결과는 덜 중요해진다. CPU 사용 패널티가 우세하기 때문이다. 더 작은 rnice 값에 분명한 영향을 미친다.

이 논의에 기반하여, nice 값의 효과는 잠시 후에 줄어든다. CPU 부하가 증가하고, 새로운 우선 순위를 결정하는 주요 요소가 되기 때문이다.

이 식은 AIX 5L에서 수정되어 우선 순위 레벨을 계산할 때 nice 값의 중요도를 높였다. 다른 버전의 AIX에, 두 개의 새로운 요소들이 도입되었다. x_nicex_nice_factor ("extra nice"와 "extra nice factor")이다. 아래 Listing 2의 두 번째 식을 보자.


Listing 2. 쓰레드 우선 순위 식
<Formula 1 : The Basic Formula>
Priority = p_nice + (C * r/32) (1)

<Formula 2 : for AIX 5L>
Priority = x_nice + (C * r/32 * x_nice_factor) (2)
Where:
p_nice = base_PRIORITY + NICE
base_PRIORITY = 40
NICE = 20 + delta_NICE
(20 is the default nice value)
That is,
P_nice = 60 + delta_NICE

C is the CPU usage charge
The maximum value of C is 120
If NICE <= 20 then x_nice = p_nice
If NICE > 20 then
x_nice = p_nice * 2 - 60 or
x_nice = p_nice + delta_NICE, or (3)
x_nice = 60 + (2 * delta_NICE) (3a)
x_nice_factor = (x_nice + 4)/64 (4)
Priority has a maximum value of 255

Formula 2와 Formula 3에서 보듯, x_nice는 증가한 nice 값을 두 배로 만들었다. x_nice_factorr 비율을 강화했다. 예를 들어, 36이라는 nice 값을 제공하는 nice 16은 새로운 1.5라는 x_nice_factor가 되었다. 이 값은 쓰레드의 수명을 넘는 CPU 사용 부분에 대해 더 50퍼센트보다 더 높은 CPU 패널티이다.

CPU 사용 줄이기

쓰레드가 실행될 기회를 갖지 못할 만큼 낮게 우선 순위를 주는 것도 가능하다. 쓰레드 우선 순위 레벨을 끌어올리는 메커니즘 없이 Formula 2와 Formula 3만 사용한다면 가능하다.

SCHED_OTHER로쓰레드가 실행되면, 우선 순위는 CPU 사용 시간만큼 강등된다. 이것이 실행되지 않고 사용 순서를 기다리면. AIX는 1초에한번씩, CPU 부하를 줄여서 우선 순위를 다시 얻는다. 규칙은 단순하다. CPU 관련 작업들은 더 낮은 우선순위로 할당되어다른 작업이 실행되도록 하지만, 그 자체를 종료할 수 없을 지경으로 내려가서는 안된다. 모든 쓰레드의 CPU 양은 초 당 한번씩사전 정의된 요소에 기반하여 줄어든다.

New Charge C = (Old Charge C) * d / 32              (5)

커널 프로세스 Swapper가 이 작업을 수행한다. 매 초 마다, 스와퍼가 깨어나고 모든 쓰레드에 대해 감소하는 CPU 양을 처리한다. 디폴트 감소는 0.5 또는 d=16이다. 이는 CPU 양의 반을 “줄인다.”

이방식을 사용하여, CPU 중심 작업은 CPU 양을 축적하고, 더 낮은 우선 순위 레벨이 되어, 끝에 가서는 너 높은 레벨이된다. 반면, I/O 중심 작업은 우선순위 레벨의 동요가 적다. 적은 CPU 시간만 축적하기 때문이다.




위로


CPU를 소진했다면?

CPU스케줄러가 워크로드의 우선 순위를 정하는 방법을 이해했다면, 일반적으로 사용되는 명령어에 대해 알아보자. AIX에서 워크로드를끝낼 수 없을 정도로 너무 긴 시간이 걸리거나, 빠르게 반응하지 않는다면, 다음 명령어를 사용하여 시스템이 CPU에 묶여있는지의 여부를 조사해보라: vmstat, iostat, sar.

이 명령어들을 사용하는 방법 모두를 설명하지는 못하지만, 참고할 만한 자료를 제시하겠다. http://www-1.ibm.com/servers/eserver/pseries/library/ 사이트를 방문하라. AIX Version 5L Version 5.3 documentation library를 클릭하면 AIX 5 관련 문서들을 찾을 수 있다.

쓰레드의 우선 순위 변경

Listing 3은 CPU 양이 쓰레드의 우선 순위를 변경하는 방법을 보여주고 있다:


Listing 3. CPU 양과 쓰레드 우선 순위의 변화
Base priority is 40
Default NICE value is 20, assume task was run using the
default nice value
p_nice = base_priority + NICE = 40 + 20 = 60
Assume r = 2 to slow down the penalty increase (default
r value is 16)
Priority = p_nice + C*r/32 = 60 + C * r / 32
Tick 0 P = 60 + 0 * 2 / 32 = 60
Tick 1 P = 60 + 1 * 2 / 32 = 60
Tick 2 P = 60 + 2 * 2 / 32 = 60
….
Tick 15 P = 60 + 15 * 2 / 32 = 60
Tick 16 P = 60 + 16 * 2 / 32 = 61
Tick 17 P = 60 + 17 * 2 / 32 = 61
….
….
Tick 100 P = 60 + 100 * 2 / 32 = 66
Tick 100 Swapper decays all CPU usage charges for all threads.
New C CPU Charge = (Current CPU Charge) * d / 32
Assume d = 16 (the default)
For the test thread, new C = 100 * 16 / 32 = 50

Tick 101 P = 60 + 51 * 2 / 32 = 63

Listing 4는 빠른 또는 느린 우선 순위를 설정하는 방법이다.


Listing 4. 전형적인 CPU 작업의 우선순위 변화 (fast 대 slow)
fast.c:
main(){for (;;)}

slow.c:
main() {sleep 80;}




위로


일반 명령어

vmstat, iostat, sar 명령어들은 CPU 모니터링에 자주 사용된다. 각 명령어들이 만들어내는 리포트의 의미와 용법을 익혀야 한다.

vmstat

vmstat 명령어는 리포트 포맷당 한 줄씩, CPU, 디스크, 메모리 액티비티 등을 통해 CPU 사용에 대한 개요를 제공한다. Listing 5의 샘플 아웃풋은 AIX 5L Version 5.3 시스템 상에서 "vmstat 1 6"을 실행하여 만들어진 것이다. 이 리포트는 매 초 마다 만들어진다. 인터벌 다음에 6이라는 카운트가 지정되기 때문에 6 번째 리포트 다음에 리포팅이 중지된다. vmstat 명령어를 실행하는 한 가지 방법은 카운트 매개변수를 방치하는 것이다. vmstat은 명령어가 종료될 때까지 지속적으로 리포트를 생성한다.

avmfre 칼럼을 제외하고, 첫 번째 리포트에는 시스템 시작 후 초당 평균 통계가 포함되어 있다. 뒤이은 리포트에는 이전 리포트 이후 인터벌 동안 모아진 통계가 포함된다.

AIX 5L Version 5.3 시작 시, vmstat 명령어는 소비된 물리적 프로세서(pc)와 Micro-Partitioning™과 SMT 환경에서 소비된 할당 백분율(ec)를 리포팅 한다. 이 식은 Micro-Partitioning과 SMT 환경에서만 디스플레이 된다.

AIX 5L은 유용한 새로운 옵션인 "-I"를 vmstat에 추가했다. 이것은 행 I/O가 완료되기를 대기하는 쓰레드의 수(p 칼럼)와 초 당 페이징 인/아웃 된 파일 페이지의 수(fi/fo 칼럼)을 보여주고 있다.

칼럼 다음에 나오는 상세한 정보는 CPU 활용에 대해서 보여주고 있다. Listing 5vmstat 1 6 명령어의 결과이다:


Listing 5. p520 시스템 (두 개의 CPU)에서 vmstat 16 명령어의 결과
vmstat 1 6 
System configuration: lcpu=4 mem=15808MB
kthr memory page faults cpu
----- ------- ------ -------- -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
1 1 110996 763741 0 0 0 0 0 0 231 96 91 0 0 99 0
0 0 111002 763734 0 0 0 0 0 0 332 2365 179 0 1 99 0
0 0 111002 763734 0 0 0 0 0 0 330 2283 139 0 5 93 1
0 0 111002 763734 0 0 0 0 0 0 310 2212 153 0 0 99 0
1 0 111002 763734 0 0 0 0 0 0 314 2259 173 0 0 99 0
0 0 111002 763734 0 0 0 0 0 0 321 2261 177 0 1 99 0

그림 2는 (소프트웨어 설치 실행된) vmstat -I 1 명령어의 결과이다:


그림 2. vmstat -I 1 명령어의 결과
Output of the vmstat -I 1 command

See 표 4는 관련 칼럼들의 목록이다.


표 4. 관련 칼럼 설명
칼럼 설명
kthr 커널 쓰레드 상태는 샘플링 인터벌 동안 초 마다 변한다.
r 실행 큐에 배치된 커널 쓰레드의 수
b Virtual Memory Manager (VMM) 대기 큐 (리소스 대기, I/O 대기)에 배치된 커널 쓰레드의 수
p 행 I/O(journaled file system (JFS)을 우회함)에서 완료되기를 대기하는 쓰레드의 수. AIX 5 및 이후 버전에서만 사용할 수 있다.
fi/fo 초 당 페이징 인/아웃 되는 파일 페이지의 수. 주: 칼럼은 AIX 5 및 이후 버전에서만 사용할 수 있다.
cpu 백분율로 나타난 CPU 사용량. 멀티프로세서 시스템의 경우, CPU 값은 모든 프로세스의 평균이다. 또한, I/O 대기 상태는 프로세서가 아닌 시스템 중심으로 정의된다.
us 사용자 모드에서 실행된 평균 CPU 사용 시간
sy 시스템 모드에서 실행된 평균 CPU 사용 시간
id CPU가 유휴 상태였고, 시스템이 뚜렷한 디스크 I/O 요청을 갖지 않았을 때 평균 시간
wa 시스템이 뚜렷한 disk/NFS I/O 요청을 갖고 있을 동안 CPU 유휴 시간. 대기가 진행 중일 때 디스크에 대한 적어도 한개 이상의 뚜렷한 I/O가 있었다면, 이 시간은 I/O 대기 시간으로 구분된다. 비동기 I/O가 프로세스에 의해 사용되면,디스크에 대한 I/O 요청은 요청이 완료될 때까지 호출 프로세스를 막는다. 프로세스에 대한 I/O 요청이 완료되면, 실행 큐에배치된다. I/O가 더 빨리 끝나면, 더 많은 CPU 시간이 사용될 수 있다.
pc 소비된 물리적 프로세서의 수. 파티션이 공유 프로세서로 실행될 경우에만 디스플레이 된다.
ec 소비된 할당 용량의 백분율. 파티션이 공유 프로세서로 실행될 경우에만 디스플레이 된다.

CPU가 유휴 상태이고 뚜렷한 I/O가 그 CPU에서 초기화 되었다면, CPU는 클락 인터럽트(1/100 ms 마다)에 wio로 표시된다. CPU가 뚜렷한 I/O 없이 유휴 상태이면, wa 대신 id로 표시된다. 예를 들어, 네 개의 CPU와 한 개의 쓰레드를 가진 시스템은 최대 25 퍼센트의 wio 시간이 보고된다. 12개의 CPU와 한 개의 쓰레드는 최대 8.3 퍼센트의 wio 시간을 보고한다. wio는 I/O가 완료되기를 기다리면서 CPU가 유휴인 시간을 퍼센트로 측정한다.

이 네 개의 칼럼들은 총 100 퍼센트이거나, 거의 가깝게 된다. 사용자와 시스템(ussy)의 CPU 활용 백분율의 합이 100 퍼센트에 근접하면, 시스템은 CPU 병목 현상을 겪게 된다.

iostat

iostat 명령어는 시스템 인풋과 아웃풋 장치를 감시하는데 사용되지만, CPU 사용 데이터도 제공한다. AIX 5.3부터, iostat명령어는, 소비된 물리적 프로세서의 수(physc)와 Micro-Partitioning과 SMT 환경에서 할당 백분율(%entc)을 리포팅 한다. 이러한 메트릭은 Micro-Partitioning/SMT 환경에서만 디스플레이 된다. SMT가실행되면, iostat은 자동으로 새로운 PURR-기반 데이터와 식을 사용한다:

  • %user
  • %sys
  • %wait
  • %idle

Listing 6은 "iostat 5 3"을 입력하여, AIX 5L Version 5.3 시스템에서 생성된 것이다:


Listing 6. iostat 리포트
System configuration: lcpu=4 drives=9

tty: tin tout avq-cpu: %user %sys %idle %iowait
0.0 4.3 0.2 0.6 98.8 0.4
Disks: %tm_act Kbps tps Kb_read Kb_wrtn
hdisk0 0.0 0.2 0.0 7993 4408
hdisk1 0.0 0.0 0.0 2179 1692
hdisk2 0.4 1.5 0.3 67548 59151
cd0 0.0 0.0 0.0 0 0
tty: tin tout cpu: %user %sys %idle %iowait
0.0 30.3 8.8 7.2 83.9 0.2
Disks: %tm_act Kbps tps Kb_read Kb_wrtn
hdisk0 0.2 0.8 0.2 4 0
hdisk1 0.0 0.0 0.0 0 0
hdisk2 0.0 0.0 0.0 0 0
cd0 0.0 0.0 0.0 0 0
tty: tin tout cpu: %user %sys %idle %iowait
0.0 8.4 0.2 5.8 0.0 93.8
Disks: %tm_act Kbps tps Kb_read Kb_wrtn
hdisk0 0.0 0.0 0.0 0 0
hdisk1 0.0 0.0 0.0 0 0
hdisk2 98.4 75.6 61.9 396 2488
cd0 0.0 0.0 0.0 0 0

Example iostat with SPLAR configuration
#iostat –t 2 3
System Configuration: lcpu=4 ent=0.80
avg-cpu %user %sys %idle %iowait physc %entc
0.1 0.2 99.7 0.0 0.0 0.9
0.1 0.4 99.5 0.0 0.0 1.1
0.1 0.2 99.7 0.0 0.0 0.9

vmstat 명령어 리포트와 마찬가지로, 첫 번째 리포트에는 시스템이 시작한 후 통계 평균이 포함되어 있다. 그 다음에는 이전 리포트 이후 인터벌 동안에 모아진 통계가 포함된다.

CPU 사용의 감소를 보여주는 네 개의 칼럼은 vmstat 명령어와 같은 정보를 제공한다. 이 칼럼의 총합은 약 100퍼센트가 되어야 한다. 사용자와 시스템(ussy) CPU-활용도의 합이 100퍼센트에 다다르면 시스템은 CPU 병목 현상을 겪는다.

한개의 애플리케이션을 실행하는 시스템 상에서, 높은 I/O 대기율은 워크로드와 관련이 있다. 많은 프로세스를 가진 시스템상에서,어떤 것은 실행 중인데 반해, 어떤 것은 I/O 대기 중이다. 이 경우, %iowait은 작거나 0이 된다. 실행 프로세스들이대기 시간을 숨기기 때문이다. %iowait가 낮더라도, 병목 현상은 애플리케이션 성능을 제한할 수 있다. iostat 명령어가 CPU에 묶인 상황이 존재하지 않고 %iowait 시간이 20 퍼센트보다 크다고 나타낸다면 I/O 또는 디스크 관련 상황에 있는 것이다.

sar

sar 명령어는 두 개의 폼을 지닌다. 첫 번째 시스템 통계를 샘플링, 디스플레이, 저장하고, 두 번째 폼은 이전에 캡처된 데이터를 처리 및 디스플레이 한다. sar 명령어는 vmstatiostat 명령어와 마찬가지로 큐와 프로세서 통계를 제공한다. 하지만, 두 개의 추가 기능이 있다:

  • 각 샘플에는 타임 스탬프가 앞에 있다. 따라서, 전체 평균은 샘플의 끝에 나타난다.

  • -P옵션은 모든 프로세서의 글로벌 평균 외에도, 프로세서 당 통계를 만드는데 사용된다. 아래 샘플 코드는, 두 개의 명령어를입력하여 나온, 4-way symmetric multiprocessor (SMP) 시스템의 샘플 아웃풋이다.
    • sar -o savefile 5 3 > /dev/null & 

      : 이 명령어는 5초 간격으로 데이터를 3회 모으고, 모은 데이터를 savefile에 저장하고, 그 리포트를 null로 리다이렉션 하여, 어떤 리포트도 터미널에 작성되지 않도록 한다.
    • sar -P ALL -u -f savefile 

      : -P ALL은 각 개별 프로세서와 -u CPU 사용 데이터에 대한 프로세서 당 통계를 취합하도록 지정된다. 게다가, -f savefilesarsavefile에 저장된 데이터를 사용하여 리포트를 만들도록 명령한다. SMT를 실행하는 모든 논리적 프로세서의 경우, sar -P All아웃풋은 물리적 프로세서가 소비한 physc (delta PURR/delta TB)를 보여준다. 이 칼럼은 프로세서들 간 나뉜관련 SMT를 보여준다. 논리적 프로세서가 물리적 프로세서 사이클이 되는 시간의 비율을 계산한다. 할당된 용량의 사용률이 100퍼센트 미만이면, U로 시작하는 라인이 추가되어 사용되지 않는 용량을 나타낸다. 공유 모드에서 실행될 때, sar는 소비된 할당 비율을 %entc로 표시한다. (((PPC/ENT)*100)

Listing 7. 전용 LPAR가 설정된 2-way p520 시스템에서 나온 전형적인 sar 리포트
AIX nutmeg 3 5 00CD241F4C00    06/14/05

System configuration: lcpu=4

11:51:33 cpu %usr %sys %wio %idle physc
11:51:34 0 0 0 0 100 0.30
1 1 1 1 98 0.69
2 2 1 0 96 0.69
3 0 0 0 100 0.31
- 1 1 0 98 1.99
11:51:35 0 0 0 0 100 0.31
1 0 0 0 100 0.69
2 0 0 0 100 0.73
3 0 0 0 100 0.31
- 0 0 0 100 2.04
11:51:36 0 0 0 0 100 0.31
1 0 0 0 100 0.69
2 0 0 0 100 0.70
3 0 0 0 100 0.31
- 0 0 0 100 2.01
11:51:37 0 0 0 0 100 0.31
1 0 0 0 100 0.69
2 0 0 0 100 0.69
3 0 0 0 100 0.31
- 0 0 0 100 2.00

Average 0 0 0 0 100 0.31
1 0 0 0 99 0.69
2 1 0 0 99 0.70
3 0 0 0 100 0.31
- 0 0 0 99 2.01

mpstat

mpstat 명령어는 시스템에서의 모든 논리적 CPU에 대한 퍼포먼스 통계를 모으고 디스플레이 한다. SMT가 실행될 경우, mpstat -s 명령어는 물리적 프로세서뿐만 아니라 논리적 프로세서의 사용도를 디스플레이 한다. (Listing 8)


Listing 8. SPLAR이 설정된 2-way p520 시스템에서 나온 전형적인 엠스탯 리포트
System configuration: lcpu=4

Proc0 Proc1
63.65% 63.65%

cpu2 cpu0 cpu1 cpu3
58.15% 5.50% 61.43% 2.22%

lparstat

lparstat 명령어는 LPAR 관련 정보와 활용도를 나타낸다. 이 명령어는 현재 LPAR 관련 매개변수와 하이퍼바이저 정보를 디스플레이 하고, LPAR용 활용도를 나타낸다. 인터벌 메커니즘은 특정 인터벌 시 리포트의 수를 검색한다.

다음 통계는 파티션 유형이 공유될 때에만 디스플레이 된다:

physc 물리적 프로세서의 소비량을 나타낸다.
%entc 할당된 용량의 소비율을 보여준다.
lbusy 사용자와 시스템 레벨에서 실행하는 동안 발생한 논리적 프로세서 사용률을 나타낸다.
app 공유 풀에서 가용 물리적 프로세서를 보여준다.
phint 팬텀(phantom)(풀에서 또 다른 공유 파티션을 목표로 함) 인터럽션의 수를 보여준다.

다음 통계는 ?h 플래그가 지정될 경우에만 디스플레이 된다:

%hypv 하이퍼바이저에서 보낸 시간 비율을 나타낸다.
hcalls 하이퍼바이저 호출 실행 수를 보여준다.

Listing 9. 2-way p520 머신에서 나온 전형적인 lparstat 리포트
System configuration: type=Dedicated mode=Capped smt=On lcpu=4 mem=15808

%user %sys %wait %idle
----- ---- ----- -----
0.0 0.1 0.0 99.9
0.0 0.1 0.0 99.9
0.4 0.2 0.1 99.3

# lparstat 1 3

System configuration: type=Shared mode=Uncapped smt=On lcpu=2 mem=2560 ent=0.50

%user %sys %wait %idle physc %entc lbusy app vcsw phint
----- ---- ----- ----- ----- ----- ------ --- ---- -----
0.3 0.4 0.0 99.3 0.01 1.1 0.0 - 346 0
43.2 6.9 0.0 49.9 0.29 58.4 12.7 - 389 0
0.1 0.4 0.0 99.5 0.00 0.9 0.0 - 312 0




위로


시스템 성능 높이기

CPU-중심 시스템의 경우, 특정 프로세스의 쓰레드와 프로세스 우선 순위를 조작하고, 스케줄러 알고리즘을 다양한 시스템 중심 스케줄링 정책에 맞게 조정함으로써, 시스템 성능을 높일 수 있다.

사용자-프로세스 우선 순위 변경하기

사용자 태스크 우선순위를 변경하거나 설정하는 명령어에는 nicerenice 명령어와, 쓰레드 우선순위와 스케줄링 정책이 API 호출을 통해 변경되도록 하는 두 개의 시스템 호출이 포함된다.

nice 명령어 사용하기

포그라운드(foreground) 프로세스의 표준 nice 값은 20이다;ksh 또는 csh (tcshbsh로 시작될 경우는 20이다.)에서 시작될 경우, 백그라운드 프로세스의 표준 nice 값은 24이다. 시스템은 nice 값을 사용하여 프로세스와 제휴 된 모든 쓰레드들의 우선순위를 계산한다. nice 명령어를 사용하여, 사용자는 표준 nice 값을 가감 설정하여, 프로세스가 다른 우선순위로 시작되도록 한다. 쓰레드 우선순위는 고정되지 않으며, 쓰레드의 CPU 사용도에 따라 다른 값을 갖는다.

nice를 사용하면, 사용자는 평균 보다 낮은 우선순위로 명령어를 실행할 수 있다. 루트 사용자만이 nice 명령어를 사용하여 평균 보다 높은 우선순위로 명령어를 실행할 수 있다. 예를 들어, nice -5 iostat 10 3 >iostat.out 명령어는 iostat 명령어가 nice 값 25(20이 아님)로 시작하도록 한다. 시작 우선순위가 더 낮다. nice 값과 우선순위는 ps 명령어와 -l 플래그를 사용하여 볼 수 있다. Listing 10ps -l 명령어를 사용하여 얻은 결과이다:


Listing 10. ps -l를 사용하여 프로세서 우선순위 보기
       F S UID   PID  PPID   C PRI NI ADDR    SZ    WCHAN    TTY  TIME CMD
240001 A 0 15396 5746 1 60 20 393ce 732 pts/3 0:00 ksh
200001 A 0 15810 15396 3 70 25 793fe 524 pts/3 0:00 iostat

루트라면, # nice --5 vmstat 10 3 >io.out 이라는 더 높은 우선순위로 iostat을 실행할 수 있다. iostat 명령어는 nice 값 15로 실행될 수 있다. 시작 우선순위가 더 높다.

renice 명령어 사용하기

프로세스가 이미 실행 중이면, renice 명령어를 사용하여 nice 값과 우선 순위를 변경할 수 있다. 프로세스는 프로세스 아이디, 프로세스 그룹 아이디, 또는 프로세스를 소유한 사용자의 이름으로 구분된다. renice 명령어는 고정된 우선순위 프로세스로 사용될 수 없다.

setpri()와 thread_setsched() 서브루틴 사용하기

사용자가 개별 프로세스나 쓰레드가 고정된 우선순위로 스케줄링 되도록 하는 두 개의 시스템 호출이 있다. setpri() 시스템 호출은 프로세스 지향이고, thread_setsched()는 쓰레드-지향이다. 이 두 개의 서브루틴을 호출할 때 주의해야 한다. 올바르지 않게 사용하면 시스템이 중지될 수 있다.

루트 사용자 아이디로 실행되는 애플리케이션은 setpri() 서브루틴을 호출하여 고유한 우선순위를 설정하거나 또 다른 프로세스의 우선순위를 설정할 수 있다. 목표 프로세스는 SCHED_RR 스케줄링 정책과 고정된 우선순위를 사용하여 스케줄링 된다. 변경 사항들은 프로세스의 모든 쓰레드에 적용된다. 다음 두 개의 예를 보자:

retcode = setpri(0, 45);

호출 프로세스에 고정된 우선순위 45를 준다.

retcode = setpri(1234, 35);

PID 1234 프로세스에 고정된 우선순위 35를 준다.

특정 쓰레드를 변경하려면, thread_setsched()서브루틴이 사용될 수 있다:

retcode = thread_setsched(thread_id,priority_value, scheduling_policy)

매개변수 scheduling_policy는 다음 중 하나가 될 수 있다:

SCHED_OTHER, SCHED_FIFO, or SCHED_RR.

SCHED_OTHER가 스케줄링 정책으로서 지정되면, 두 번째 매개변수(priority_value)는 무시된다.

스케줄링 알고리즘을 글로벌로 변경하기

AIX에서는 사용자가 schedo 명령어를 사용하여 우선순위 계산 식을 변경할 수 있다.

r과d 결정하기

앞서 언급했지만, 우선순위 값을 계산하는 식은 다음과 같다:

Priority = x_nice + (C * r/32 * x_nice_factor)

최근 CPU 사용 값은 ps 명령어 아웃풋에 C 칼럼에 디스플레이 된다. 최근 CPU 사용의 최대 값은 120이다. 매 초마다, 각 쓰레드에 대한 CPU 사용 값은 다음 식을 사용하여 강등된다.

New Charge C = (Old Charge C) * d / 32

r의 디폴트 값은 16이다; 따라서, 쓰레드 우선순위는 recent CPU usage * 0.5로 줄어든다. d 역시 디폴트 값은 16이다. 모든 프로세스의 최근 CPU 사용 값이 매 초 마다 원래 값의 반으로 줄었다는 의미이다. 일부 사용자의 경우, sched_Rsched_D의 디폴트 값은 포그라운드와 백그라운드 프로세스간 구별을 허용하지 않는다. 이 두 값은 schedo 명령어에 sched_Rsched_D 옵션을 사용하여 조정된다. 다음 두 예제를 보자:

  • # schedo -o sched_R=0


    (R=0, D=.5)는 CPU 패널티가 언제나 0이라는 것을 나타낸다. RR 프로세스처럼 취급되지는 않지만, 이 프로세스의 우선순위 값은 고정되었다.

  • # schedo -o sched_D=32


    (R=0.5, D=1)은 장기 실행프로세스들이 120이라는 C 값에 도달한 뒤 머물러 있음을 나타내고 있다. 최근 CPU 사용 값은 줄어들지 않았고 장기 실행프로세스의 우선순위도 새로운 프로세스와 경쟁하기 위해 낮은 숫자(높은 중요도)로 변하지 않았다.

타임슬라이스 변경하기

schedo 명령어가 스케줄러 타임슬라이스의 길이를 변경할 수 있지만 타임슬라이스 변경은 RR 쓰레드에만 적용된다. 다른 스케줄링 정책으로 실행되는 쓰레드에는 영향을 미치지 않는다. 이 명령어의 신택스는 다음과 같다.

schedo -L timeslice

n은 타임슬라이스로 사용된 10ms 클락 킥의 수이다. schedo -p -o timeslice=2는 타임슬라이스 길이를 20ms로 설정한다.

루트로서 로그인 하여 schedo 명령어를 사용하여 변경할 수 있다.




위로


기타 기술 사용하기

CPU 중심 시스템에 사용할 수 있는 여러 기술들이 있다.

스케줄링

애플리케이션의 상대적 중요성에 따라, at, cron,, batch 명령어를 사용하여 연장된 시간을 덜 중요한 시간으로 스케줄링 한다.

mkpasswd 명령어

시스템에 /etc/passwd 파일에 수 천 개의 엔트리가 있다면 mkpasswd 명령어를 사용하여 해시 또는 인덱스 버전의 /etc/passwd 파일을 만들어서 사용자 아이디를 찾는데 드는 CPU 시간을 줄일 수 있다.




위로


개별 애플리케이션 튜닝

다음 기술들을 사용하여 AIX에서 실행되는 특정 애플리케이션을 진단하고 성능을 높인다.

ps 명령어

ps명령어 또는 프로파일링은 많은 CPU 시간을 소비하는 애플리케이션을 구분한다. 이 정보는 CPU 병목 현상을 검색하는데 드는시간을 줄일 수 있다. 문제 영역을 찾은 후에, 애플리케이션을 튜닝 및 향상시킬 수 있다. 애플리케이션을 재 컴파일 하거나 소스코드를 변경한다.

schedo 명령어

schedo 명령어는 모든 CPU 스케줄러 튜닝 매개변수의 현재 또는 다음 부팅 값을 설정 또는 디스플레이 한다. 이 명령어는 루트 사용자만이 실행할 수 있다. schedo 명령어는 영구적으로 변경하거나, 다음 재부팅 때까지 변경을 연기할 수 있다. AIX 5L Version 5.3부터, 여러 튜닝 매개변수들이 schedo 명령어에 추가되었다. Listing 11은 모든 CPU 스케줄러 매개변수이다.


Listing 11. CPU 스케줄러 매개변수
# schedo -a
%usDelta = 100
affinity_lim = 7
big_tick_size = 1
fixed_pri_global = 0
force_grq = 0
hotlocks_enable = 0
idle_migration_barrier = 4
krlock_confer2self = n/a
krlock_conferb4alloc = n/a
krlock_enable = n/a
krlock_spinb4alloc = n/a
krlock_spinb4confer = n/a
maxspin = 16384
n_idle_loop_vlopri = 100
pacefork = 10
sched_D = 16
sched_R = 16
search_globalrq_mload = 256
search_smtrunq_mload = 256
setnewrq_sidle_mload = 384
shed_primrunq_mload = 64
sidle_S1runq_mload = 64
sidle_S2runq_mload = 134
sidle_S3runq_mload = 134
sidle_S4runq_mload = 4294967040
slock_spinb4confer = 1024
smt_snooze_delay = 0
smtrunq_load_diff = 2
timeslice = 1
unboost_inflih = 1
v_exempt_secs = 2
v_min_process = 2
v_repage_hi = 0
v_repage_proc = 4
v_sec_wait = 1

업그레이드

튜닝으로도 시스템 성능을 향상시킬 수 없다면, 시스템을 더 빠른 CPU 또는 더 많은 CPU로 업그레이드 해야 한다.

Posted by saudades

댓글을 달아 주세요

2009.02.03 16:56

AIX 5에서 공유 라이브러리 메모리 크기

developerWorks
문서 옵션
수평출력으로 설정

이 페이지 출력

이 페이지를 이메일로 보내기

이 페이지를 이메일로 보내기

영어원문

영어원문


제안 및 의견
피드백

난이도 : 초급

George Cross, 선임 소프트웨어 개발자, Business Objects Americas

옮긴이: 박재호 이해영 dwkorea@kr.ibm.com

2008 년 9 월 16 일

IBM® AIX®에서 공유 라이브러리 메커니즘과 메모리 크기에 대해 배워봅시다. 이 기사는 서버 코드를 작성하는 개발자와 AIX 시스템을 실제 운영하는 관리자에게 필요한 지식을 핵심만 간추려 설명합니다. 이 기사는 개발자와 관리자에게 명령어와 기법을 설명하고 AIX에서 서버 프로세스의 메모리 요구 사항을 분석하는 데 필요한 지식을 제공합니다. 이 기사는 또한 개발자와 관리자가 ps나 topas와 같은 표준 실시간 분석 도구로 파악하기 어려운 자원 부족을 회피하는 방법을 설명합니다. 이 기사는 시스템 관리자와 AIX용 응용 프로그램 개발자를 대상으로 작성했습니다.

소개

이 기사는 다음 명령어를 시연하면서 32비트 AIX 5L™(5.3)에서 공유 라이브러리가 메모리를 차지하는 방법을 살펴본다.

  • ps
  • svmon
  • slibclean
  • procldd
  • procmap
  • genkld
  • genld

이 기사는 커널 공유 라이브러리 세그먼트는 물론이고 프로세스의 가상 메모리 공간을 설명하며, 가상 메모리를 살펴보는 방법, 위에서 언급한 다양한 진단 도구가 제공하는 출력 결과 해석 방법도 다룬다. 이 기사는 또한 커널 공유 세그먼트가 꽉 찬 상황을 진단하며 이런 상황을 해결하기 위해 가능한 접근 방법도 설명한다.

이 기사에서 사용하는 예제로 소프트웨어 제품인 Business Objects Enterprise Xir2®에서 따온 프로세스를 사용한다. 이는 임의로 든 예며, 여기서 소개하는 개념은 AIX 5L에서 동작하는 모든 프로세스에 적용할 수 있다.




위로


검토

이제 무엇을 할지 공감했으니, 32비트 아키텍처를 조금 검토해보자. 검토 과정에서 아주 유용한 'bc' 명령행 계산기를 사용하겠다.

32비트 프로세서에서 레지스터는 2^32개의 가능한 값을 담을 수 있다.

	$ bc
	2^32
	4294967296
	obase=16
	2^32
	100000000


이 범위는 4기가바이트다. 이는 시스템에서 동작하는 프로그램이 0에서 2^32 - 1 범위 내에서 함수나 자료 주소에 접근할 수 있음을 의미한다.

	$ bc
 	2^32 - 1 
	FFFFFFFF
	obase=10
	2^32 - 1 
	4294967295


이미 알고 있듯이, 운영체제는 잠재적으로 수백 개에 이르는 프로그램을 동시에 돌릴 수 있다. 응용 프로그램 각각이 4GB 메모리 범위에 접근이 가능할지라도, 개별 프로그램마다 물리 RAM을 4GB만큼 할당 받는다는 뜻은 아니다. 이렇게 하기란 비현실적이다. 그 대신 운영체제는 적당한 물리 RAM과 스왑(또는 페이징) 영역으로 지정된 파일 시스템 사이에서 코드와 자료를 스와핑하는 복잡한 정책을 구현했다. 또한 각 프로세서가 4GB라는 메모리 영역에 접근이 가능할지라도, 대다수 프로세서는 이 영역을 완전히 사용하지 않는다. 따라서 운영체제는 특정 프로세스마다 요구하는 코드와 자료를 올리고 스왑하기만 하면 된다.


그림 1. 가상 메모리를 개념으로 설명하는 도식
가상 메모리 관리

이런 방법은 종종 가상 메모리나 가상 주소 공간으로 부른다.

실행 파일이 동작할 때, 운영체제에 들어있는 가상 메모리 관리자는 파일을 구성하는 코드와 자료를 살펴서 어느 부분을 램으로 올리고 어느 부분을 스왑으로 올리고 어느 부분을 파일 시스템에서 참조할지 결정한다. 동시에, 운영체제는 몇몇 구조체를 만들어 4GB 범위 내에서 물리 영역을 가상 영역으로 사상한다. 이 4GB 범위는 (종종 VMM 구조와 함께) 프로세스의 이론적인 최대 범위를 표현하며, 프로세스의 가상 주소 공간으로 알려져 있다.

AIX에서 4GB 가상 공간은 256메가바이트짜리 세그먼트 16개로 나뉜다. 세그먼트에는 미리 정해진 기능이 있다. 몇 가지를 정리해보았다.

  • 세그먼트 0: 커널 관련 자료
  • 세그먼트 1: 코드
  • 세그먼트 2: 스택과 동적 메모리 할당
  • 세그먼트 3: 사상된 파일을 위한 메모리, mmap으로 설정한 메모리
  • 세그먼트 d: 공유 라이브러리 코드
  • 세그먼트 f: 공유 라이브러리 자료

반면에 HP-UX®에서 주소 공간은 4분면으로 나뉜다. 3사분면과 4사분면은 +q3p enable과 +q4p enable 옵션을 켜서 chatr 명령을 내릴 경우 공유 라이브러리 사상 목적으로 사용이 가능하다.




위로


공유 라이브러리가 메모리에 올라오는 위치

당연한 이야기지만, 공유 라이브러리는 공유할 목적으로 만들어졌다. 좀 더 구체적으로 말하자면, 코드("텍스트"로 알려진)와 읽기 전용 자료(상수 자료, 기록 시점에서 복사 가능한 자료)를 포함한 이진 파일 이미지에서 읽기 전용 영역을 물리적인 메모리에 올리고 나면 이를 요구하는 프로세스에 여러 번 사상할 수 있다.

이를 확인하기 위해, AIX가 동작하는 기계를 구해 현재 메모리에 올라온 공유 라이브러리를 살펴보자.

> su 
# genkld
Text address     Size File

    d1539fe0    1a011 /usr/lib/libcurses.a[shr.o]
    d122f100    36732 /usr/lib/libptools.a[shr.o]
    d1266080    297de /usr/lib/libtrace.a[shr.o]
    d020c000     5f43 /usr/lib/nls/loc/iconv/ISO8859-1_UCS-2
    d7545000    161ff /usr/java14/jre/bin/libnet.a
    d7531000    135e2 /usr/java14/jre/bin/libzip.a
.... [ lots more libs ] ....
d1297108 3a99 /opt/rational/clearcase/shlib/libatriastats_svr.a
[atriastats_svr-shr.o]
    d1bfa100    2bcdf /opt/rational/clearcase/shlib/libatriacm.a[atriacm-shr.o]
    d1bbf100    2cf3c /opt/rational/clearcase/shlib/libatriaadm.a[atriaadm-shr.o]
.... [ lots more libs ] ....
    d01ca0f8     17b6 /usr/lib/libpthreads_compat.a[shr.o]
    d10ff000    30b78 /usr/lib/libpthreads.a[shr.o]
    d00f0100    1fd2f /usr/lib/libC.a[shr.o]
    d01293e0    25570 /usr/lib/libC.a[shrcore.o]
    d01108a0    18448 /usr/lib/libC.a[ansicore_32.o]
.... [ lots more libs ] ....
    d04a2100    fdb4b /usr/lib/libX11.a[shr4.o]
    d0049000    365c4 /usr/lib/libpthreads.a[shr_xpg5.o]
    d0045000     3c52 /usr/lib/libpthreads.a[shr_comm.o]
    d05bb100     5058 /usr/lib/libIM.a[shr.o]
    d05a7100    139c1 /usr/lib/libiconv.a[shr4.o]
    d0094100    114a2 /usr/lib/libcfg.a[shr.o]
    d0081100    125ea /usr/lib/libodm.a[shr.o]
    d00800f8      846 /usr/lib/libcrypt.a[shr.o]
    d022d660   25152d /usr/lib/libc.a[shr.o]

관찰 결과에 따르면, 현재 Clearcase와 자바(Java™)가 동작하고 있다. 여기서 libpthreads.a라는 공통 라이브러리 중 하나를 찍어보자. 라이브러리를 탐색해서 구현 함수 내역을 살핀다.

# dump -Tv /usr/lib/libpthreads.a | grep EXP
[278]   0x00002808    .data      EXP     RW SECdef        [noIMid] pthread_attr_default
[279] 0x00002a68 .data EXP RW SECdef [noIMid]
 pthread_mutexattr_default
[280]   0x00002fcc    .data      EXP     DS SECdef        [noIMid] pthread_create
[281]   0x0000308c    .data      EXP     DS SECdef        [noIMid] pthread_cond_init
[282]   0x000030a4    .data      EXP     DS SECdef        [noIMid] pthread_cond_destroy
[283]   0x000030b0    .data      EXP     DS SECdef        [noIMid] pthread_cond_wait
[284]   0x000030bc    .data      EXP     DS SECdef        [noIMid] pthread_cond_broadcast
[285]   0x000030c8    .data      EXP     DS SECdef        [noIMid] pthread_cond_signal
[286]   0x000030d4    .data      EXP     DS SECdef        [noIMid] pthread_setcancelstate
[287]   0x000030e0    .data      EXP     DS SECdef        [noIMid] pthread_join
.... [ lots more stuff ] ....

음, 흥미롭다. 이제 시스템에서 현재 메모리에 올라와 있는 동작 중인 프로세스를 살펴보자.

# for i in $(ps -o pid -e | grep ^[0-9] ) ; do j=$(procldd $i | grep libpthreads.a); \
	if [ -n "$j" ] ; then ps -p $i -o comm | grep -v COMMAND; fi  ; done
portmap
rpc.statd
automountd
rpc.mountd
rpc.ttdbserver
dtexec
dtlogin
radiusd
radiusd
radiusd
dtexec
dtterm
procldd : no such process : 24622
dtterm
xmwlm
dtwm
dtterm
dtgreet
dtexec
ttsession
dtterm
dtexec
rdesktop
procldd : no such process : 34176
java
dtsession
dtterm
dtexec
dtexec

멋지다! 이제 똑같은 작업을 하되, 중복을 없애보자.

# cat prev.command.out.txt | sort | uniq 
       
automountd
dtexec
dtgreet
dtlogin
dtsession
dtterm
dtwm
java
portmap
radiusd
rdesktop
rpc.mountd
rpc.statd
rpc.ttdbserver
ttsession
xmwlm

현재 동작 중이면서 libpthreads.a를 메모리에 올린 이진 파일 목록을 깔끔하게 분리해서 정리해보자. 이 시점에서 시스템에 더 많은 프로세스가 떠 있음에 주의하자.

# ps -e | wc -l 	
      85

이제 각 프로세스가 libpthreads.a를 어디에 올렸는지 살펴보자.

# ps -e | grep java
 34648      -  4:13 java
#
# procmap 34648 | grep libpthreads.a
d0049000         217K  read/exec      /usr/lib/libpthreads.a[shr_xpg5.o]
f03e6000          16K  read/write     /usr/lib/libpthreads.a[shr_xpg5.o]
d0045000          15K  read/exec      /usr/lib/libpthreads.a[shr_comm.o]
f03a3000         265K  read/write     /usr/lib/libpthreads.a[shr_comm.o]
#
# ps -e | grep automountd
 15222      -  1:00 automountd
 25844      -  0:00 automountd
#
# procmap 15222 | grep libpthreads.a
d0049000         217K  read/exec      /usr/lib/libpthreads.a[shr_xpg5.o]
f03e6000          16K  read/write     /usr/lib/libpthreads.a[shr_xpg5.o]
d0045000          15K  read/exec      /usr/lib/libpthreads.a[shr_comm.o]
f03a3000         265K  read/write     /usr/lib/libpthreads.a[shr_comm.o]
d10ff000         194K  read/exec         /usr/lib/libpthreads.a[shr.o]
f0154000          20K  read/write        /usr/lib/libpthreads.a[shr.o]
#
# ps -e | grep portmap              
 12696      -  0:06 portmap
 34446      -  0:00 portmap
#
# procmap 12696 | grep libpthreads.a
d0045000          15K  read/exec      /usr/lib/libpthreads.a[shr_comm.o]
f03a3000         265K  read/write     /usr/lib/libpthreads.a[shr_comm.o]
d10ff000         194K  read/exec         /usr/lib/libpthreads.a[shr.o]
f0154000          20K  read/write        /usr/lib/libpthreads.a[shr.o]
#
# ps -e | grep dtlogin
  6208      -  0:00 dtlogin
  6478      -  2:07 dtlogin
 20428      -  0:00 dtlogin
#
# procmap 20428 | grep libpthreads.a
d0045000          15K  read/exec      /usr/lib/libpthreads.a[shr_comm.o]
f03a3000         265K  read/write     /usr/lib/libpthreads.a[shr_comm.o]
d0049000         217K  read/exec      /usr/lib/libpthreads.a[shr_xpg5.o]
f03e6000          16K  read/write     /usr/lib/libpthreads.a[shr_xpg5.o]

각 프로세스는 libpthreads.a를 매번 동일 주소에 올린다는 사실에 주목하자. 라이브러리를 구성하는 목록에 현혹되지 말자. AIX에서는 동적 공유 라이브러리(보통 .so 파일)는 물론이고 아카이브 라이브러리(보통 .a 파일)도 공유할 수 있다. 이런 공유 기능은 전통적인 링크와 마찬가지로 링크 시점에서 심볼을 결정하지만 최종 이진 파일로 구성 목적 파일(아카이브에서 .o 파일) 복사가 필요하지 않다. 그렇기 때문에 동적 공유 라이브러리(.so/.sl 파일)와는 달리 동적(실행 중) 심볼 결정을 수행하지 않는다.

또한 read/exec로 표시된 libpthreads.a 코드 영역은 세그먼트 0xd에 올라왔다는 사실에 주목하자. 이 세그먼트는 앞서 언급한 바와 같이 공유 라이브러리를 위한 세그먼트로 AIX에서 지정되어 있다. 다시 말해 커널은 공유 라이브러리의 공유 가능한 세그먼트를 동일한 커널에서 동작 중인 모든 프로세스가 공유하는 영역에 올린다.

자료 섹션 역시 동일한 세그먼트(공유 라이브러리 세그먼트 0xf)에 위치한다는 사실을 눈치챘을지도 모르겠다. 하지만 이는 각 프로세스가 libpthreads.a의 자료 섹션까지 공유함을 의미하지는 않는다. 조금 느슨하게 정의해 보자면, 이런 배치는 동작하지 않는다. 각 프로세스 별로 다른 이름으로 다른 자료 값을 유지할 필요가 있기 때문이다. 물론 가상 메모리 주소는 동일할지 몰라도 세그먼트 0xf는 libpthreads.a를 사용하는 각 프로세스마다 다르다.

svmon 명령어는 프로세스에 대한 Vsid(가상 메모리 관리자에서 세그먼트 ID)를 보여준다. 공유 라이브러리 코드 세그먼트는 Vsid가 같지만, 공유 라이브러리 자료 세그먼트는 Vsid가 제각각이다. 유효 세그먼트 ID인 Esid는 프로세스의 주소 공간 범위 내에서 세그먼트 ID를 의미한다(그냥 용어 설명이므로 혼동하지 말기 바란다).

# svmon -P 17314

-------------------------------------------------------------------------------
     Pid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd  16MB
   17314 dtexec           20245     9479       12    20292      N     N     N

    Vsid      Esid Type Description              PSize  Inuse   Pin Pgsp Virtual
       0         0 work kernel segment               s  14361  9477    0 14361 
   6c01b         d work shared library text          s   5739     0    9  5786 
   19be6         f work shared library data          s     83     0    1    87 
   21068         2 work process private              s     56     2    2    58 
   18726         1 pers code,/dev/hd2:65814          s      5     0    -     - 
    40c1         - pers /dev/hd4:2                   s      1     0    -     - 
#
# svmon -P 20428

-------------------------------------------------------------------------------
     Pid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd  16MB
   20428 dtlogin          20248     9479       23    20278      N     N     N

    Vsid      Esid Type Description              PSize  Inuse   Pin Pgsp Virtual
       0         0 work kernel segment               s  14361  9477    0 14361 
   6c01b         d work shared library text          s   5735     0    9  5782 
   7869e         2 work process private              s     84     2   10    94 
                   parent=786be
   590b6         f work shared library data          s     37     0    4    41 
                   parent=7531d
   6c19b         1 pers code,/dev/hd2:65670          s     29     0    -     - 
   381ae         - pers /dev/hd9var:4157             s      1     0    -     - 
    40c1         - pers /dev/hd4:2                   s      1     0    -     - 
   4c1b3         - pers /dev/hd9var:4158             s      0     0    -     - 




위로


산수 놀이

공유 세그먼트 0xd에서 얼마나 많은 메모리를 차지하는지 살펴보자. 다시 한번 bc 계산기를 써보자. 정신 바짝 차리고, 세그먼트 0xd 크기를 비교해보자.

# bc    
ibase=16
E0000000-D0000000
268435456
ibase=A
268435456/(1024^2)
256

여기까지는 좋아 보인다. 위에서 언급한 내용처럼 각 세그먼트는 256MB다. 좋다. 이제 현재 사용 중인 메모리 용량을 살펴보자.

$ echo "ibase=16; $(genkld | egrep ^\ \{8\} | awk '{print $2}' | tr '[a-f]' '[A-F]' \
	|  tr '\n' '+' ) 0" | bc
39798104
$
$ bc <<EOF
> 39798104/(1024^2)
> EOF
37

현재 사용 중인 메모리는 37MB라고 알려준다. XIr2를 시작한 다음에 비교해보자.

$ echo "ibase=16; $(genkld | egrep ^\ \{8\} | awk '{print $2}' | tr '[a-f]' '[A-F]' \
	|  tr '\n' '+' ) 0" | bc
266069692
$
$ bc <<EOF
> 266069692/(1024^2)
> EOF
253

이제 253MB를 사용 중이다. 이는 256MB 한계에 아주 근접한 값이다. WIReportServer와 같은 프로세스를 임의로 골라 공유 영역으로 얼마나 많은 공유 라이브러리를 밀어넣었으며 얼마나 많은 라이브러리를 내부적으로 사상했는지 살펴보자. 공유 세그먼트 시작 주소가 0xd000000라는 사실을 알고 있으므로, procmap 결과에서 필터링해보자. 단지 코드 섹션만 세그먼트 0xd에 사상된다는 사실을 기억하자. 따라서 read/exec 행만 살펴보면 된다.

$ procmap 35620 | grep read/exec | grep -v ^d
10000000       10907K  read/exec         boe_fcprocd
31ad3000       14511K  read/exec
/crystal/sj1xir2a/xir2_r/bobje/enterprise115/aix_rs6000/libEnterpriseFramework.so
3167b000        3133K  read/exec
/crystal/sj1xir2a/xir2_r/bobje/enterprise115/aix_rs6000/libcpi18nloc.so
3146c000        1848K  read/exec
/crystal/sj1xir2a/xir2_r/bobje/enterprise115/aix_rs6000/libBOCP_1252.so
31345000         226K  read/exec
/crystal/sj1xir2a/xir2_r/bobje/enterprise115/aix_rs6000/btlat300.so

위에 나타난 네 가지 라이브러리는 공유 세그먼트로 사상될 수 없는 듯이 보인다. 필연적으로 네 가지 라이브러리는 mmap() 루틴을 호출해 할당한 범용 메모리로 쓰이는 내부 세그먼트 0x3에 사상되었다.

공유 라이브러리를 32비트 AIX에서 내부적으로 강제로 사상하기 위해서는 몇 가지 조건이 필요하다.

  • (위에서 발생한 상황처럼) 공유 세그먼트 0xd 영역이 꽉 차 있다.
  • 그룹과 다른 사람에 대한 실행 권한이 공유 라이브러리에 없다. 이런 문제를 해결하려면 접근 허가를 rwxr-xr-x로 지정하면 된다. 하지만 개발자들은 자신에게만 접근 허가를 주기를 원하므로(예: rwx------), 테스트 목적으로 공유 라이브러리를 컴파일해 배포할 때마다 sibclean을 돌릴 필요가 없다.
  • 몇몇 문서는 nfs 위에서 공유 라이브러리를 메모리에 올리면 이렇게 된다고 말한다.

AIX 커널은 동일한 라이브러리라도 다른 위치에서 시작했다면 공유 메모리에 두 번 올릴 것이다.

sj2e652a-chloe:~/e652_r>genkld | grep libcplib.so
        d5180000    678c6 /space2/home/sj2e652a/e652_r/lib/libcplib.so
        d1cf5000    678c6 /home/sj1e652a/xir2_r/lib/libcplib.so




위로


뭔가 잘못되었을 때

다른 디렉터리에 설치된 XIr2 인스턴스를 다시 한번 돌린다면, 프로세스 메모리 크기에 상당한 차이가 난다.

$ ps -e -o pid,vsz,user,comm | grep WIReportServer
28166 58980   jbrown WIReportServer
46968 152408 sj1xir2a WIReportServer
48276 152716 sj1xir2a WIReportServer
49800 152788 sj1xir2a WIReportServer
50832 152708 sj1xir2a WIReportServer

'jbrown' 계정에서 돌리는 인스턴스가 첫 번째로 시작했으며, 'sj1xir2a' 계정에서 돌리는 인스턴스가 두 번째로 시작했다. 두 번째 인스턴스를 돌리기 앞서 bobje/setup/env.sh 파일에서 적절한 위치에 다음과 같은 항목을 설정해 뭔가 조금 이상한 작업을 했다면

    LIBPATH=~jbrown/vanpgaix40/bobje/enterprise115/aix_rs6000:$LIBPATH

메모리 사용량이 정규화된 상태를 확인할 것이다(이 LIBPATH 테스트에서는 WIReportServer를 시동할 수 없기에 프로세스 boe_fcprocd를 사용했다).

$ ps -e -o pid,vsz,user,comm | grep boe_fcprocd   
29432 65036   jbrown boe_fcprocd
35910 67596   jbrown boe_fcprocd
39326 82488 sj1xir2a boe_fcprocd
53470 64964 sj1xir2a boe_fcprocd

그리고 기대한 바와 같이 procmap은 ~jbrown에서 올라온 파일을 보여준다.

53470 : /crystal/sj1xir2a/xir2_r/bobje/enterprise115/aix_rs6000/boe_fcprocd
-name vanpg 
10000000       10907K  read/exec         boe_fcprocd
3000079c        1399K  read/write        boe_fcprocd
d42c9000        1098K  read/exec
/home7/jbrown/vanpgaix40/bobje/enterprise115/aix_rs6000/libcrypto.so
33e34160         167K  read/write
/home7/jbrown/vanpgaix40/bobje/enterprise115/aix_rs6000/libcrypto.so
33acc000        3133K  read/exec
/home7/jbrown/vanpgaix40/bobje/enterprise115/aix_rs6000/libcpi18nloc.so
33ddc697         349K  read/write
/home7/jbrown/vanpgaix40/bobje/enterprise115/aix_rs6000/libcpi18nloc.so




위로


정리

응용 프로그램이 종료되었다면, 공유 라이브러리는 여전히 공유 세그먼트 0xd에 남아있을지도 모른다. 이런 경우에는 'slibclean' 유틸리티를 사용해 더 이상 참조하지 않는 공유 라이브러리를 메모리에서 내린다. 이 유틸리티에는 인수가 필요없다.

slibclean

또한 -l 옵션을 추가하면 procmap과 비슷한 결과를 보여주는 genld라는 유틸리티는 현재 시스템에 존재하는 모든 프로세스를 보여준다.

genld -l

종종 slibclean을 돌린 다음에도 공유 라이브러리 복사가 여전히 불가능할 경우가 있다. 예를 들면 다음과 같다.

$ cp /build/dev/bin/release/libc3_calc.so   /runtime/app/lib/
cp: /runtime/app/lib/libc3_calc.so: Text file busy

이미 slibclean을 돌렸기 때문에 'genld -l'은 이 라이브러리가 메모리에 올라온 프로세스를 보여주지 않는다. 하지만 시스템은 여전히 이 파일을 보호하고 있다. 이런 문제점을 극복하려면 우선 목표 위치에 있는 공유 라이브러리를 지운 다음에 새로운 공유 라이브러리를 복사하면 된다.

$ rm /runtime/app/lib/libc3_calc.so
$ cp /build/dev/bin/release/libc3_calc.so   /runtime/app/lib/

공유 라이브러리 개발 과정 동안, 컴파일, 링크, 실행, 예제 실행을 반복한다면 단지 소유주(r_xr__r__)만 실행 가능한 공유 라이브러리를 만드는 방법으로 매 주기마다 slibclean 명령을 내리지 않아도 된다. 이렇게 하면 테스트 목적으로 사용하는 프로세스를 메모리에 올려 공유 라이브러리를 내부적으로 사상할 것이다. 하지만 궁극적으로는 모든 사람이 실행 가능하도록 주의해야 한다(즉, 제품 배포 시점에서 r_xr_xr_x이 되어야 한다).




위로


요약

공유 라이브러리가 메모리를 차지하는 방법과 이를 검사하기 위해 사용된 유틸리티에 대한 방법을 자세히 살펴봤으리라 믿는다. 이 기사를 통해, 응용 프로그램이 요구하는 메모리 크기 조건을 평가하고 AIX 시스템에서 돌아가는 프로세스에 대한 메모리 사용량 구성 요소를 분석할 수 있을 것이다.



참고자료

교육

토론


필자소개

George Cross는 유닉스에서 C++로 서버 응용 프로그램을 개발한 경력이 있으며, Business Objects Americas에서 선임 소프트웨어 개발자로 활약하고 있다. Cross는 Simon Fraser University에서 컴퓨터 과학 학사 학위를 취득했다.

Posted by saudades

댓글을 달아 주세요

2009.02.03 16:55

svmon 명령은 메모리의 현재 상태에 관한 정보를 보여줍니다.
표시된 정보는 메모리의 실제 스냅샵을 구성하지 않는데,
그 이유는 svmon 명령이 인터럽트가 가능한 사용자 레벨에서 수행되기 때문입니다.

세그먼트는 페이지 세트로, 메모리 소비를 보고하기 위해 사용되는 기본 오브젝트입니다.
그러므로, svmon에 의해 보고되는 통계는 페이지 수 측면에서 표시됩니다.

1 페이지는 가상 메모리의 4K 블록이고, 1 프레임은 실제 메모리의 4K 블록입니다.
달리 명시하지 않으면, 모든 통계는 4096 바이트 메모리 페이지 단위입니다.
메모리 소비는 inuse, free, pin, virtual 및 paging space 계수기를 사용하여 보고됩니다.
 
  - inuse 계수기 : 사용된 프레임 수
  - free : 모든 메모리 풀에서 사용 가능한 프레임 수
  - pin : 고정된 프레임 수, 즉 스왑될 수 없는 프레임 수
  - virtual : 시스템 가상공간에 할당된 페이지 수
  - paging space : 페이징 공간에서 예약되거나 사용된 페이지 수

한 세그먼트를 여러 개의 프로세스에서 사용할 수 있습니다.
그러한 세그먼트에 속한 각 페이지는 해당 세그먼트를 사용하는 각 프로세스에 대해서

inuse, pin, virtual 또는 pgspace 필드에서 설명됩니다.

그러므로, 활성화된 모든 프로세스에 걸친 inuse, pin, virtual 및 pgspace 필드의 합계가
메모리나 페이징 공간의 총 페이지 수를 초과할 수도 있습니다.

VMM은 통계 목적으로만 virtual 페이지 계수기를 관리합니다.
즉, 항상 최신 데이터가 아니며 값도 해당되는 inuse 계수기보다 작을 수 있습니다.

세그먼트는 다음의 5가지 유형 중 하나에 속합니다.

persistent - 파일 및 디렉토리 조작에 사용되는 세그먼트
working - 프로세스 및 공유 메모리 세그먼트의 데이터 영역을 구현하기 위해 사용되는 세그먼트
client - NFS와 CD-ROM 파일시스템과 같은 일부 가상 파일 시스템을 구현하기 위해 사용
mapping - 메모리에서 파일 맵핑을 구현하기 위해 사용되는 세그먼트
real memory mapping - 가상 주소 공간으로부터 10 공간에 액세스하기 위해 사용되는 세그먼트


시스템 전체 메모리 사용량 통계 확인

# svmon -G size inuse free pin virtual memory 32760 22182 10578 6035 25932 pg space 65536 8061 work pers clnt lpage pin 6035 0 0 0 in use 17057 5125 0 0

간단히 설명하면, 전체 메모리 사이즈는 32760*4096byte/1024/1024 = 127MB.
Free Memory는 10578*4096/1024/1024 = 41MB

4096byte를 곱한 이유는 svmon에서 나오는 결과는 전부 페이지단위(1page=4K)이므로....

 
memory - 다음을 포함해 실제 메모리의 사용을 설명하는 통계를 지정.
  - size 실제 메모리 프레임의 수(실제 메모리 크기)
  - inuse 페이지를 포함되는 프레임의 수
  - free 모든 메모리 풀 중 사용 가능 프레임의 수
  - pin 고정된 페이지를 포함하는 프레임의 수
  - virtual 시스템 가상 영역내에 할당된 페이지 수
 
in use - 다음을 포함해 사용중 인 실제 메모리의 서브세트에 대한 통계
  - work 작업 세그먼트 페이지를 포함하는 프레임 수
  - pers 영구 세그먼트 페이지를 포함하는 프레임 수
  - clnt 클라이언트 세그먼트 페이지를 포함하는 프레임 수

 

pin - 다음을 포함해 고정된 페이지가 있는 실제 메모리의 서브세트에 대한 통계 열거.
  - work 작업 세그먼트 페이지를 포함하는 프레임 수
  - pers 영구 세그먼트 페이지를 포함하는 프레임 수
  - clnt 클라이언트 세그먼트 페이지를 포함하는 프레임 수

 

pg space - 페이지공간의 사용을 설명하는 통계를 나타냅니다
  - size 페이징 공간의 크기
  - inuse 사용 중인 페이징 공간 페이지 수


유저별 메모리 사용량 통계 확인
# svmon -U root -d ; root 사용자가 사용하는 메모리 내역 =============================================================================== User Inuse Pin Pgsp Virtual LPageCap root 10556 2000 5555 16182 Y ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd LPage 3922 dtgreet 5045 1823 1705 7781 N N N 7020 rpc.mountd 5032 1826 1595 7629 N Y N 8514 hostmibd 5010 1823 1586 7281 N N N 4518 X 4981 1825 1938 7838 N N N 1 init 4979 1823 1579 7576 N N N 13420 getty 4963 1823 1586 7245 N N N 7482 portmap 4877 1823 1614 7513 N N N 13158 getty 4858 1823 1674 7239 N N N 2524 telnetd 4741 1823 1574 7292 N N N 3600 telnetd 4741 1823 1574 7292 N N N 15494 i4lmd 4729 1823 1586 7238 N N N 15752 i4lmd 4722 1823 1586 7221 N N N 7998 snmpd 4717 1823 1616 7339 N N N 12412 i4lmd 4712 1823 1583 7213 N N N 16512 i4lmd 4710 1823 1597 7234 N N N 14972 i4llmd 4705 1823 1627 7217 N N N 14466 i4llmd 4680 1826 1686 7284 N Y N 17386 -ksh 4671 1823 1574 7214 N N N 18012 -ksh 4670 1823 1574 7214 N N N 8256 dpid2 4647 1823 1576 7254 N N N 4756 svmon 4631 1823 1574 7211 N N N 7740 inetd 4628 1823 1574 7225 N N N 9834 cron 4626 1823 1594 7227 N N N 5166 errdemon 4624 1823 1661 7250 N N N 16256 IBM.AuditRMd 4599 1830 2010 7675 N Y N 5704 prngd 4598 1823 1574 7193 N N N 15998 IBM.ERrmd 4592 1830 2114 7785 N Y N 14212 rmcd 4586 1826 2112 7733 N Y N 7226 syslogd 4573 1823 1608 7205 N N N 5422 srcmstr 4572 1823 1656 7229 N N N 2704 dtlogin <:0> 4567 1823 1602 7202 N N N 15232 IBM.CSMAgentR 4563 1832 2125 7775 N Y N 14712 ctcasd 4562 1830 1968 7566 N Y N 9550 biod 4555 1823 1574 7160 N N N 13938 diagd 4546 1823 1627 7188 N N N 6268 nfsd 4542 1823 1597 7175 N N N 11356 qdaemon 4537 1823 1608 7173 N N N 10586 rpc.lockd 4527 1823 1635 7199 N N N 3412 syncd 4525 1823 1603 7159 N N N 4246 dtlogin 4520 1823 1601 7152 N N N 10846 uprintfd 4517 1823 1580 7131 N N N 11618 writesrv 4516 1823 1638 7191 N N N 11094 rpc.lockd 2907 1832 1561 4326 N Y N 10066 nfsd 2906 1832 1561 4326 N Y N 1548 gil 2898 1827 1563 4320 N Y N 9030 kbiod 2888 1824 1559 4306 N Y N 6726 j2pg 2887 1828 1572 4318 N Y N 1032 xmgc 2884 1823 1559 4302 N N N 1290 netm 2884 1823 1559 4302 N N N 8774 rtcmd 2884 1823 1559 4302 N N N 774 reaper 2884 1823 1561 4302 N N N 3102 lvmbb 2882 1823 1561 4302 N N N 516 wait 2882 1823 1559 4300 N N N 1806 wlmsched 2882 1823 1561 4302 N N N 0 swapper 4 2 0 4 N N N ............................................................................... SYSTEM segments Inuse Pin Pgsp Virtual 3008 1888 1631 4487 Vsid Esid Type Description LPage Inuse Pin Pgsp Virtual 0 0 work kernel seg - 2880 1821 1559 4298 8c5 - work - 23 9 1 23 16aa - work - 22 9 1 23 2792 - work - 11 9 18 29 1a0f - work - 11 7 12 23 2191 - work - 11 7 12 23 3f3e - work - 11 7 15 22 1eae - work - 10 3 0 10 3619 - work - 9 3 3 10 2752 - work - 7 3 8 11 e26 - work - 5 5 1 6 1a2d - work - 4 4 1 5 3c9f - work - 4 1 0 4 ............................................................................... EXCLUSIVE segments Inuse Pin Pgsp Virtual 5915 112 3909 8875 Vsid Esid Type Description LPage Inuse Pin Pgsp Virtual aa4 2 work process private - 396 2 15 410 182c 2 work process private - 374 2 4 377 19cc 2 work process private - 327 2 119 446 365b - pers /dev/hd2:12338 - 312 0 - - 3b9d 2 work process private - 296 2 345 640 2473 2 work process private - 275 2 38 313 .......... ..........(중략) 3f9e - pers /dev/hd9var:308 - 0 0 - - 1e8e 1 pers code,/dev/hd2:10638 - 0 0 - - d67 - pers /dev/hd9var:2127 - 0 0 - - 27b3 - work shmat/mmap - 0 0 2 2 2151 - pers /dev/hd9var:2115 - 0 0 - - 2012 3 mmap mapped to sid 1408 - 0 0 - - 1d4f - pers /dev/hd9var:120 - 0 0 - - ............................................................................... SHARED segments Inuse Pin Pgsp Virtual 1633 0 15 2820 Vsid Esid Type Description LPage Inuse Pin Pgsp Virtual 2a15 d work shared library text - 1633 0 15 2820

 
특정 명령어의 메모리 사용량 통계 확인
# svmon -C inetd ; inetd 데몬에 의해 사용되어지는 메모리 통계 =============================================================================== Command Inuse Pin Pgsp Virtual inetd 4628 1823 1574 7225 ............................................................................... SYSTEM segments Inuse Pin Pgsp Virtual 2880 1821 1559 4298 Vsid Esid Type Description LPage Inuse Pin Pgsp Virtual 0 0 work kernel seg - 2880 1821 1559 4298 ............................................................................... EXCLUSIVE segments Inuse Pin Pgsp Virtual 115 2 0 107 Vsid Esid Type Description LPage Inuse Pin Pgsp Virtual 2a74 2 work process private - 62 2 0 62 367a f work shared library data - 45 0 0 45 3a7c 1 pers code,/dev/hd2:10656 - 7 0 - - 162e - pers /dev/hd2:68574 - 1 0 - - ............................................................................... SHARED segments Inuse Pin Pgsp Virtual 1633 0 15 2820 Vsid Esid Type Description LPage Inuse Pin Pgsp Virtual 2a15 d work shared library text - 1633 0 15 2820


프로세스 메모리 사용량 통계 확인
# svmon -P ; 시스템 프로세스별 메모리 통계 확인 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd LPage 3922 dtgreet 5045 1823 1705 7781 N N N Vsid Esid Type Description LPage Inuse Pin Pgsp Virtual 0 0 work kernel seg - 2880 1821 1559 4298 2a15 d work shared library text - 1633 0 15 2820 19cc 2 work process private - 327 2 119 446 3e5d f work shared library data - 173 0 11 188 27d3 - work shmat/mmap - 29 0 1 29 2b14 1 pers code,/dev/hd2:116793 - 3 0 - - 3198 - pers /dev/hd9var:2182 - 0 0 - - 106a - pers /dev/hd2:145819 - 0 0 - - 186e - pers /dev/hd2:68956 - 0 0 - - 1f8f - pers /dev/hd9var:2125 - 0 0 - - ...... ...... ...... ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd LPage 0 swapper 4 2 0 4 N N N Vsid Esid Type Description LPage Inuse Pin Pgsp Virtual 2412 2 work process private - 4 2 0 4

 
프로세스 개별확인은 # svmon -P (pid)


세그먼트 테이블 세그먼트 유형 세그먼트 사용법 설 명 ---------------------------------------------------------------------------------------- persistent 로그파일 로그 persistent 파일 및 디렉토리 장치 이름: i-노드 번호 persistent 대형 파일 대형 파일 장치 이름: i-노드 번호 mapping 파일 맵핑 sid 소스 sid에 맵핑됨 working 프로세스 및 공유 메모리 세그먼트의 VSID및 ESID를 기초로 세그먼트의 데이타영역 역할에 따라 다름 client NFS 및 CD-ROM 파일 상 동 rmapping IO 영역 맵핑 상 동

http://blog.naver.com/win2107/100010783120
Posted by saudades

댓글을 달아 주세요

2009.01.29 11:49

[출처] AIX 점검 명령어|작성자 피곤한데


하드웨어
CPU - 수량 및 사용 가능상태 확인
Command Description
lsdev-Cc processor      Processor 수량 및 Available 한 가용상태 확인
Sar-P ALL 5 10             각Processor의 사용률을 확인하여 문제되는 Processor 유무 확인

Memory - 수량 및 사용 가능상태 확인
Command Description
lsdev-Cc Memory Memory(Card)      수량 및 Available 한 가용상태 확인
lsattr-El mem(n)                              메모리 타입 및 Size 확인

Disk - 수량 및 사용 가능상태 확인
Command Description
lsdev-Cc disk      disk 수량 및 Available 한 가용상태 확인
lspv                    디스크 할당 상태 확인
lspv hdisk(n)       디스크 할당 상태 및 가용 Size 확인

Adapter - 구성된 종류 및 수량, 가용상태 확인
Command Description
lsdev-Cc adapter      adapter 별 Available 한 가용상태 확인
ssaraid-(option)       SSA Adapter의 구성상태 확인
diag                        구성 장치들의 문제점 진단

OS 및 환경
Storage - 저장공간으로 할당된 영역에 대한 가용상태 확인
Command Description
lsvg-o |lsvg -il          시스템에서 activity 한 volume group 및 vg에 할당되어 있는 LV 들의 sync 상태 확인
lspv                          디스크의 volume group 할당 정보확인
df -k                         파일 시스템 사용량 및 가용 Size 확인
ssaraid , ssaxlate      SSA Disk RAID 구성상태 확인
datapath , lsvpcfg      SAN Disk 구성 상태 확인

Environment - OS 최적 환경을 위한 구성 확인
Command Description
bootlist               System normal 또는 service 부팅 시 부트순서 확인.
mirroring             시에 미러 디스크가 리스트에 존재하는지 확인.
sysdumpdev       System dump를 위해 지정된 device 및 요구 size 를 충족하는지 여부 확인
lsattr-El sys0      system 전반적인 설정상태 확인
lslpp                  Install 된 fileset 들의 체크섬 정보와 링크 상태에 대한 진단.
lssrc                  System resource controller 의 daemon 수행 상태 확인

Log 점검 - 오류에 대한 로그 및 시스템에 설정된 로그파일 확인
Command Description
errpt                                    System 에서 발생된 기본적인 로그를 확인하고 Class:H (Hardware)와 type:P(PEND, PERF,                                  PERM) 부분의 발생여부 중점으로 점검
syslog /etc/syslog.conf        파일에 설정된 정보에 따른 로그파일을 분석하여 문제점 여부 파악.
alog                                    console에 Display 된 오류 정보나 booting 시 문제 되었던 부분, dump 정보에 대한 부분등을

                                         점검
vi /var/spool/mail/root          root 메일을 점검하여 관리자에게 통지된 에러 확인
find / -name core                 core 파일 생성 여부 확인하여 잘못 수행된 APP 프로세스 및 OS Base Processor의 존재 여부

                                          확인

 

성능
CPU - CPU의 병목 여부 파악
Command Description
sar                        Processor 별로 사용률 점검
vmstat                    processor 의 used, idle, wait 등을 파악
topas                     processor load average 를 검토
bindprocessor        processor bind 의 존재여부 확인 및 필요 시 binding
ps aux                  문제가 되거나 문제의 소지가 있는 process의 유무 점검

Memory - Memory의 과부하 여부 파악
Command Description
vmstat                   충분한 Free memory가 있는지 확인하고 paging in, out 여부를 파악하여 Memory 의 병목 여부 판단.
lsps                      Paging 공간의 사용률을 파악하여 메모리 병목 판단에 활용
topas                    Memory의 caching 사용여부와 사용률을 파악
ps aux                  프로세스 별로 메모리 사용률 파악
svmon                  프로세스 사용률 순 또는 Memory 사용률에 따른 순서로 상세한 사용에 대한 세부 내역파악.

Disk - Disk I/O 에 대한 병목 여부 파악
Command Description
iostat            각 Disk의 초당 read-write 및 busy율 을 파악하여 과도한 action이 이루어지는지 또는 I/O가 원할하게 이루어  지는지 확인

 

 

Etc - 기타 성능 분석을 위한 명령 실행
Command Description
netstat         네트워크 송수신에 이용되는 Memory의 overflow 현상이나 Collision 등의 발생 여부 확인
tprof            프로세스당 Processor 사용률 확인
netpmon      네트웤과 관련된 Process 사용률 확인
filemon        특정 Storage resource(LV, FS, Disk) 에 대한 집중적인 access 파악.


 


LOGGING 
[root]/ >errpt | more
B
식별자     시간소인   T C 자원 이름      설명
CD546B25   0406103906 I O SYSPFS         파일시스템 복구가 필요함
5537AC5F   0405150006 P H smc0           테이프 드라이버 장애
C60BB505   0405115506 P S SYSPROC        소프트웨어 프로그램의 비정상적인 종료
C60BB505   0228191506 P S SYSPROC        소프트웨어 프로그램의 비정상적인 종료
C60BB505   0228191006 P S SYSPROC        소프트웨어 프로그램의 비정상적인 종료
......

 

[root]/ >errpt -aj CD546B25
---------------------------------------------------------------------------
레이블:         JFS_FSCK_REQUIRED
식별자: CD546B25
날짜/시간:       2006년 4월  6일 목요
일련번호:       6184
기계 ID:         00095C8A4C00
노드 ID:         GW_DB
클래스:          O
유형:            INFO
자원 이름:       SYSPFS
설명
파일시스템 복구가 필요함
        권고 조치
        FSCK 유틸리티를 사용하여 전체 파일시스템 복구를 수행하십시오.
상세 자료
주/부 장치 번호
0031 0002
파일시스템 장치와 마운트 위치
/dev/lv_legato, /legato_backup
 
[root]/ >umount /legato_backup
 


[root]/ >df -k
파일시스템   1024 블록수      Free  %Used    Iused %Iused 마운트 위치
/dev/hd4         1048576    840496   20%     1947     1% /
/dev/hd2         5046272   2283324   55%    73086     6% /usr
/dev/hd9var      1048576    230140   79%     1440     1% /var
/dev/hd3         1048576    387248   64%      811     1% /tmp
/dev/hd1         10092544  4699856   54%    40362     2% /home
GW:/home/backup  23265280  7859488   67%    71462     2% /home/backup
/dev/log_lv      20447232 10929896   47%    56431     2% /home/log_unisql
/dev/lv01        7602176    980464   88%       18     1% /imsi
/dev/lv00      104857600  91683048   13%     3588     1% /home/destiny
/dev/edmsdb_lv  20971520  17088412   19%       34     1% /home/unisql/edms_db
/dev/gwdb_lv    20971520   9187640   57%       70     1% /home/unisql/gw_db
 
 

[root]/ >fsck -y /legato_backup
** /dev/rlv_legato 점검중(/legat)
** 0 단계 - 로그 점검
log redo processing for /dev/rlv_legato
** 1 단계 - 블록 및 크기 점검
** 2 단계 - 경로 이름 점검
** 3 단계 - 연결성 점검
** 4 단계 - 참조 계수 점검
참조되지 않은 파일  I=2053  소유자=unisql 모드=100600
크기=819200000 mtime= 3월  2일 17:18 2005  (재연결됨)
참조되지 않은 파일  I=2054  소유자=unisql 모드=100600
크기=24576000 mtime= 1월 20일 22:57 2005  (재연결됨)
참조되지 않은 파일  I=2055  소유자=unisql 모드=100600

 

Posted by saudades

댓글을 달아 주세요

2009.01.28 23:00
출처 : http://www.aixservice.net/

가능하면 최신의 nmon 버전을 사용하여 얻은 결과화일이어야 합니다. (버전 9 나 버전 8 추천됨)
결과화일명은 영문명이어야 합니다. 예를 들면 abcd.nmon 입니다.
굳이 정렬(Sorting) 하실 필요는 없습니다.

이 화일을 PC 로 Binary 모드로 FTP 하여 가져옵니다.

가져온 화일 abcd.nmon 을 알집등의 압축 유틸리티로  zip 압축하여 abcd.zip 으로 만듭니다.

이 abcd.zip 을 아래 NMON 웹분석기 어플리케이션의 입력파일로 주시면 됩니다.

- http://aixservice.net/nmon2rrd

원본파일인 abcd.nmon 이 아닌 abcd.zip 으로 압축하여 올리는 이유는 네트워크 부하를 줄이기 위해서 입니다.
평균 1/5 정도로 파일크기가 줄어드는 것 같습니다.
서버가 zip 압축된 파일을 자동으로 압축해제하여 성능그래프를 만들어 냅니다.

실제 예 :  - http://aixservice.net/nmon2rrd/output_sample/
Posted by saudades

댓글을 달아 주세요

2008.12.24 11:28
루트 권한으로 로그인 한 후

rmdev -dl 네트워크디바이스(ex: rmdev -dl en0) // 네트워크 디바이스 삭제
cfgmgr // 디바이스 다시잡기
lsdev -Cc adapter // 디바이스 조회

mktcpip -h'호스트네임' -a'IP주소' -m'서브넷마스크' -i'인터페이스이름' -g'게이트웨이주소' -A'no' -t'N/A'
(ex: mktcpip -h'211.102.185.123' -m'255.255.255.0' -i'en0' -g'211.102.185.1' -A'no' -t'N/A')
Posted by saudades

댓글을 달아 주세요

2008.10.27 09:44

설치된 파일세트와 버전 확인하기
#   lslpp -L

 AIX ML 확인하기
#   oslevel

알려져 있는(known) AIX ML 확인하기
#   oslevel -q

AIX 4.3.2.0 ML 이하의 파일세트 확인하기
#   oslevel -l 4.3.2.0

fix가 설치되어 있는지 확인하기(예 : IX38794와 IX48523). 
#   instfix -iak IX38794

maintenance 패키지가 있는지 확인하기
#   instfix -ik 433-02_AIX_ML

4.3.3.0-02 레벨로 업그레이드해야 하는 파일세트 확인하기
#   instfix -ciqk 4330-02_AIX_ML | grep ":-:"

AIX 5L(5.2, 5.3) 에서일정 ML에서
# oslevel -rl 5200-08 을 하시면 현재 ML 보다 낮은, 업데이트가 필요한 파일셋을 보여줍니다.
#oslevel -s
5200-08-01
처럼 TL 과 SP 까지 보여줍니다.


Posted by saudades

댓글을 달아 주세요

2008.10.23 09:05

난이도 : 초급

Shiv Dutta, Technical Consultant, IBM

2003 년 5 월 06 일
2005 년 6 월 14 일 수정

AIX®와 pSeries® 서버로 작업할 때 스스로 문제를 해결하고 싶은가? 전문가의 도움을 받지 않고 시간을 절약하기를 바라는가? Shiv Dutta가 AIX 필수 명령어들을 설명한다.

머리말

알다시피 AIX는 많은 명령어들이 있다. 이를 통해서 여러 가지 많은 작업들을 수행할 수 있다. 여러분의 필요에 따라, 이들 명령어들 중 일부만 사용할 수 있을 뿐이다. 사용되는 명령어는 사용자 마다, 그리고 필요마다 다르다. 하지만 공통적으로 사용되는 몇 가지 핵심 명령어들이 있다.

이 글에서 이러한 핵심 명령어들을 설명할 것이다. 여기에서 설명하는 명령어는 모든 AIX 릴리스에서 동일하게 작동하지만 테스트는 AIX 5.3에서 수행되었다.

주:
다음 섹션에서 논의될 bootinfo 명령어는 사용자 레벨 명령어가 아니며, AIX 4.2 이후 버전에서는 지원되지 않는다.

명령어

커널

32-bit 커널 또는 64-bit 커널을 실행하고 있다면 이를 어떻게 알 수 있는가?

커널이 32-bit를 실행하는지 아니면 64-bit를 실행하는지를 알고 싶다면 다음 명령어를 사용한다.

bootinfo -K

유니프로세서 커널을 실행하는지, 멀티프로세서 커널을 실행하는지 알려면?

/unix는 부팅된 커널에 대한 심볼릭 링크이다. 어떤 커널 모드가 실행되는지 알고 싶다면 ls -l /unix를 입력하고 어떤 /unix 파일이 링크 되었는지를 본다. 다음은 명령어에서 나올 수 있는 세 가지 아웃풋과 상응하는 커널이다.

/unix -> /usr/lib/boot/unix_up 		# 32 bit uniprocessor kernel 
/unix -> /usr/lib/boot/unix_mp 		# 32 bit multiprocessor kernel
/unix -> /usr/lib/boot/unix_64 		# 64 bit multiprocessor kernel       

주:
AIX 5L Version 5.3은 유니프로세서 커널을 지원하지 않는다.

한 개의 커널 모드에서 또 다른 커널 모드로 변경하려면?

설치 프로세스 동안, AIX 버전과 하드웨어에 맞는 커널들 중 하나가 기본적으로 실행된다. 이전 질문에서 메소드를 사용하여 32-bit 커널이 실행된다고 가정해 보자. 이를 64-bit 커널 모드에서 부팅해야 된다고 가정해 보자. 다음과 같은 명령어를 연속적으로 실행한다.

ln -sf /usr/lib/boot/unix_64    /unix
ln -sf /usr/lib/boot/unix_64    /usr/lib/boot/unix

bosboot -ad  /dev/hdiskxx
shutdown -r

/dev/hdiskxx 디렉토리는 부트 논리적 볼륨인 /dev/hd5이 위치한 곳이다. 어떤 xx가 hdiskxx에 있는지 알려면 다음 명령어를 실행한다.

 lslv -m hd5
 

주:
AIX 5.2에서, 32-bit 커널은 기본적으로 설치된다. AIX 5.3에서, 64-bit 커널은 64-bit 하드웨어에 설치되고, 32-bit 커널은 32-bit 하드웨어에 기본적으로 설치된다.

하드웨어

내 머신이 AIX 5L Version 5.3을 실행할 수 있는지의 여부를 알려면?

AIX 5L Version 5.3은 현재 모든 CHRP(Common Hardware Reference Platform) 기반 POWER 하드웨어에서 실행된다.

내 머신이 CHRP 기반인지를 어떻게 아는가?

prtconf 명령어를 실행한다. 이것이 CHRP 머신이면 chrp 스트링이 Model Architecture 라인에 나타난다.

내 pSeries 머신(하드웨어)가 32-bit인지 아니면 64-bit인지 알 수 있는 방법은?

다음 명령어를 사용한다.

bootinfo -y

머신의 실제 메모리가 얼마나 되는지 알고 싶다면?

실제 메모리(kilobytes (KB))를 알고 싶다면 다음 명령어를 사용한다.

bootinfo -r    

lsattr -El sys0 -a realmem 

내 머신이 64-bit 커널을 실행할 수 있을까?

64-bit 커널을 실행하려면 64-bit 하드웨어가 필요하다.

내 시스템 장치에 필요한 애트리뷰트 값은?

테이프 장치(rmt0)용 애트리뷰트 값을 알려면:

lsattr -l rmt0 -E

테이프 장치(rmt0)용 디폴트 애트리뷰트 값을 알려면:

lsattr -l rmt0 -D

TTY 장치(tty0)용 로그인 애트리뷰트 값을 알려면:

lsattr -l tty0 -a login -R

시스템 레벨 애트리뷰트를 디스플레이 하려면:

lsattr -E -l sys0

시스템이 얼마나 많은 프로세서를 갖고 있는가?

다음 명령어를 사용한다.

lscfg | grep proc

시스템이 보유한 하드 디스크의 수와 사용중인 하드 디스크를 알려면?

다음 명령어를 사용한다.

lspv

시스템에 대한 상세한 설정을 보려면?

다음 명령어를 사용한다.

lscfg

아래 옵션들은 특별한 정보를 제공한다.

-p 플랫폼 스팩의 장치 정보를 디스플레이 한다. 이 플래그는 AIX 4.2.1과 이후 버전에 적용된다.
-v 커스터마이징된 VPD 객체 클래스에서 발견된 VPD를 디스플레이 한다.

테이프 드라이브(rmt0)에 대한 자세한 정보를 디스플레이 하려면:

lscfg -vl rmt0

prtconf 명령어를 실행하면 비슷한 정보를 얻을 수 있다.

칩 유형, 시스템 이름, 노드 이름, 모델 번호 등을 알려면?

uname 명령어가 시스템에 대한 제세한 정보를 제공한다.

uname -p 시스템의 칩 유형을 디스플레이 한다. 예를 들어, PowerPC.
uname -r 운영 체계의 릴리스 번호를 디스플레이 한다.
uname -s 시스템 이름을 디스플레이 한다. 예를 들어, AIX.
uname -n 노드 이름을 디스플레이 한다.
uname -a 시스템 이름, nodename, 버전, 머신 ID를 디스플레이 한다.
uname -M 시스템 모델 이름을 디스플레이 한다. 예를 들어, 9114-275.
uname -v 운영 체계 버전을 디스플레이 한다.
uname -m 시스템이 실행되는 하드웨어의 머신 ID 번호를 디스플레이 한다.
uname -u 시스템 아이디 ID 번호를 디스플레이 한다.

AIX

AIX의 어떤 버전, 릴리스, 관리 레벨 등이 내 시스템에서 실행되고 있는가?

다음 명령어를 사용한다.

oslevel -r

lslpp -h bos.rte

파일시스템 크기를 변경하는 방법은?

/usr 파일시스템 크기를 1000000 512-byte 블록으로 늘리려면:

chfs -a size=+1000000 /usr

주:
AIX 5.3에서 JFS2 파일 시스템의 크기는 줄어들 수도 있다.

CD를 마운트 하려면?

다음 명령어를 사용한다.

mount -V cdrfs -o ro /dev/cd0  /cdrom

머신의 IP 주소를 얻으려면?

다음 명령어를 사용한다.

ifconfig -a

host Fully_Qualified_Host_Name
			

예를 들어, host cyclop.austin.ibm.com.

어떤 파일세트가 특정 바이너리를 포함하고 있는가?

bos.acct/usr/bin/vmstat를 포함하고 있다는 것을 확인하려면:

lslpp -w /usr/bin/vmstat

또는, bos.perf.tools/usr/bin/svmon을 포함하고 있다는 것을 보여주려면:

which_fileset svmon

관리 레벨의 모든 파일세트가 내 시스템에 설치되어 있는지를 확인하려면?

다음을 명령어를 사용한다.

instfix -i | grep ML

시스템에 픽스가 설치되었는지를 알고 싶다면?

IY24043가 설치되었는지를 알려면:

instfix -ik IY24043

파일세트가 필요한 사전 조건들을 갖추고 있고 완벽히 설치되어 있다는 것을 확인하려면?

어떤 파일세트가 설치 또는 수정되어야 하는지를 알려면:

lppchk -v

심볼릭 표현에서 로더 섹션의 헤더의 덤프와 심볼 엔트리를 얻으려면?

다음 명령어를 사용한다.

dump -Htv

페이징 공간 할당과 사용을 결정하려면?

다음 명령어를 사용한다.

lsps -a

내 시스템이 Simultaneous Multi-threading(SMT)를 사용할 수 있는지의 여부를 알려면?

AIX 5L Version 5.3을 실행하는 POWER5 기반 시스템이라면 SMT가 가능하다.

SMT가 내 시스템에서 실행되는지를 아는 방법은?

옵션 없이 smtctl 명령어를 실행하면 실행 여부를 알려준다.

SMT가 32-bit 커널에도 지원되는가?

그렇다. SMT는 32-bit와 64-bit 커널 모두 지원된다.

SMT를 실행하는 또는 실행하지 않는 방법은?

smtctl 명령어를 실행한다. 구문은 다음과 같다.

smtctl [ -m off | on [ -w boot | now]]

다음 옵션들을 사용할 수 있다.

-m off SMT 모드를 실행하지 않도록 설정한다.
-m on SMT 모드가 실행되도록 설정한다.
-w boot 다음 시스템 재부팅 전에 bosboot를 실행하면 다음 번 재부팅에 SMT 변경이 적용된다.
-w now SMT 모드를 일시적으로 변경하지만 재부팅 까지는 지속되지 않는다.

-w boot 또는 -w now 옵션이 지정되지 않았다면 모드 변경은 일시적으로 발생한다. 다음에 시스템을 재부팅 하기 전에 bosboot 명령어를 실행하면 후속 재부팅까지 지속된다.

파티션 스팩의 정보와 통계를 알고 싶다면?

lparstat 명령어는 파티션 정보 리포트와 사용 통계를 제공한다. 또한 하이퍼바이저 정보를 디스플레이 한다.

볼륨 그룹과 논리적 볼륨

볼륨 그룹이 정상인지, 큰지, 확장 가능한지를 알고 싶다면?

볼륨 그룹에 lsvg 명령어를 실행하고 MAX PV의 값을 확인한다. 값이 32 면 정상이고, 128 이면 큰 것이고, 1024 확장성 볼륨 그룹이다.

볼륨 그룹을 만드는 방법은?

아래 명령어를 사용하면 s partition_size가 각 물리적 파티션에 있는 메가바이트(MB)의 수를 설정한다. 물리적 파티션에서는 partition_size가 MB 단위로 1 에서 1024 까지 나타난다.(AIX 5.3의 경우 1 에서 131072 까지다.) partition_size 변수는 2의 제곱과 같다. (예를 들어: 1, 2, 4, 8). 표준 볼륨 그룹과 큰 볼륨 그룹의 디폴트 값은 가장 적은 값이다. 물리적 볼륨 당 1016 물리적 파티션이 그 한도이다. 확장성 볼륨 그룹의 디폴트 값은 물리적 볼륨 당 2040 물리적 파티션을 수용할 수 있는 가장 적은 값이다.

mkvg -y name_of_volume_group -s partition_size list_of_hard_disks
			

논리적 볼륨을 만드는 방법은?

다음 명령어를 사용한다.

mklv -y name_of_logical_volume name_of_volume_group number_of_partition
			

볼륨 그룹에 대한 쿼리

시스템에 볼륨 그룹을 보려면:

lsvg

rootvg의 모든 특징을 알려면:

lsvg rootvg

rootvg에서 사용되는 디스크를 보려면:

lsvg -p rootvg

디스크를 볼륨 그룹에 추가하는 방법은?

다음 명령어를 사용한다.

extendvg   VolumeGroupName   hdisk0 hdisk1 ... hdiskn 

내 하드 디스크에서 최대로 지원되는 논리적 트랙 그룹(LTG) 크기를 알려면?

lquerypv 명령어와 -M 플래그를 함께 사용한다. KB 단위로 LTG 크기를 보여준다. 아래 예제의 경우, hdisk0의 LTG 크기는 256 KB이다.

/usr/sbin/lquerypv -M hdisk0
256

하드 디스크 상에 lspv 명령어를 실행하여 MAX REQUEST의 값을 볼 수 있다.

디스크를 바꾸려면?

  1. extendvg VolumeGroupName  hdisk_new
  2. migratepv hdisk_bad hdisk_new
  3. reducevg -d VolumeGroupName hdisk_bad

논리적 볼륨을 미러링 하려면?

  1. mklvcopy LogicalVolumeName Numberofcopies
  2. syncvg VolumeGroupName

rootvg를 복사(복제) 하려면?

alt_disk_copy 명령어를 실행하여 현재 rootvg를 대체 디스크에 복사한다. 아래 예제는 rootvg을 hdisk1에 복제하는 방법이다.

alt_disk_copy -d  hdisk1

네트워크

네트워크 매개변수에 대한 값을 디스플레이 또는 설정하려면?

no 명령어가 네트워크 튜닝 매개변수에 대한 현재 또는 앞으로의 부트 값을 설정 및 디스플레이 한다.


Posted by saudades
TAGAIX

댓글을 달아 주세요

2008.10.21 17:44
1GB가 넘는 파일은 FTP로 업로드중 계속해서 fail 이 뜬다. 
해당 오류를 보니 452 Error writing file: A file cannot be larger than the value set by ulimit. 라고 나온다. 
문제는 AIX 에 최대 생성할 수 있는 파일용량이 1G로 제한되어 있었기 때문이다. 

하드_파일사이즈에 대한 정보를 확인하는 방법은 "ulimit -Ha" 이다. 


file size 가 unlimited 이면 제한이 없는것이다.

설정하는 방법은 "/etc/security/limit" 파일을 직접 수정한후, 다시 로그인하면 되고,
chuser 명령을 통해서도 변경이 가능하다.
"chuser fsize=-1 root" 와 같이 하면 root 계정의 soft fiel size 를 무제한으로 변경한다.
"chuser hard_fsize=-1 root" 와 같이 하면 hard file size 를 무제한으로 변경한다. 
"ulimit -f = -1" 과 같이 주면 현재 사용중인 유저의 file size 를 무제한으로 변경한다. 

어쨋든 로그를 확인하는 것은 무엇보다 중요하다. :-(
Posted by saudades
TAGAIX

댓글을 달아 주세요