추적 서비스를 사용하여 EJB 캐시 조정

EJB(엔터프라이즈 JavaBeans) 캐시 크기는 Application Server의 성능에 영향을 줄 수 있습니다. EJB 컨테이너를 최적의 성능 레벨로 조정하는 단계 중 EJB 캐시를 미세 조정하는 단계가 포함됩니다.

시작하기 전에

참고: 이 주제는 하나 이상의 애플리케이션 서버 로그 파일을 참조합니다. 권장되는 대안은 분배 및 IBM® i 시스템에서 SystemOut.log, SystemErr.log, trace.logactivity.log 파일을 사용하는 대신 HPEL(High Performance Extensible Logging) 로그를 사용하고 인프라를 추적하도록 서버를 구성하는 것입니다. 원시 z/OS® 로깅 기능과 연계하여 HPEL을 사용할 수도 있습니다. HPEL을 사용하는 경우 서버 프로파일 바이너리 디렉토리의 LogViewer 명령행 도구를 사용하여 모든 로그에 액세스하고 정보를 추적할 수 있습니다. HPEL 사용에 대한 자세한 정보는 HPEL을 사용한 애플리케이션 문제점 해결 정보를 참조하십시오.

이 태스크 정보

다음 프로시저에서는 최상의 캐시 크기를 판별하는 데 도움이 되도록 진단 추적 서비스를 사용하는 방법을 설명합니다.

프로시저

  1. EJB 캐시 추적을 사용 가능하게 하십시오. 추적 서비스를 사용하는 방법을 학습하려면 추적에 대한 작업 주제를 참조하십시오. [IBM i][AIX Solaris HP-UX Linux Windows]추적 서비스 설정에 대한 정보는 진단 추적 서비스 설정 주제를 참조하십시오.
    다음 추적 문자열을 사용하여 추적을 설정하십시오.
    com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy=all=enabled:com.ibm.ejs.util.cache.CacheElementEnumerator=
    all=enabled

    [IBM i][AIX Solaris HP-UX Linux Windows]최대 파일 크기200MB 이상으로 설정하십시오. 기본값(20MB)을 그대로 두면 추적 랩핑 때문에 단일 20MB 추적 로그까지만 채우고 일부 데이터는 유실될 수 있습니다.

    [IBM i][AIX Solaris HP-UX Linux Windows]히스토리 파일의 최대 수5로 설정하십시오. 파일 수는 5개로도 충분합니다. 하지만 5개 파일을 모두 채우고 추적이 랩핑되면 이 값을 늘리십시오.

  2. [IBM i][AIX Solaris HP-UX Linux Windows]서버를 중지하고 기존 로그를 삭제한 후 서버를 시작하십시오.
  3. [z/OS]서버를 중지하고 다시 시작하십시오.
  4. 일반 시나리오를 실행하여 캐시 추적 데이터를 캡처하십시오. 추적이 사용 가능한 일반 시나리오를 실행하여 EJB 캐시 추적 데이터를 가져와 다음 단계로 분석합니다.
  5. 추적 출력을 보고 분석하십시오.
    1. 추적 로그를 여십시오. 다음 추적 문자열 중 하나 또는 모두가 표시되는지 확인하십시오.

      [IBM i][AIX Solaris HP-UX Linux Windows]BackgroundLru 3  EJB Cache: Sweep (1,40) - Cache limit not reached : 489/2053
      BackgroundLru >  EJB Cache: Sweep (16,40) - Cache limit exceeded : 3997/2053 Entry

      [z/OS] Trace: 2007/03/22 11:47:07.048 01 t=7A9690 c=UNK key=P8 (13007002)
      ThreadId: 0000006a
      FunctionName: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
      SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
      Category: FINEST
      ExtendedMessage: EJB Cache: Sweep (23,40) - Cache limit not reached : 0/2053

      Trace: 2007/03/22 11:54:16.755 01 t=7BD3B0 c=UNK key=P8 (13007002)
      ThreadId: 0000006d
      FunctionName: EJB Cache: Sweep (75,37) - Cache limit exceeded : 3801/2053
      SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
      Category: FINER
      ExtendedMessage: Entry

      Cache limit란 단어를 포함하는 추적 문자열에는 비율이 나옵니다. (예: 3997/2053). 첫 번째 숫자는 현재 EJB 캐시에 있는 엔터프라이즈 Bean의 수(용량이라고 함)를 나타냅니다. 두 번째 숫자는 EJB 캐시 설정입니다. 이는 나중 단계에서 더 자세히 다룹니다. 분석에서 이 비율, 특히 용량을 사용하십시오.

      또한 Cache limit not reachedCache limit exceeded와 같은 문장이 있는지 확인하십시오.
      Cache limit not reached
      캐시가 적정 수준 이상입니다. 크기가 너무 크면 메모리를 낭비하는 것이므로 적정 값으로 캐시 크기를 줄여야 합니다.
      Cache limit exceeded
      현재 사용 중인 Bean 수가 지정된 용량을 초과하므로 캐시가 적절히 조정되지 않았음을 의미합니다. 설정값은 고정된 한계가 아니므로 용량이 EJB 캐시 설정을 초과할 수도 있습니다. 한계에 도달해도 EJB 컨테이너는 캐시에 Bean을 추가하는 작업을 중지하지 않습니다. 즉, 캐시가 가득 차도 Bean에 대한 요청이 충족되지 않거나 최소한 캐시가 한계 이하로 떨어질 때까지 지연됨을 의미합니다. 대신 캐시 한계를 초과할 수는 있지만 EJB 컨테이너가 캐시를 정리하여 EJB 캐시 크기 이하로 유지하려고 합니다.
      캐시 한계를 초과하는 경우 다음과 비슷한 추적 지점을 볼 수 있습니다.

      [IBM i][AIX Solaris HP-UX Linux Windows]BackgroundLru <  EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053 Exit

      [z/OS] EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053

      Evicted = 문자열에 유의하십시오. 이러한 문자열이 나타나면 옵션 A 또는 B 캐싱에 구성된 Stateful 세션 Bean 또는 엔티티 Bean을 사용합니다. Evicted 오브젝트는 선택한 캐싱 옵션을 충분히 활용하지 못함을 나타냅니다. 첫 번째 단계는 EJB 캐시 크기를 늘리는 것입니다. 계속해서 애플리케이션을 실행했을 때 축출 빈도가 증가하면 이는 애플리케이션이 기존 Bean을 다시 사용하지 않고 EJB 캐시 소거 사이에서 캐시가 보유할 수 있는 수보다 더 많은 Bean에 액세스하거나 Bean을 더 많이 작성함을 의미합니다.
      엔티티 Bean에서 옵션 C 캐싱 사용을 고려하거나 Stateful 세션 Bean이 더 이상 필요하지 않으면 이를 제거하지 않을 것인지 애플리케이션을 검사하여 확인할 수 있습니다.
      참고: 옵션 C 캐싱에 구성된 엔티티 Bean은 트랜잭션 동안 캐시에 있는 유일한 항목이므로 전체 트랜잭션에서 캐시에 보유하고 있어야 합니다. 따라서 캐시 소거 중에는 축출되지 않지만 트랜잭션을 완료하면 캐시에서 제거됩니다. 또한 옵션 C 캐싱에서 Stateless 세션 Bean 또는 엔티티 Bean만(또는 둘 다) 사용하는 경우 EJB 캐시 정리 간격을 더 큰 숫자로 늘릴 수 있습니다. 정리 간격은 EJB 캐시 설정에서 설명한 대로 설정할 수 있습니다. Stateless 세션 Bean은 EJB 캐시에 없으며 옵션 C 캐싱을 사용하는 엔티티 Bean은 캐싱(LRU) 계획에서 절대로 축출되지 않으므로 실제로 자주 소거하지 않아도 됩니다. Stateless 세션 Bean 또는 옵션 C 캐싱만 사용하는 경우 표시된 추적 예제에는 "Evicted = 0"만 표시되어야 합니다.
    2. 추적 로그를 분석하십시오. 추적 문자열 Cache limit exceeded이 있는지 확인하십시오.
      • 이 문자열의 인스턴스는 둘 이상 찾을 수 있습니다. 이들 문자열을 모두 검사하여 EJB 캐시에서 가장 높은 Bean의 용량 값을 찾으십시오. 그리고 EJB 캐시 크기를 이 숫자의 110%로 재설정하십시오. EJB 캐시 크기를 설정하는 방법은 나중 단계에서 설명합니다.
      • 이 문자열의 인스턴스를 하나도 찾지 못할 수도 있습니다. 즉, EJB 캐시 용량을 초과하지 않았음을 의미합니다(최종 목표). 하지만 초기 분석에서 보지 못했다는 것은 캐시를 너무 크게 설정하여 불필요한 메모리를 낭비하고 있음을 의미할 수도 있습니다. 이런 경우에는 캐시 크기를 줄인 다음, 캐시 한계가 초과되지 않을 때까지 캐시를 최적 값으로 늘려서 캐시를 조정해야 합니다. EJB 캐시 크기를 설정하는 방법은 나중 단계에서 설명합니다.
      최종 목표는 자원을 낭비하지 않으면서 한계를 초과하지 않는 값으로 캐시 한계를 설정하는 것입니다. 제대로 설정하면 추적에 Cache limit not reached 메시지와 캐시 용량이 EJB 캐시 설정의 100%에 가깝지만, 이 값 이하인 비율만 나타나게 됩니다.
      참고: 캐시 크기를 기본값(2053) 이하인 값으로 설정하지 않는 것 좋습니다.
  6. 분석을 기초로 캐시 설정을 수정하십시오. 이를 수행하는 방법에 대한 정보는 EJB 캐시 설정을 참조하십시오.
  7. [IBM i][AIX Solaris HP-UX Linux Windows]서버를 중지하고 모든 로그를 삭제한 후 서버를 다시 시작하십시오.
  8. [z/OS]서버를 중지하고 다시 시작하십시오.
  9. 설정을 만족할 때까지 이전 단계를 반복하십시오.
  10. EJB 캐시 추적을 사용 불가능하게 하십시오. 적절히 캐시를 조정하여 추적을 제거하고 이전 로그를 제거한 후 서버를 다시 시작할 수 있습니다.

다음에 수행할 작업

분석 시 EJB 컨테이너 Perspective에서 최적으로 EJB 캐시를 설정할 수 있지만 WebSphere® Application Server Perspective에서는 최적이 아닐 수도 있습니다. 캐시 크기를 늘리면 히트 수가 증가하고 EJB 캐시 성능이 향상되지만 메모리 사용량이 증가합니다. 캐시에서 사용하는 메모리는 제품의 다른 영역에서는 사용할 수 없습니다. 따라서 전반적으로 성능이 떨어질 수 있습니다. 메모리가 큰 시스템의 경우 문제가 되지 않을 수 있지만, EJB 캐시를 적절히 조정하면 전반적으로 성능을 늘릴 수 있습니다. 그러나 캐시 구성 시 이러한 시스템 성능과 EJB 캐시 성능의 장단점을 모두 고려해야 합니다.


주제 유형을 표시하는 아이콘 태스크 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tejb_tunecash
파일 이름:tejb_tunecash.html