머리말

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

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

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

# 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 사이클(총 프로세싱 단위 이상)을 요구하면, 공유 풀에서 사용되지 않은 용량을 활용할 수 있다.

위로

스케줄링 알고리즘

AIX 5는 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에는 두 개의 중요한 스케줄링 명령어가 있다: nice와 renice이다. 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에서, 스케줄러는 출발 할 준비가 된 모든 쓰레드의 실행 큐를 관리한다. 각각의 우선순위를 지진 모든 출발 준비가 된 쓰레드들은 실행 큐에서 연속적인 위치를 차지하고 있다.

AIX 5L은 각 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 5.3 SMT가 실행된 상태에서, 전통적인 활용 메트릭은 두 개의 논리적 프로세서들 때문에 잘못 다루어진다.
• 한 개의 쓰레드가 100퍼센트 busy 상태라면, 한 개의 유휴 쓰레드는 50 퍼센트 활용 상태가 된다. 실제로, SMT 쓰레드가 모든 CPU 리소스를 사용한다면, CPU는 새로운 Processor Utilization Resource Register- (PURR) 기반 메소드를 사용하여 리포트 된 대로, 100 퍼센트 busy 상태가 된다.

PURR

AIX 5.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 활용

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

• 경과된 PURR는 현재 샘플 기간 동안 계산된다.
• 이 값은, 이전에 추가된 고정된 크기로 증가(10 ms)하는 대신, 적절한 활용 카테고리 (user, sys, iowait, idle)에 추가된다.

• (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 레지스터를 사용하여 경과된 시간을 측정한다.

위로

AIX 5.3 명령어 변화

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

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

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

위로

쓰레드 우선 순위 식

아래 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_R과 sched_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 사용 패널티가 우세하기 때문이다. 더 작은 r은 nice 값에 분명한 영향을 미친다.

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

이 식은 AIX 5L에서 수정되어 우선 순위 레벨을 계산할 때 nice 값의 중요도를 높였다. 다른 버전의 AIX에, 두 개의 새로운 요소들이 도입되었다. x_nice와 x_nice_factor ("extra nice"와 "extra nice factor")이다. 아래 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_factor는 r 비율을 강화했다. 예를 들어, 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 양이 쓰레드의 우선 순위를 변경하는 방법을 보여주고 있다:

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는 빠른 또는 느린 우선 순위를 설정하는 방법이다.

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은 명령어가 종료될 때까지 지속적으로 리포트를 생성한다.

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

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 5는 vmstat 1 6 명령어의 결과이다:

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 명령어의 결과이다:

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

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 퍼센트이거나, 거의 가깝게 된다. 사용자와 시스템(us와 sy)의 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 시스템에서 생성된 것이다:

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퍼센트가 되어야 한다. 사용자와 시스템(us와 sy) CPU-활용도의 합이 100퍼센트에 다다르면 시스템은 CPU 병목 현상을 겪는다.

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

sar

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

• 각 샘플에는 타임 스탬프가 앞에 있다. 따라서, 전체 평균은 샘플의 끝에 나타난다.
  
  
• -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 savefile은 sar의 savefile에 저장된 데이터를 사용하여 리포트를 만들도록 명령한다. SMT를 실행하는 모든 논리적 프로세서의 경우, sar -P All 아웃풋은 물리적 프로세서가 소비한 physc (delta PURR/delta TB)를 보여준다. 이 칼럼은 프로세서들 간 나뉜 관련 SMT를 보여준다. 논리적 프로세서가 물리적 프로세서 사이클이 되는 시간의 비율을 계산한다. 할당된 용량의 사용률이 100 퍼센트 미만이면, U로 시작하는 라인이 추가되어 사용되지 않는 용량을 나타낸다. 공유 모드에서 실행될 때, sar는 소비된 할당 비율을 %entc로 표시한다. (((PPC/ENT)*100)

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)

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용 활용도를 나타낸다. 인터벌 메커니즘은 특정 인터벌 시 리포트의 수를 검색한다.

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

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

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

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

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

nice 명령어 사용하기

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

nice를 사용하면, 사용자는 평균 보다 낮은 우선순위로 명령어를 실행할 수 있다. 루트 사용자만이 nice 명령어를 사용하여 평균 보다 높은 우선순위로 명령어를 실행할 수 있다. 예를 들어, nice -5 iostat 10 3 >iostat.out 명령어는 iostat 명령어가 nice 값 25(20이 아님)로 시작하도록 한다. 시작 우선순위가 더 낮다. nice 값과 우선순위는 ps 명령어와 -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_R과 sched_D의 디폴트 값은 포그라운드와 백그라운드 프로세스간 구별을 허용하지 않는다. 이 두 값은 schedo 명령어에 sched_R과 sched_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 스케줄러 매개변수이다.

# 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로 업그레이드 해야 한다.

위로

케이스 스터디

두 개의 실제 예제에서는, IBM의 성능 전문가가 지금까지 배운 이론과 기술을 적용하는 방법을 설명한다.

Case 1

증상: 사용자는 500개의 다른 배치 스크립트로 시작하는 배치 스크립트를 갖고 있고, 각각의 스크립트는 데이터베이스를 쿼리 및 업데이트 한다. 각 스크립트는 또 다른 머신으로부터 사용자 요청으로 시작한다. 각 클라이언트 요청은 데이터베이스 서버 머신에 데이터베이스 사용자 쓰레드를 만든다. 응답 시간은 이 시간 동안 10초 미만으로 시작한다. 그 다음에는, 응답 시간은 점점 느려진다. 1분에서 2분까지 걸리기도 한다.

진단: 실행 큐는 이것이 수 백 개에 도달할 때까지 증가한다. 또 다른 증상으로는 100퍼센트 사용되고(8-way SMP 시스템), 99 퍼센트가 사용자 모드에서 사용되는 CPU가 포함된다. 몇 초간 모아진 AIX 트레이스 샘플을 검사하면, 패턴을 볼 수 있다. 하나의 쓰레드가 CPU를 사용하는 동안, 네트워크 패킷이 도착하고 네트워크 어댑터 인터럽트를 발생시킨다. 이것은 현재 실행되는 쓰레드를 CPU에서 가져갔기 때문에 인터럽트가 제공될 수 있는 것이다.

인터럽트 후에, 스케줄러는 다른 쓰레드가 실행될 수 있는지, 현재 실행되는 쓰레드 보다 더 높은 우선순위를 갖는지를 확인한다. 현재 실행되는 쓰레드가 이미 적은 타임슬라이스로 실행되었기 때문에, CPU 우선순위는 CPU 틱들을 누적한 만큼 증가했다. 500개의 각 스크립트는 우선순위 60으로 시작된다. 이들이 실행 가능하면, 현재 실행되는 쓰레드를 60보다 높은 우선순위로 선점한다. 이렇게 선점된 쓰레드는 실행 큐의 끝에 놓이게 되고, 우선순위가 다시 상승할 때까지 CPU를 대기해야 한다.

선점의 결과로 가끔, 쓰레드는 데이터베이스 잠금 상태로 선점된다. 이러한 유형의 잠금은 데이터베이스 소프트웨어 내의 애플리케이션 레이어에서 구현되기 때문에, 커널은 쓰레드가 잠금을 갖고 있는지를 알 수 없다. 잠금이 커널 레벨 잠금이거나 pthread 라이브러리 뮤텍스 잠금이면, 커널은 우선순위를 높이고, 쓰레드의 우선순위를 잠금을 요청한 실행 쓰레드의 우선순위와 같은 레벨로 올린다. 이러한 방식으로, 요청 쓰레드는 CPU를 얻어서 잠금을 해제하기 위해 잠금 홀더(holder)를 오랜 시간 기다릴 필요가 없다.

이 시나리오에서 잠금은 사용자 잠금이기 때문에, 데이터베이스 쓰레드는 스핀 카운트(조정 가능한 데이터베이스 매개변수)를 소진할 때까지 잠금 상태가 지속된 후, 수면 상태로 간다. 99퍼센트가 사용되는 CPU는 대게는 데이터베이스 잠금으로 고정된 쓰레드 때문이다.

처방: 우선순위 선점이 부정적인 효과를 준다는 것을 파악한 후에, 쓰레드 우선순위를 계산한 스케줄러 식을 조정했다. 식은 다음과 같다.

pri = base_pri + NICE + (C * r/32) 

pri는 새로운 우선순위이고, base_pri는 40이다. NICE는 nice 값이고(이 경우 20이다.), C는 CPU 사용도(틱)이고, r은 16이다.

쓰레드가 CPU 틱을 모으기 때문에, 우선순위 값은 더 커진다. 따라서 우선순위는 더 낮아지게 된다.

schedo 명령어는 sched_R 옵션을 사용하여 r 값을 변경하는 방법을 제공한다. schedo -p -o sched_R=0을 실행하면 r이 0이 되고, CPU 패널티(C * r/32)가 0이 된다. 이로써, nice 값이 변하지 않는 한, 우선순위가 변하지 않는다. nice 값이 모든 쓰레드에 같다면, 쓰레드는 우선순위 변화로 인해 선점되지 않고, 고유의 타임슬라이스를 마친다. 현재 실행 중이며, 데이터베이스 잠금을 보유한 쓰레드는 계속 실행되고 잠금을 해제한다.

결과: 변경을 통해 퍼포먼스가 변했다. 2분이었던 응답 시간이, 모든 스크립트를 완료하는데 단 몇 초가 걸릴 정도로 나아졌다. 우선순위 식의 C 값은 CPU 사용 감소 인수(C = C*d/32)에 의해 1초에 한번씩 재계산된다. schedo 명령어를 사용할 때 d 값을 0으로 설정하면 같은 결과를 얻었다. 이 경우, d=0이면, C*d/32 = 0이 된다. CPU 패널티 인수는 C*r/32이고, 이는 0이 되어서 우선순위가 40 + NICE가 된다.

Case 2

증상: pSeries 머신은 데이터베이스와 애플리케이션 서버로 사용되었다. 사용자들은 요청을 폼 기반 애플리케이션에 입력하고, 트랜잭션을 실행한다. 특정 시간에, 폼이 스크린 상에 업데이트 되고, 일반적인 단기 실행 쿼리가 리턴되는데 시간이 오래 걸린다는 사실을 알게 되었다.

진단: 이렇게 느려지는 현상이 관찰되었을 당시, 시스템으로 장기 실행 데이터베이스 일괄 작업들이 있었다. 일반적으로, 일괄 작업들은 밤에 실행되지만, 월말이 가까워 지면서 추가 일괄 작업들이 사용자가 시스템을 사용하는 낮 시간 동안 실행된 것이다. 일괄 작업들은 CPU를 많이 소모하고 지속적으로 실행 큐에 상주했다. 따라서, 사용자의 쓰레드는 일괄 작업의 쓰레드와 경쟁해야 했다.

CPU 사용이 증가하면서 우선순위가 강등되도록 하면, 일괄 작업의 우선순위는 더 낮아지고, 사용자 쓰레드가 실행된다. 하지만, 커널은 CPU 사용 값 C를 초당 반씩 줄이다. 이로써 일괄 작업의 우선순위는 단기간에 향상되었다. 따라서 일괄 작업들은 다시 사용자 쓰레드와 경쟁하게 되었다.

처방: CPU 사용을 줄이는데 사용된 강등 인수 (d/32)를 초당 한번으로 변경함으로써, 사용자 퍼포먼스를 높였다. schedo 명령어를 사용하여 d 값을 31로 설정했다. d의 값이 더 커질수록, C (C=C*d/32)의 값도 커진다.

C는 우선순위(pri=40+NICE+C*r/32)를 계산하는데 사용되기 때문에, 우선순위는 C가 커지게 되면 더 낮아진다. d 값을 더 높은 숫자로 설정함으로써, C 값은 평상시 보다 느리게 감소된다.

결과: 사용자 쓰레드는 일괄 쓰레드 보다 자주 CPU를 갖게 되었다. 결과적으로, 사용자는 퍼포먼스의 즉각적인 향상을 경험할 수 있었다. 물론, 일괄 작업은 다소 느려졌지만, 이러한 작업들은 언제라도 CPU를 얻을 수 있다. 일괄 작업에 영향을 최소화 했지만, 사용자 퍼포먼스는 매우 높아졌다.

케이스 스터디 노트: 패턴 따라가기

마지막으로 퍼포먼스에 영향을 미쳤던 한 가지 사건을 소개하고자 한다. 벤치마크 동안, CPU 사용이 100퍼센트에 다다르고, 대부분의 시간이 시스템에 편중되는 현상을 경험했다. 그 당시, 애플리케이션 퍼포먼스는 눈에 띄게 줄어들었다.

AIX 트레이스를 모은 결과, 반복되는 패턴을 발견했다. 한 개의 애플리케이션 프로세스가 한 주소에 있는 페이지 오류를 만난다. 이 페이지 오류는 VMM에서 protection exception을 일으킨다. 결국 커널은 이 프로세스에 SIGSEGV (segmentation violation) 신호를 보내게 된다. 프로세스가 시작되면, 같은 주소에서 페이지 오류가 다시 발생하고, 이는 또 다른 protection exception과 또 다른 SIGSEGV 신호를 프로세스에 보내는 결과를 초래한다. SIGSEGV 시그널에 대한 디폴트 시그널 해제는 프로세스를 죽이고 코어 덤프를 만드는 것이지만, 이 경우, 애플리케이션은 계속 실행되고 이 순환 고리에 머물러있었다. 대부분의 CPU 시간은 여기에 소비되었다.

조사한 끝에, 문제를 발견했다. 다른 컴포넌트의 개발자가 시그널 핸들러를 설치하여 테스트 프로세스 동안 코드에서 SIGSEGV 시그널을 잡았다. 테스팅을 완료한 후, 개발자는 시그널 핸들러를 지우는 것을 깜빡 잊었다. 벤치마크 동안, 나머지 애플리케이션과 연결된 컴포넌트와, 애플리케이션과 관련 없는 컴포넌트가 세그멘테이션 오류를 일으키게 되었다. 이 오래된 시그널 핸들러는 예외를 잡아도, 이를 무시하고, 프로세스를 시작했다. (예외를 일으켰던) 명령어가 재시작 되었고, 영원한 악순환이 시작된 것이다.

기사의 원문보기

• CPU monitoring and tuning

참고자료

• The AIX 5L Support for Micro-Partitioning and Simultaneous Multi-threading
  
  
• Operating system exploitation of the POWER5 system
  
  
• AIX 5L Differences Guide Version 5.3 Edition
  
  
• Capped and Uncapped Partitions in IBM POWER5
  
  
• AIX 5L Practical Performance Tools and Tuning Guide
  
  
• developerWorks AIX and UNIX zone
  
  
• developerWorks blogs
  
  

필자소개

아티클 순위

의견

위로

목차

• 머리말
• SMT란 무엇인가?
• 스케줄링 알고리즘
• AIX 5.3 명령어 변화
• 쓰레드 우선 순위 식
• AIX가 새로운 우선 순위를 계산하는 방법
• CPU를 소진했다면?
• 일반 명령어
• 시스템 성능 높이기
• 기타 기술 사용하기
• 개별 애플리케이션 튜닝
• 케이스 스터디
• 참고자료
• 필자소개
• 의견