WebSphere Extended Deployment, Version 6.0.x     운영 체제: AIX, HP-UX, Linux, Solaris, Windows, z/OS

Autonomic Request Flow Manager(ARFM) 구성

일반적으로 필요하거나 권장되지는 않지만 Autonomic Request Flow Manager(ARFM)는 콘솔의 기본 설정을 변경하여 미세 조정이 가능합니다.

이 타스크의 수행 목적 및 시기

Autonomic Request Flow Manager(ARFM)는 작업 프로파일러, 제어기 및 게이트웨이와 같이 세 개의 컴포넌트를 포함합니다. 각 노드 그룹에서 ARFM 기능은 Node Agent에서 각각 실행 중인 하나의 작업 프로파일러 및 하나의 제어기에서 구현합니다. 이와 함께 게이트웨이 콜렉션은 HTTP 통신량의 경우 On Demand Router(ODR)에서, 그리고 IIOP 및 JMS 통신량의 경우백엔드 서버에서 실행됩니다. 게이트웨이에서 수신 HTTP 및 IIOP 요청을 중단한 후 대기열에 지정하는 동안 제어기는 제어 신호 또는 방향을 게이트웨이 및 배치 제어기에 제공합니다. 작업 프로파일러는 조작 중인 시스템의 관찰 내용에 따라 다양한 요청 유형의 계산 요구사항을 계속 예상합니다. 이 컴포넌트를 함께 사용하면 수신 요청의 우선순위를 올바르게 지정할 수 있습니다.

관리 콘솔 페이지에서 ARFM 기본 설정을 수정하려면 조작 정책 > 자율 관리자 > Autonomic Request Flow Manager(ARFM)를 클릭하십시오.
NoteColonSymbol 보안이 사용 가능한 경우 적절한 보안 권한이 없으면 일부 필드는 편집할 수 없습니다.
  1. 원하는 ARFM 설정을 수정하십시오.
    필드 목적 설정에 대한 팁
    수집 기간 각 ARFM 게이트웨이는 정기적으로 수집된 통계를 브로드캐스트합니다. 이 매개변수에서 기간을 지정합니다. 게이트웨이에서 보고하는 통계는 다음을 지원합니다.
    • WebSphere Extended Deployment 관리 콘솔의 런타임 도표.
    • ARFM 제어기 조작.
    • 응용프로그램 배치 제어기 조작.
    • 작업 프로파일러 조작.

    수집 기간을 설정하는 경우 충분한 수의 성능 샘플을 수집할 수 있도록 값을 높게 설정했는지 확인하십시오. 각 요청에 대한 샘플은 게이트웨이에서 수집합니다. 양호한 통계 측정을 생성하려면 수백 개의 샘플이 필요합니다.

    서비스 클래스와 연관된 요청은 250밀리초가 지나면 실행되고 평균 10개의 요청이 동시에 실행되는 예제를 사용합니다. (동시 값은 WebSphere Extended Deployment에서 환경의 자원 및 클러스터 크기에 따라 자동으로 계산됩니다. 동시 값은 콘솔의 런타임 조작 카테고리 아래 있는 시각화 패널에 표시될 수 있습니다.) 결과적으로 서비스 클래스는 초당 40개의 요청을 처리합니다. 따라서 수집 기간 값을 15초로 설정하면 각 수집 기간에 600개의 샘플을 수집합니다. 600개의 샘플 조사에서 제공된 메트릭은 유용하고 신뢰성이 높습니다.

    수집 기간 값을 너무 낮게 설정하면 성능 메트릭의 신뢰성이 떨어집니다. 적은 수의 샘플에서 파생된 성능 메트릭은 혼잡하고 신뢰성이 떨어지므로 샘플 크기를 늘리는 것이 좋습니다. 새 통계가 생성되면 ARFM 제어기가 활성화되므로 수집 기간 값을 너무 길게 설정하면 제어 설정의 재계산 빈도가 적어집니다. 따라서 WebSphere Extended Deployment에서 트래픽의 집약도 및 패턴이 갑작스럽게 변경된 경우 응답 횟수가 줄어듭니다.

    제어 주기 최소 길이 이 매개변수에서는 ARFM 제어기가 활성화되는 빈도를 정의합니다. 제어기 활성화는 입력을 평가하고 입력을 수신하여 새 제어 설정을 생성하는 프로세스입니다. ARFM 제어기의 활성화 프로세스는 해당 게이트웨이 중 하나에서 새 통계를 수신하고 이전 활성화 이후 경과 시간이 제어 주기 최소 길이 이상인 경우 또는 이전에 제어기가 활성화되지 않은 경우 시작됩니다. 이 설정에서는 더 낮은 한도를 제공하는 제어 주기 길이를 판별합니다. 예를 들어 하나의 ODR만 있는 상태에서 수집 기간을 30초로 설정하고 제어 주기 최소 길이를 60초로 설정한 경우 이전 통계 도착 시간이 12:00:59.9이므로 활성화가 한 번 12:00:00.0에 발생하고 다음에는 90.1초 후, 12:01:30.1에 발생함을 확인할 수 있습니다. 제어 주기 최소 길이를 58 또는 59초로 설정하면 약 60초에 해당하는 신뢰할만한 제어 주기를 보장할 수 있습니다.
    안정화 창 이 설정에서는 게이트웨이 통계의 연결을 허용하여 수신 게이트웨이 통계에 대한 ARFM 제어기 반응의 민감도를 설정합니다. 모든 게이트웨이에서 해당 ARFM 제어기는 해당 게이트웨이에서 최근 일부 통계 보고서의 실행 평균을 사용합니다. 안정화 창에서는 결합되는 보고서 수를 제어합니다.

    낮은 안정화 창 설정은 제어기의 민감도를 높이고 더 빠른 반응을 가능하게 합니다. 그러나 매개변수가 낮으면 데이터에서 혼잡 또는 예외에 대한 민감한 반응이 나타나기도 합니다.

    수집 기간 및 안정화 창의 곱이 실제 제어 주기 길이와 비슷한 것이 좋습니다. 구성된 제어 주기 최소 길이가 좀 더 큰 경우도 있습니다.

    최대 대기열 길이
    이 매개변수는 각 ARFM 대기열 길이를 대기열에 보유될 수 있는 최대 요청 수로 바인드할 때 사용합니다. ARFM은 모든 수신 트래픽을 플로우로 구분하여 각 플로우에서 별도의 대기열을 포함합니다. 특정 플로우는 다음과 같은 요청을 포함합니다.
    • 특정 서비스 클래스를 포함하는 요청.
    • 특정 전개 대상에서 제공되는 요청.
    • 특정 ODR을 검토하는 요청.
    요청이 도착했을 때 해당 대기열이 가득 찬 경우 요청은 거부됩니다.
    이 필드의 매개변수가 낮을 수록 단기 트래픽 버스트 때문에 요청을 거부할 확률은 높아집니다. 반면 이 필드의 매개변수가 높을 수록 대기열에서 요청을 보유하는 기간은 길어질 수 있습니다. 대기열에 지정된 요청은 메모리를 소비합니다. 기본 설정은 1000이지만 이 설정을 검토하여 사용자 환경에 가장 적합한 설정을 찾을 수 있습니다.
    최대 CPU 사용

    ARFM은 오버로드 보호 및 우선순위 성능을 제공합니다. ARFM은 해당 게이트웨이에서 요청을 대기열에 지정하여 Application Server의 오버로드를 방지합니다.

    이 릴리스에서 로드는 Application Server의 첫 번째 층에서 나타나는 CPU 사용의 관점에서 판별됩니다. 최대 CPU 사용 매개변수는 서버를 로드하는 부담을 ARFM에 알립니다. 최대 조건이 매우 높으면 이 사용 한계를 초과할 수도 있습니다.

    값이 높을 수록 자원 사용이 개선되고 값이 낮을 수록 조작이 보다 강력해집니다. 실제 로드는 복잡하고 가변적입니다. WebSphere Extended Deployment의 성능 관리 기술을 통해 로드의 변경사항에 반응하지만 어느 정도 시간이 지연됩니다. 이 반응 시간 중 시스템이 해당 구성 영역 외부에서 작동할 수도 있습니다. 구성된 값보다 CPU 사용이 더 높은 경우도 이에 해당합니다. Application Server에서 수 분 동안 CPU 사용이 100%로 조작되는 경우 일부 내부 통신 메커니즘이 중단되어 많은 기능이 손상되는 점이 관찰되었습니다.

    이 설정은 아래의 원래 속도 예상 대상 CPU 사용 설정과 일치해야 합니다. 하나를 변경한 경우 다른 사항도 변경해야 합니다. 각각의 기본값은 90%입니다.

    이 WebSphere Extended Deployment 릴리스에서 성능 관리는 Application Server 시스템의 첫 번째 층에 ODR을 사용하여 HTTP를 통해 도달하는 WebSphere 요청 이외의 다른 작업이 로드된 경우 제대로 작동하지 않습니다.

    이 설정은 응용프로그램 배치에 영향을 줍니다. 예상된 총 요구가 최대 CPU 사용 한계를 초과하는 경우 최상의 배치를 계산하기 전에 배치 제어기가 모든 동적 클러스터의 요구를 똑같이 감소시킵니다.

  2. 변경을 완료한 다음 확인 또는 적용을 클릭하십시오.
  3. 저장을 클릭하여 변경사항을 마스터 저장소에 저장했는지 확인하십시오.
  4. 방금 정의한 설정을 테스트하고 필요한 만큼 자주 반복하여 원하는 요청 플로우 성능을 확보하십시오.



Related tasks
다중 층 구성 시 속도 요소 구성

타스크 주제    

이용 약관 | 피드백 마지막 갱신 날짜: Mar 21, 2006 11:32:49 AM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=?topic=/com.ibm.websphere.xd.doc/info/odoe_task/todtunearfm.html

© Copyright IBM 2004, 2006. All Rights Reserved.
이 Information Center는 Eclipse 테크놀러지로 강화되었습니다. (http://www.eclipse.org)