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

성능 상태 정책 작성

성능 상태 정책은 WebSphere Extended Deployment에서 스스로를 보호하는 특정 성능 상태 기준의 정의입니다. 성능 상태 관리 기능은 소프트웨어 오작동 시 Application Server 환경을 검색할 때 정의된 정책을 사용합니다.

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

이 타스크의 단계를 수행하십시오. 또한 스크립트를 사용하여 성능 상태 정책을 작성 및 유지할 수 있습니다. 자세한 정보는 스크립트를 사용하여 성능 상태 정책 관리를 참조하십시오.
  1. 관리 콘솔에서 조작 정책 > 성능 상태 정책 > 새로 작성을 클릭하십시오.
  2. 성능 상태 정책 일반 특성을 정의하십시오.
    1. 성능 상태 정책 이름을 제공하십시오. 이름은 모든 성능 상태 정책에서 고유해야 하며 특정 네이밍 기준을 준수해야 합니다. 네이밍 기준은 성능 상태 정책 콘솔의 도움말 패널에서 간략히 설명합니다.
    2. OptionalColonSymbol 성능 상태 정책 설명 제공
    3. 성능 상태 조건을 선택하십시오. 사용 가능한 모든 조건에서 반응으로 서버 재시작을 지원합니다. 유효 기간 및 워크로드 조건은 예방 정책이며 나머지는 발견에 기반한 정책입니다.
      • 유효 기간 기반 조건은 이 정책과 연관된 구성원이 특정 유효 기간 값에 도달하면 트리거됩니다.
      • 초과 요청 제한시간 조건은 연관된 구성원에 지정된 요청이 제한시간을 초과하고 제한시간의 백분율이 지정된 값을 초과하면 트리거됩니다. 이 조건에서는 서버 재시작 반응 이외에도 스레드 덤프를 지원합니다.
        RestrictionColonSymbol 과도한 요청 제한시간 조건은 JMS 및 IIOP 통신량에 적용되지 않습니다.
      • 초과 응답 시간 조건은 발견에 기반한 이 정책과 연관된 구성원의 요청에 대한 평균 응답 시간이 특정 시간을 초과하면 트리거됩니다.
      • 메모리 조건: 초과 메모리 사용은 발견에 기반한 이 정책과 연관된 구성원의 메모리 사용이 특정 시간 동안 최대 힙 크기(백분율)를 초과하면 트리거됩니다.
      • 메모리 조건: 메모리 누수는 서버에서 사용 가능한 여유 메모리의 하향 추세가 Java 힙에서 일관되는지 검토합니다. 발견 레벨 설정에서 이 추세를 발견하는 시기를 판별합니다. 더 느린 설정의 경우 대부분의 히스토리 데이터가 필요합니다. 표준 및 더 빠른 설정의 경우 동일한 크기의 히스토리 데이터가 필요하지만 더 빠른 설정의 경우 Java 힙이 최대 구성 크기로 확장되기 전에 분석을 허용합니다. 이 경우 더 일찍 발견할 수 있지만 오탐지가 증가할 수도 있습니다. 이 조건에서는 반응으로 서버 재시작뿐만 아니라 힙 덤프를 지원합니다.
      • 스톰 드레인 조건은 낮은 응답 시간을 가지며 결함이 있는 클러스터 구성원으로 요청이 이동되는 상황을 발견합니다. 스톰 드레인은 지정된 시간 계열 데이터에서 변경 포인트 발견에 의존합니다. 변경 포인트를 발견기 위해 지정된 지점에서 왼쪽 중간값 및 오른쪽 중간값을 계산합니다. 한 지점에서 왼쪽 중간값은 이 샘플보다 먼저 도착한 N개 샘플의 중간값으로 구성되며 오른쪽 중간값은 나중에 도착한 N개 샘플(자체 포함)의 중간값입니다. 왼쪽과 오른쪽 중간값의 차이를 저장하고 이 차이를 지정된 창(N으로 설정됨)의 다른 차이와 비교하여 이 차이가 로컬 최대인지 판별합니다. 최대 차이인 경우 이 차이에 해당하는 지점을 변경 포인트라고 선언합니다. 스톰 드레인 발견 시 사용하는 두 개의 메트릭은 서버에서 관찰한 응답 시간 및 동적 워크로드 관리자 가중치입니다.

        더 빠른 발견, 높은 오탐지 가능성 정책에서는 응답 시간 및 동적 워크로드 관리자 가중치 모두에서 더 적은 샘플(N = 10)을 사용하며 샘플 세트에 따라 각 메트릭에서 변경 포인트를 발견합니다. 결과적으로 20개의 샘플(왼쪽 중간값에서 10개, 오른쪽 중간값에서 10개)을 대기하여 차이를 계산하고 로컬 최대인지 확인하므로 더 빨리 결론에 도달합니다. 샘플은 15초 간격으로 수집됩니다. 따라서 스톰 드레인은 발생 5분 이내에 발견할 수 있습니다. 그러나 샘플이 적으므로 샘플에서 일시적인 최대 사용 또는 최저 사용이 많이 나타나는 경우 오탐지 가능성이 더 높아집니다.

        더 느린 발견, 낮은 오탐지 가능성 정책에서는 응답 시간 및 동적 워크로드 관리자 가중치에서 더 많은 샘플(N = 15)을 사용합니다. 결과적으로 중간값 차이를 계산할 경우 30개의 샘플(왼쪽 중간값에서 15개, 오른쪽 중간값에서 15개)을 대기해야 하므로 더 늦게 결론에 도달합니다. 발견 시간은 7분 30초입니다. 그러나 샘플이 더 많으므로 일시적인 최대 사용 또는 최저 사용이 나타나는 샘플이 조금 있어도 중간값에는 큰 영향을 주지 않습니다. 따라서 오탐지 가능성은 더 낮아집니다.
        RestrictionColonSymbol 배수 조건은 JMS 및 IIOP 통신량에 적용되지 않습니다.
      • 워크로드 조건은 이 정책과 연관된 구성원이 사용자 정의 요청 수를 제공하는 경우 트리거됩니다.
    4. 다음을 클릭하십시오.
  3. 성능 상태 정책의 성능 상태 조건 특성을 정의하십시오. 표시하는 성능 상태 조건 특성은 선택한 성능 상태 조건에 따라 다양합니다.
    성능 상태 조건 특성
    최대 유효 기간
    이 필드는 유효 기간 기반 성능 상태 조건의 유효 기간 값을 설정할 때 사용합니다. 유효 기간 기반 조건 정책은 유효 기간이 특정 값에 도달한 경우 정책과 연관된 구성원을 재시작합니다. 가능한 값은 1시간 - 365일 사이의 일 또는 시간을 가리키는 모든 양수입니다. 1.5일과 같은 값을 입력하려면 소수점은 지원되지 않으므로 대신 36시간을 사용하십시오.
    위반 조건을 발생시키는 제한시간을 초과한 요청(백분율):
    이 필드는 제한시간을 초과한 요청(백분율)의 임계값을 설정합니다. 이 필드의 가능한 값은 1 - 99 사이의 모든 수입니다.
    응답 시간:
    초과 응답 시간 조건 정책은 완료된 요청의 평균 수가 지정된 기간을 초과하면 구성원을 재시작합니다. 이 필드의 가능한 값은 1밀리초 - 60분 사이입니다. MDB(Message Driven Beans)의 경우, 응답 시간은 onMessage 메소드에 사용된 시간을 기초로 합니다. 동기식 클라이언트의 경우, 응답 시간은 동일한 세션 오브젝트에 있는 클라이언트로부터 호출을 받는 시간 간격입니다. 응답 시간에는 Autonomic Request Flow Manager(ARFM) 대기열에서 보낸 시간도 포함됩니다.
    모니터할 최대 JVM 힙 크기(백분율):
    초과 메모리 사용 조건 정책에서는 시간이 지남에 따라 메모리 사용이 힙 크기(백분율)를 초과하면 구성원을 재시작합니다. 이 필드의 가능한 값은 1 - 99 사이의 모든 수입니다.
    JVM 힙 임계값을 위반하는 기간:
    초과 메모리 사용 조건 정책에서는 시간이 지남에 따라 메모리 사용이 힙 크기(백분율)를 초과하면 구성원을 재시작합니다. 총 사용된 메모리(백분율)는 구성원을 재시작할 시기를 판별하는 백분율 값으로 사용됩니다. 이 필드의 가능한 값은 1초 - 60분 사이입니다.
    총 요청 수
    이 필드는 선택한 성능 상태 정책이 워크로드인 경우 사용 가능합니다. 워크로드 조건 정책에서는 특정한 사용자 정의 요청 수를 제공하면 구성원을 재시작합니다. 가능한 요청 값은 1000 - 9223372036854775807 사이의 모든 수여야 합니다.
    조건의 발견 레벨:
    다음에서 선택하십시오.
    • 더 빠른 발견, 높은 오탐지 가능성, 오탐지의 가능성이 더 높지만 잠재적인 메모리 누수를 더 빨리 발견합니다.
    • 표준 발견, 표준 오탐지 가능성, 잠재적인 메모리 누수를 더 느리지만 정확히 발견합니다.
    • 더 느린 발견, 낮은 오탐지 가능성, 대부분의 잠재적인 메모리 누수를 정확히 발견합니다.
    성능 상태 관리 모니터 반응
    반응 모드
    감독 또는 자동을 선택하십시오. 반응 모드는 성능 상태 조건에서 정정 조치가 필요하다고 결정하는 경우 사용자 상호 작용의 레벨을 정의합니다. 감독 모드에서 제안된 조치 계획은 실행 전에 승인될 수 있습니다. 자동 모드는 승인 없이 모든 제안된 조치 계획을 수행합니다. 특히, 서버 재시작을 사용 가능하게 할 경우 자동 반응을 주의하여 사용하십시오. 서버를 재시작할 때 연속적인 서비스 가용성이 인터럽트될 수 있습니다.
    성능 상태 조건 위반 시 수행할 조치를 선택하십시오.
    성능 상태 조건에 따라 성능 상태 조건을 위반한 경우 수행할 조치를 하나 이상 선택할 수 있습니다.
    • 서버 재시작
    • 스레드 덤프 수행
    • IBM JDK(Java Development Kit)에서만 JVM 힙 덤프 수행
  4. 다음을 클릭하십시오. 다음 패널에서는 정책의 대상을 선택하도록 프롬프트를 표시합니다.
  5. 성능 상태 정책에서 모니터할 멤버쉽을 선택하십시오. 사용 가능한 멤버쉽 목록에 구성원 유형이 표시되면 모니터할 유형을 선택한 후 추가를 클릭하십시오.
    • Application Server 및 노드
    • 클러스터
    • 동적 클러스터
    논리 레이어를 모니터되는 멤버쉽에 적용할 수 있습니다. 예를 들어 특정 성능 상태 정책을 모든 클러스터 구성원 및 클러스터 외부의 Application Server에 적용하고자 할 수 있습니다. Application Server 패널에서 단일 Application Server 및 Application Server 패널에서 클러스터를 선택하십시오. 여기에는 클러스터의 모든 기존 및 잠재적인 Application Server가 들어 있습니다. 클러스터 구성원은 추가 논리를 적용하여 서비스에 대한 반응의 영향을 최소화합니다.
  6. 다음을 클릭하십시오.
  7. 새 정책을 검토하고 완료를 클릭하십시오. 콘솔 창의 헤더에 저장 옵션이 표시됩니다.
  8. 저장을 클릭하십시오. 저장 및 버리기 옵션이 있는 창이 표시됩니다. 다시 저장을 클릭하여 새 정책을 확약하십시오.

결과

이제 성능 상태 정책을 작성하여 대상 환경에 적용했습니다.

다음에 수행할 내용

다음 단계는 성능 상태 관리를 사용 가능하게 하는 것입니다. 사용 가능한 경우 성능 상태 정책에서 지능형 결정을 내리고 응용프로그램 배치 기능을 함께 사용하여 재시작을 보증하는 조건이 진행 중인 응용프로그램 작업에 영향을 주지 않도록 합니다. 자세한 정보는 성능 상태 관리 사용 가능 및 사용 불가능을 참조하십시오.



Related reference
스크립트를 사용하여 성능 상태 정책 관리

타스크 주제    

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

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