IBM WebSphere Application Server, Advanced Edition
조정 안내서
IBM WebSphere Application Server, Advanced Edition조정 안내서 |
|
관리 콘솔에서 이를 호출하려면 콘솔 > 마법사 > 성능 조정을 선택하십시오.
자세한 정보는 InfoCenter의 6.6.21을 참조하십시오.
동적 단편 캐싱은 응용프로그램 성능을 극적으로 개선하는 기술로, 동적 servlet 및 JSP 파일의 출력을 캐싱하는 기능입니다. Application Server의 JVM 내에서 작동하는 이 캐시는 servlet의 service() 메소드에 대한 호출을 가로채어 servlet을 재실행하기 보다는 캐시에서 해당 호출을 제공할 수 있는지 점검합니다. J2EE 응용프로그램에서는 읽기-쓰기 비율이 높아서 데이터가 약간 새로워질 수 있는 잠재성을 허용할 수 있으므로, 단편 캐싱은 서버 응답 시간, 처리량 및 확장성에 대해 극적인 이득을 얻을 수 있게 합니다.
Servlet이 실행되었으면(캐싱될 출력 생성), 그 출력을 포함하는 캐시 항목이 생성됩니다. 실행의 부수적인 효과(즉, 다른 servlet 또는 JSP 파일 호출)와 제한시간 및 항목 우선순위 정보를 포함하여 항목에 대한 메타 데이터도 생성됩니다. 고유 항목들은 각각의 servlet 호출마다 HttpServletRequest 오브젝트를 통해 생성되는 ID 문자열로 구별됩니다. 그 결과, servlet은 요청 매개변수에 따라 캐시되고, URI를 사용하여 servlet 또는 세션 정보를 호출합니다. JSP 파일은 WebSphere Application Server에 의해 servlet으로 컴파일되므로, JSP 및 servlet이 서로 바뀌어 사용됩니다(XML 파일 내에서 요소들을 선언할 경우를 제외하고).
이를 설정하는 방법:
자세한 정보는 InfoCenter의 4.5: 동적 단편 캐싱을 참조하십시오.
| 증상 | 추가 정보 |
| 처리량 및 응답 시간이 바람직하지 않습니다. | 프로세서 속도 |
|
AIX: 메모리 할당 오류 Solaris: 너무 많은 파일이 열려 있음 | AIX 파일 설명자(ulimit) 또는 Solaris 파일 설명자(ulimit) |
| Solaris: 서버가 최대 기간 동안 속도가 느려지며, 응답에 시간이 걸리고, 시스템 프로세스의 모든 활동과 함께 프로세서 이용률이 높게 남아 있으며, netstat에서 여러 개의 소켓이 CLOSE_WAIT 또는 FIN_WAIT_2 상태로 포트 80에 열려 있는 것으로 표시합니다. | Solaris tcp_close_wait_interval/tcp_time_wait_interval 및 Solaris tcp_fin_wait_2_flush_interval |
| Windows NT/2000: Netstat에서 너무 많은 소켓이 TIME_WAIT 상태에 있는 것으로 나타납니다. | Windows NT/2000 TcpTimedWaitDelay |
| HP-UX 11: 처리량이 바람직하지 않으며 Application Server 우선순위가 조정되지 않았습니다. | Application Server 프로세스의 운영 체제 우선순위 조정 |
| 로드 하에서, 클라이언트 요청이 시간 제한되거나 거부되어 웹 서버에 도착하지 못합니다. |
HP-UX 11의 경우 HP-UX 11 tcp_conn_request_max를 참조하십시오. IIS Windows NT/2000의 경우 ListenBackLog 매개변수를 참조하십시오. NT상의 IBM HTTP Server의 경우 ListenBackLog를 참조하십시오. |
| Windows NT/2000: 다른 벤더의 Application Server 설치 후 WebSphere Application Server 성능이 감소했습니다. | IIS 권한 등록 정보 |
| 자원 분석기의 최대화된 메트릭 퍼센트는 웹 컨테이너 스레드 풀이 너무 작음을 나타냅니다. | 웹 컨테이너 최대 ThreadsMax 연결 수 |
| Netstat에서 포트 9080에 대해 너무 많은 TIME_WAIT 상태의 소켓이 나타납니다. | 웹 컨테이너 전송 최대 Keep-Alive |
| 페이징 동안 너무 많은 디스크 입/출력(I/O)이 발생합니다. | 힙 크기 설정 |
| 자원 분석기의 데이터소스 연결 풀에 대한 메트릭에 사용된 퍼센트는 풀 크기가 너무 큼을 나타냅니다. | WebSphere 데이터소스 연결 풀 크기 |
| 자원 분석기의 준비된 명령문 캐시 버리기 메트릭에서 데이터소스 준비된 명령문 캐시 크기가 너무 작음을 나타냅니다. | 준비된 명령문 캐시 크기 |
| DB2가 로그 레코드를 쓰고 있기 때문에 너무 많은 디스크 입/출력(I/O)이 발생합니다. | DB2 MinCommit |
| 자원 분석기의 최대화된 메트릭 퍼센트에서 OBR(Object Request Broker) 스레드 풀이 너무 작음을 보여줍니다. | 대기열 및 엔터프라이즈 Bean |
| 자원 분석기의 JVMPI(Java Virtual Machine Profiler Interface)는 가비지 콜렉션에 너무 많은 시간이 소요될 때 지나친 오브젝트의 이용을 나타냅니다. | 지나친 오브젝트 이용 발견 |
| 자원 분석기의 사용된 메모리 메트릭은 메모리 누출을 보여주며 Java는 메모리 부족 예외를 표시합니다. | 메모리 누출 발견 |
| 처리량, 응답 시간 및 확장성이 바람직하지 않습니다. | 응용프로그램에서 허용하면 동적 단편 캐싱을 이용하십시오. |
성능 조정에 대해 사용 가능한 프로시저를 사용할 때 WebSphere Application Server에
광범위한 성능 향상이 이루어질 수 있습니다. 이 조정 안내서에서는 일반 권장사항 및
특정 조정 방법의 설명을 제공함으로써 어떤 식으로 조정이 작동하는가를
알려줍니다. 성능 조정을 향상시킬 수 있는 여러가지 요인 및 변수에
관한 힌트 및 팁 역시 사용 가능합니다.
해당 예 및 자원과 함께, 조정 안내서를 사용하여 조정 경험을 확장하십시오.
조정은 계속적인 학습 프로세스입니다.
결과는 이 안내서에서 제시된 것과 다를 수 있습니다.
편의를 위해 일부 프로시저는 다른 제품의 매개변수 설정에 대해 설명하고 있습니다. 제품들은 바뀔 수 있으므로 이러한 프로시저는 제안사항으로 간주하시기 바랍니다.
응용프로그램 조정 및 매개변수 조정의 두 가지 조정 유형이 있습니다.
응용프로그램 조정으로 간혹 최상의 조정 효과를 보는 경우가 있지만, 이 문서에서는 개별 성능 매개변수와 그 매개변수들 사이의 상호 의존성에 초점을 두고 있습니다.
WebSphere Application Server Development Best Practices for Performance and Scalability 백서는 응용프로그램 조정에 대해 설명합니다. 이 백서에서는 Servlet, JSP(Java Server Page) 파일, JDBC(Java Database Connectivity)를 포함하는 웹 응용프로그램과 엔터프라이즈 Bean을 포함하는 엔터프라이즈 응용프로그램 둘 다에 대한 최적의 개발 조건에 대해 설명합니다.
다음 테이블에서는 다양한 고성능 향상 조정 매개변수를
나열합니다.
다음 매개변수들은 기능적 문제점의 방지를 돕습니다.
| ListenBackLog 매개변수: 과도한 클라이언트 로드 하에서 IIS가 있는 Windows NT/2000를 실행 중인 경우에 적용합니다. |
| 전송 유형: Solaris에서 INET 소켓을 사용합니다(WebSphere Application Server의 기본값) |
| DB2에 대한 연결 수: DB2보다 많은 연결을 설정하는 경우 기본으로 설정됩니다. |
| 최대값 이상으로 스레드 할당 허용이 선택되었으며 너무 많은 스레드가 할당되어 시스템이 과부하되었습니다. |
| Linux에서 DB2에 TCP 소켓 사용: 로컬 데이터베이스의 경우 |
| WebSphere 데이터소스 연결 풀 크기: 엔티티 EJB와의 트랜잭션 처리에 필요한 추가 연결을 처리하고 교착 상태를 피하기에 충분한 연결 수를 가지도록 하십시오. |
WebSphere Application Server에는 엔드 투 엔드 e-business 응용프로그램의 사용자 요구사항을 지원하도록 균형있게 조정해야 하는 상호 관련된 구성요소 시리즈가 있습니다. 이러한 조정은 전반적인 시스템 안정성을 유지하면서 최대 처리량을 얻는데 도움이 됩니다.
WebSphere Application Server는 응용프로그램 서비스 플랫폼의 다양한 구성요소를 나타내는 상호연결된 대기열의 네트워크인 대기열 네트워크를 형성합니다. 이러한 대기열에는 네트워크, 웹 서버, 웹 컨테이너, EJB 컨테이너, 데이터소스, 그리고 사용자 정의 백엔드 시스템의 연결 관리자가 포함됩니다. 이 자원들 각각은 해당 자원을 사용하려고 대기 중인 요청의 대기열을 나타냅니다.
WebSphere 대기열은 로드에 종속적인 자원입니다. 요청의 평균 서비스 시간은 동시 클라이언트 수에 따라 다릅니다.
대기열 네트워크를 구성하는 대부분의 대기열은 닫힌 대기열입니다. 열린 대기열과는 반대로 닫힌 대기열은 대기열에 있는 최대 요청 수에 제한을 둡니다.
닫힌 대기열을 통해 시스템 자원을 확실하게 관리할 수 있습니다. 예를 들어, 웹 컨테이너의 최대 연결 수 설정은 웹 컨테이너 대기열의 크기를 제어합니다. 웹 컨테이너에서 실행 중인 평균 Servlet이 각 요청 중에 10MB의 오브젝트를 작성하는 경우, 최대 연결 수에 대한 값을 100으로 설정하면 웹 컨테이너가 소모하는 메모리가 약 1GB로 제한됩니다.
닫힌 대기열에서 요청은 두 가지 상태(즉, 활성 또는 대기 중) 중 하나일 수 있습니다. 활성 요청은 작업을 수행하거나 다운스트림 대기열의 응답을 기다리는 중입니다. 예를 들어, 웹 서버의 활성 요청이 작업(정적 HTML 검색과 같은)을 수행하거나 웹 컨테이너에서 요청이 완료되기를 기다리고 있습니다. 대기 중 상태의 요청은 활성화 되기를 기다리는 중입니다. 요청은 활성 요청 중 하나가 대기열을 떠날 때까지 대기 중 상태로 남게 됩니다.
WebSphere Application Server가 지원하는 모든 웹 서버는 WebSphere Application Server 데이터 소스와 마찬가지로 닫힌 대기열입니다. 웹 컨테이너는 열린 대기열이나 닫힌 대기열로 구성할 수 있습니다. 일반적으로, 닫힌 대기열로 구성하는 것이 가장 좋습니다. EJB 컨테이너는 열린 대기열입니다. 풀에 사용 가능한 스레드가 없으면, 요청 지속 기간 동안 새 스레드가 작성됩니다.
Servlet이 엔터프라이즈 Bean을 호출하는 중이면 웹 컨테이너는 자체 제한을 수반하므로 총 동시 요청 수를 EJB 컨테이너로 제한합니다. 이는 실행 Servlet 스레드로부터 엔터프라이즈 Bean을 호출하는 경우에만 적용됩니다. 사용자가 자신의 스레드를 작성하고 EJB 컨테이너에 요청을 하는 것을 막을 수 없습니다. 이것이 Servlet이 자기 소유의 작업 스레드를 작성하는 것이 바람직하지 못한 이유 중 하나입니다.
다음은 여러가지 대기열 설정을 간략히 설명한 것입니다.
다음 절에서는 WebSphere Application Server 대기열 구성 방법을 간략히 설명합니다. 자원을 이동시키거나(예를 들어, 데이터베이스 서버를 다른 시스템으로 이동) 보다 강력한 자원을 제공함으로써(예를 들어, 더 많은 메모리와 함께 더 빨라진 CPU 세트) 시스템의 동적사항이 변경될 수 있으며, 이에 따라 조정 매개변수가 변경될 수 있습니다. 따라서, 생산 환경의 특정 구성에 따라 조정 매개변수를 조정하십시오.
조정의 첫 번째 규칙은 WebSphere Application Server 대기열의 요청 수를 최소화하는 것입니다. 일반적으로 요청이 WebSphere Application Server에서 대기하는 것보다는 네트워크(웹 서버의 앞)에서 대기하는 것이 더 좋습니다. 이러한 구성의 결과, 처리할 준비가 되어 있는 요청만 대기열 네트워크로 허용됩니다. 이러한 구성을 하려면, 대기열을 최고로 업스트림하도록(클라이언트에 가장 가깝도록) 지정하여 약간 더 커지도록 하고 대기열을 더 다운스트림하도록(클라이언트에서 멀어지도록) 지정하여 점차적으로 작아지도록 하십시오.
이 대기열 네트워크의 대기열들은 작업이 다운스트림으로 흐르면서 점차 작아집니다. 200개의 클라이언트가 웹 서버에 도착하는 경우, 웹 서버는 75개의 동시 클라이언트를 처리하도록 설정되어 있으므로 125개의 요청은 네트워크 대기열에 남게 됩니다. 75개의 요청이 웹 서버에서 웹 컨테이너로 전달되면 25개의 요청만 웹 서버의 대기열에 남게 되고 나머지 50개의 요청은 웹 컨테이너에 의해 처리됩니다. 이 프로세스는 마지막 25명의 사용자가 최종 목적지인 데이터베이스 서버에 도달할 때까지 데이터소스를 통해 진행됩니다. 각 포인트 업스트림에는 구성요소를 입력하려고 대기 중인 일부 작업이 있으므로 이 시스템에는 작업이 도달하기를 기다려야 하는 구성요소가 없습니다. WebSphere Application Server 밖에서는 네트워크 내에서 많은 요청이 대기 중입니다. 그러면 어떤 구성요소에도 과부하가 걸리지 않으므로 안정성이 추가됩니다. IBM의 Network Dispatcher와 같은 라우팅 소프트웨어를 사용하여 대기 중인 사용자를 WebSphere Application Server 클러스터의 다른 서버로 보낼 수 있습니다.
전체 생산 응용프로그램 경향을 나타내는 테스트 사례를 사용하거나(예를 들어, 의미있는 모든 코드 경로를 실습함) 생산 응용프로그램 자체를 사용하여 일련의 실험을 실행함으로써 시스템 성능이 최대화된 시기(포화점)를 판별하십시오. 이러한 검사는 대부분의 병목 현상이 응용프로그램에서 제거된 후에 시행하십시오. 이러한 검사의 일반적인 목적은 100%에 가까운 CPU 이용률을 이끌어 내기 위한 것입니다.
큰 대기열을 사용하여 초기 기준선 실험을 시작하십시오. 이로써 시스템의 최대 동시성이 가능해집니다. 예를 들어, 대기열 네트워크의 각 서버(웹 서버, 웹 컨테이너 및 데이터소스)에서 대기열 크기를 100으로 하여 첫 번째 실험을 시작하십시오.
다음으로, 각 실험 후 동시 사용자 로드를 증가시켜 처리량 곡선을 그리기 위한 일련의 실험을 시작하십시오. 예를 들어 사용자 1명, 사용자 2명, 사용자 5, 10, 25, 50, 100, 150 및 200명을 사용하여 실험을 수행하십시오. 각 실행 후에 처리량(초당 요청 수)과 응답 시간(요청당 초 수)을 기록하십시오.
기준선 실험 결과 곡선은 다음 그림에 표시된 일반적인 처리량 곡선과 유사해야 합니다.
WebSphere Application Server의 처리량은 시스템 전체에 나타나는 동시 요청 수의 함수입니다. 섹션 A, 부하가 적은 구역은 동시 사용자 요청 수가 증가할 때 처리량이 요청 수에 거의 선형적으로 증가됨을 보여줍니다. 이는 부하가 적게 걸리는 경우 동시 요청이 WebSphere Application Server 시스템 대기열 내에서 거의 혼잡을 느끼지 않는다는 사실을 반영합니다. 몇몇 지점에서 혼잡이 시작되고 WebSphere Application Server 시스템에서 일부 병목 현상으로 판별되는 것처럼 최대 처리량 값을 나타내는 포화점에 이를 때까지 훨씬 더 낮은 비율로 처리량이 증가됩니다. 가장 관리 가능한 유형의 병목 현상은 WebSphere Application Server 시스템의 CPU가 포화 상태가 되는 경우입니다. 이는 추가 CPU나 더 강력한 CPU를 추가함으로써 CPU 병목 현상을 쉽게 정정할 수 있기 때문에 바람직합니다.
섹션 B, 과부화 구역에서는 동시 클라이언트 로드가 증가됨에 따라 처리량이 비교적 일관되게 남아 있습니다. 그러나 응답 시간은 사용자 로드에 비례하여 증가합니다. 즉 과부하 구역에서 사용자 로드가 두 배가 되면 응답 시간도 두 배가 됩니다. 섹션 C, 버클 구역으로 표시되는 일부 지점에서는 시스템 구성요소 중 하나가 고갈됩니다. 이제 처리량이 줄어들기 시작합니다. 예를 들어, 웹 서버의 네트워크 연결이 네트워크 어댑터 한계를 모두 소모하거나 파일 처리에 대한 운영 체제 한계를 초과하는 경우 시스템이 버클 구역에 들어갈 수 있습니다.
시스템 CPU를 100%에 가깝게 구동함으로써 포화점에 도달하면 다음 단계로 이동하십시오. CPU가 100% 구동되지 않으면 병목 현상이 응용프로그램에 의해 악화됩니다. 예를 들어, 응용프로그램이 Java 오브젝트를 과도하게 작성하여 Java에서 가비지 콜렉션 병목 현상을 일으킬 수 있습니다.
응용프로그램 병목 현상을 관리하는데에는 병목 현상 제거 또는 병목 현상 복제의 두 가지 방법이 있습니다. 가장 훌륭한 병목 현상 관리 방법은 이를 제거하는 것입니다. Java 기반의 응용프로그램 프로파일러를 사용하여 전반적인 오브젝트 활용도를 검사하십시오. PTDV(Performance Trace Data Visualizer), JProbe 및 Jinsight와 같은 프로파일러를 사용할 수 있습니다.
처리량 포화점에서의 동시 사용자 수는 응용프로그램의 최대 동시성을 나타냅니다. 예를 들어 응용프로그램이 사용자가 50명일 때 WebSphere Application Server를 포화상태로 만드는 경우 48명의 사용자가 최상의 처리량과 응답 시간을 제공함을 알 수 있습니다. 이 값을 최대 응용프로그램 동시성 값이라고 합니다. 응용프로그램 동시성은 WebSphere Application Server 시스템 대기열을 조정하기 위한 기준으로 사용할 값이 됩니다. 대부분의 사용자가 네트워크에서 대기하는 것이 바람직하므로 클라이언트로부터 다운스트림으로 점점 이동하면서 대기열 크기를 줄이십시오. 예를 들어, 최대 응용프로그램 동시성 값이 48인 경우, 웹 서버 75, 웹 컨테이너 50, 데이터소스 45 값을 갖는 시스템 대기열로 시작하십시오. 최상의 설정을 찾기 위해 이 값을 약간씩 높게 그리고 낮게 조정하여 일련의 추가 실험을 수행하십시오.
자원 분석기를 사용하여 servlet 엔진 스레드 풀 동시 활성 스레드 메트릭을 통해 동시 사용자 수를 결정할 수 있습니다.
성능 실험에서, 웹 컨테이너 전송 최대 Keep-Alive가 웹 컨테이너 스레드와 일치하도록 조정될 때 처리량이 10-15% 증가되었습니다.
많은 경우에 하나의 대기열을 통해 전달되는 요청 부분만 다음 대기열 다운스트림에 들어갑니다. 정적 페이지가 많은 사이트에서는 많은 요청이 웹 서버에서 이행되지만 웹 컨테이너에는 전달되지 않습니다. 그러한 상황에서, 웹 서버 대기열은 웹 컨테이너 대기열보다 상당히 커질 수 있습니다. 이전 섹션에서, 웹 서버 대기열을 최대 응용프로그램 동시성 값에 가깝게 설정하지 않고 75로 설정했습니다. 서로 다른 구성요소들이 서로 다른 실행 시간을 가질 때에는 비슷한 조정을 수행해야 합니다.
예를 들어, 복잡한 Servlet에서 그 시간의 90%를 소모하고 10%만 짧은 JDBC 조회에 사용하는 응용프로그램에서는 평균적으로 Servlet의 10%만 데이터베이스 연결을 사용하고 있으므로, 데이터베이스 연결 대기열은 웹 컨테이너 대기열보다 상당히 작아질 수 있습니다. 역으로, 대부분의 Servlet 실행 시간이 데이터베이스의 복잡한 조회에 사용되는 경우, 웹 컨테이너와 데이터소스 둘 다의 대기열 값 증가를 고려하십시오. 항상 WebSphere Application Server와 데이터베이스 서버 둘 다에 대한 CPU 및 메모리 활용도를 모니터하여 CPU 또는 메모리가 포화상태가 되지 않도록 해야 합니다.
엔터프라이즈 Bean에 대한 메소드 호출은 메소드 호출을 작성하는 클라이언트가 원격인 경우에만 대기열에 들어갑니다. 예를 들어, EJB 클라이언트가 엔터프라이즈 Bean과 다른 별도의 JVM(다른 주소 공간)에서 실행 중인 경우입니다. 반대로, EJB 클라이언트(Servlet 또는 다른 엔터프라이즈 Bean)가 같은 JVM에 설치되어 있으면 EJB 메소드는 EJB 클라이언트와 동일한 실행 스레드에서 실행되고 대기열에 들어가지 않습니다.
원격 엔터프라이즈 Bean은 RMI/IIOP 프로토콜을 사용하여 통신합니다. RMI/IIOP를 거쳐 초기화되는 메소드 호출은 서버측 ORB에 의해 처리됩니다. 스레드 풀은 수신되는 요청에 대한 대기열로 작동합니다. 그러나 원격 메소드 요청이 발행되고 스레드 풀에 사용 가능한 스레드가 없으면 새로운 스레드가 작성됩니다. 메소드 요청이 완료되면 스레드는 파기됩니다. 따라서 원격 메소드 요청을 처리하는데 ORB가 사용되면, EJB 컨테이너의 스레드 사용이 언바운드되므로 EJB 컨테이너는 열린 대기열입니다. 다음 그림은 엔터프라이즈 Bean의 두 가지 대기열 옵션을 보여줍니다.
스레드 풀을 구성할 때 EJB 클라이언트의 호출 패턴을 이해하는 것이 중요합니다. Servlet이 원격 엔터프라이즈 Bean에 대해 소수의 호출을 수행하고 있으며 각 메소드 호출이 비교적 빠른 경우, ORB 스레드 풀의 스레드 수를 웹 컨테이너 스레드 풀 크기 값보다 작게 설정하십시오.
자원 분석기에서 구성된 모든 스레드가 얼마만큼의 시간을 사용 중인지를 판별하는데 사용되는 최대화된 퍼센트라는 메트릭을 보여줍니다. 이 값이 지속적으로 두 자리 수인 경우, ORB가 병목 현상일 수 있으며 스레드 수를 증가시켜야 합니다.
ORB 스레드 풀 값의 증가 정도는 엔터프라이즈 Bean을 호출하는 동시 Servlet(즉, 클라이언트) 수와 각 메소드 호출의 지속 기간에 대한 함수입니다. 메소드 호출이 긴 쪽에 있는 경우, 이는 원격 메소드 호출에 대한 인터리브가 적기 때문이니 ORB 스레드 풀 크기를 웹 컨테이너 크기와 같게 만드십시오. Servlet이 ORB에 대해 수명이 짧거나 빠른 호출만을 할 경우, ORB 스레드 풀이 작아질 수 있습니다. Servlet은 잠재적으로 동일한 ORB 스레드를 재사용할 수 있습니다. 이 경우, ORB 스레드 풀은 작아 질 수 있습니다(웹 컨테이너의 스레드 풀 크기 설정의 반 정도). 응용프로그램이 많은 시간을 ORB에 소비할 경우, 웹 컨테이너와 ORB 사이의 보다 대등한 관계를 구성하십시오.
Application Server의 복제 성능은 확장 가능한 생산 환경을 구성하는 데 있어 중요한 자산이 될 수 있습니다. 이는 특히 응용프로그램이 SMP(Symetric Multiprocessing) 서버의 완전한 CPU 이용을 막는 병목 현상이 발생할 경우에 더욱 그렇습니다. 클러스터 구성에서 WebSphere Application Server 시스템 대기열을 조정할 경우, 서버를 클러스터에 추가하면 서버 다운스트림의 로드가 두 배가 됨을 기억하십시오.
두 웹 컨테이너 복제본은 웹 서버와 데이터소스 사이에 위치합니다. 웹 서버, Servlet 엔진 및 데이터소스(데이터베이스가 아님) 모두가 단일 SMP 서버에서 실행되고 있다고 가정합니다. 이러한 제한조건에 따라 다음 대기열 고려사항을 작성해야 합니다.
SSL 연결이 이루어지면 SSL 데이터 교환이 발생합니다. 연결이 이루어진 후 SSL은 각 읽기 쓰기에 대한 벌크 암호화 및 암호 해독을 수행합니다. SSL 데이터 교환의 성능 비용은 벌크 암호화 및 암호 해독의 비용보다 큽니다.
SSL 성능을 향상시키기 위해서는 개별 SSL 연결 및 데이터 교환 수를 줄여야 합니다.
연결 수를 줄이면 TCP 연결을 통한 비 보안 통신뿐 아니라 SSL 연결을 통한 보안 통신 성능이 증가됩니다. 개별 SSL 연결 수를 줄이는 한 방법은 HTTP 1.1을 지원하는 브라우저를 사용하는 것입니다. HTTP 1.1로 업그레이드할 수 없는 일부 사용자들에게는 개별 SSL 연결 수를 줄이는 것이 불가능할 수도 있습니다.
두 WebSphere Application Server 구성요소 사이에서 연결 수(TCP와 SSL 둘 다)를 줄이는 것이 보다 보편적입니다. 다음과 같은 지침이 Application Server의 HTTP 전송이 틀림없이 구성되어 웹 서버 플러그인이 Application Server에 대한 새 연결을 반복해서 다시 열지 않도록 돕습니다.
현재 WebSphere Application Server에서 지원하는 하드웨어 가속기는 SSL 데이터 교환 성능만 증가시키고, 벌크 암호화/암호 해독은 증가시키지 않습니다. 웹 서버 연결의 수명이 짧으므로 가속기는 보통 웹 서버에게만 혜택을 줍니다. WebSphere Application Server의 모든 다른 SSL 연결의 수명은 깁니다. 이러한 연결들은 SSL 데이터 교환만을 가속화시키는 하드웨어 장치로부터 혜택을 누리지 못합니다.
cipher suite의 성능은 소프트웨어 및 하드웨어에 따라 서로 다릅니다. cipher suite가 소프트웨어에서 잘 수행되기 때문에 하드웨어에서도 더 잘 수행된다는 것을 의미하지는 않습니다. 일부 알고리즘은 보통 하드웨어에서 비효율적입니다(예를 들어, DES 및 3DES). 그러나 특수화된 하드웨어는 이러한 동일한 알고리즘의 효과적인 구현을 제공할 수 있습니다.
벌크 암호화 및 암호 해독의 성능은 개별 SSL 연결에 사용되는 cipher suite에 의해 영향을 받습니다. 데이터를 계산하는 테스트 소프트웨어는 클라이언트와 서버 소프트웨어 둘 다에 IBM JSSE를 사용했으며, crypto 하드웨어 지원을 사용하지 않았습니다. 테스트는 연결을 형성하는 시간은 포함하지 않았으나, 형성된 연결을 통해 데이터를 전송하는 시간은 포함하고 있습니다. 그러므로, 데이터는 오래 실행 중인 연결에 대한 다양한 cipher suite의 상대적인 SSL 성능을 나타냅니다.
연결을 형성하기 전에 클라이언트가 각 테스트 케이스에 대해 하나의 cipher suite를 사용 가능하게 했습니다. 연결이 형성된 후 클라이언트는 서버에 정수를 쓰기 위해 얼마나 오래 걸렸는지와 서버가 지정된 바이트 수를 다시 클라이언트에 쓰는데 얼마나 오래 걸렸는지 시간을 측정합니다. 다양한 데이터 양은 cipher suite의 상대적인 성능에 무시해도 좋을 만큼의 작은 영향을 미칩니다. 다음 도표는 각 cipher suite의 성능을 보여줍니다.
위의 데이터 분석은 다음을 나타냅니다.
점검 목록에는 다음과 같은 설정이 포함됩니다.
확약 옵션 A는 트랜잭션 범주 밖에서 데이터베이스 데이터를 캐시함으로써 최대 엔터프라이즈 Bean 성능을 제공합니다. 일반적으로, 확약 옵션 A는 EJB 컨테이너가 해당 데이터베이스를 독점 액세스하는 경우에만 적용 가능합니다. 그렇지 않은 경우에는 데이터 무결성이 손상됩니다. 확약 옵션 B는 엔티티 EJB 오브젝트 인스턴스의 보다 적극적인 캐싱을 제공하여, 그 결과 확약 옵션 C보다 더 향상된 성능을 주지만 더 많은 메모리를 사용하기도 합니다. 확약 옵션 C는 실제로 엔티티 EJB에 대해 가장 일반적인 구성입니다.
Activate At 및 Load At 등록 정보의 설정은 어느 확약 옵션이 사용될지를 결정합니다.
분리 레벨 역시 성능에 중요한 역할을 합니다. 분리 레벨이 높을 수록 데이터 액세스 동시성을 줄이면서 행 잠금 및 데이터베이스 오버헤드를 증가시킴으로써 성능이 저하됩니다. 여러가지 데이터베이스가 분리 설정에 관하여 서로 다른 작동을 제공합니다. 일반적으로, Repeatable Read가 DB2 데이터베이스에 대해 적절한 설정입니다. Read Committed는 일반적으로 Oracle에 대해 사용됩니다. Oracle은 Repeatable Read를 지원하지 않으며 이 설정을 가장 높은 분리 레벨 Serializable로 변환합니다.
분리 레벨은 Bean 또는 메소드 레벨에서 지정될 수 있습니다. 그러므로, 여러가지 메소드에 대해 서로 다른 분리 설정을 구성할 수 있습니다. 이는 일부 메소드가 다른 메소드보다 더 높은 분리를 필요로 할 때에 이로우며, 무결성 요구사항을 유지하면서 최대의 성능을 성취하기 위해 사용할 수 있습니다. 그러나, 단일 엔터프라이즈 Bean 트랜잭션 내의 메소드 호출들 간의 분리는 변경할 수 없습니다. 그런 경우에는 런타임 예외가 발생할 것입니다.
Repeatable Read
이 레벨은 손상 읽기 및 비반복가능 읽기를 방지하지만, 환영 읽기는 허용합니다.
Read Committed
이 레벨은 손상 읽기를 방지하지만, 비반복가능 읽기 및 환영 읽기는 허용합니다.
Read Uncommitted
이 레벨은 손상 읽기, 비반복가능 읽기 및 환영 읽기를 허용합니다.
컨테이너는 다음과 같은 트랜잭션 분리 레벨 속성을 사용합니다.
클라이언트가 트랜잭션 문맥 외부로부터 Bean을 호출하면 컨테이너는 지원 안됨 트랜잭션 속성이 설정된 것과 똑같은 방식으로 작동합니다. 클라이언트는 트랜잭션 문맥없이 메소드를 호출해야 합니다.
트랜잭션 의무
이 사용 가능 값은 컨테이너가 항상 클라이언트와 연관된 트랜잭션 문맥 내에서
Bean 메소드를 호출하도록 지시합니다.
클라이언트가 트랜잭션 문맥없이 Bean 메소드를 호출하려 시도하면, 컨테이너가
클라이언트에 javax.jts.TransactionRequiredException 예외를 내보냅니다.
트랜잭션 문맥은 엔터프라이즈 Bean 메소드에 의해 액세스되는 엔터프라이즈 Bean
오브젝트나 자원에 전달됩니다.
이 엔티티 Bean에 액세스하는 엔터프라이즈 Bean 클라이언트는 기존 트랜잭션 내에서 그렇게 해야 합니다. 다른 엔터프라이즈 Bean의 경우, 엔터프라이즈 Bean이나 Bean 메소드가 Bean 관리 값을 구현하거나 트랜잭션 필요됨 또는 새 트랜잭션 필요 값을 사용해야 합니다. 비 엔터프라이즈 Bean EJB 클라이언트의 경우, javax.transaction.UserTransaction 인터페이스를 사용하여 클라이언트가 트랜잭션을 호출해야 합니다.
새 트랜잭션 필요
이 사용 가능 값은 클라이언트가 트랜잭션 문맥 내에서 또는 외부에서 메소드를 호출하는
지에 관계없이 컨테이너는 항상 새 트랜잭션 문맥내에서 Bean 메소드를 호출하도록
지시합니다.
트랜잭션 문맥은 이 Bean 메소드에 의해 사용되는 엔터프라이즈 Bean
오브젝트나 자원에 전달됩니다.
트랜잭션 필요됨
이 사용 가능 값은 컨테이너가 트랜잭션 문맥 내에서 Bean 메소드를 호출하도록
지시합니다.
클라이언트가 트랜잭션 문맥 내에서 Bean 메소드를 호출하면
컨테이너는 클라이언트 트랜잭션 문맥 내에서 Bean 메소드를 호출합니다.
클라이언트가 트랜잭션 문맥 외부에서 Bean 메소드를 호출하는 경우에는
컨테이너가 새 트랜잭션 문맥을 작성하고 그 문맥 내에서부터 Bean 메소드를 호출합니다.
트랜잭션 문맥은 이 Bean 메소드에 의해 사용되는 엔터프라이즈 Bean
오브젝트나 자원에 전달됩니다.
트랜잭션 지원
이 사용 가능 값은 클라이언트가 트랜잭션 내에서 메소드를 호출하는
경우 컨테이너가 트랜잭션 문맥 내에서 Bean 메소드를 호출하도록
지시합니다.
클라이언트가 트랜잭션 문맥없이 Bean 메소드를 호출하면
컨테이너는 트랜잭션 문맥없이 Bean 메소드를 호출합니다.
트랜잭션 문맥은 이 Bean 메소드에 의해 사용되는 엔터프라이즈 Bean
오브젝트나 자원에 전달됩니다.
트랜잭션 지원 안됨
이 사용 가능 값은 컨테이너가 트랜잭션 문맥없이 Bean 메소드를
호출하도록 지시합니다.
클라이언트가 트랜잭션 문맥 내에서부터 Bean 메소드를 호출하면
컨테이너가 엔터프라이즈 Bean 인스턴스에 대한 메소드를 호출하기 전에
트랜잭션과 현재 스레드 사이의 관계를 일시중단합니다.
그런 후 메소드 호출이 리턴할 때 컨테이너가 일시중단된 연관을 재개합니다. 일시중단된
트랜잭션 문맥은 이 Bean 메소드에 의해 사용되는 엔터프라이즈 Bean
오브젝트나 자원에 전달되지 않습니다.
Bean 관리
이 값은 컨테이너에게 Bean 클래스가 트랜잭션 경계를 직접 처리함을
알립니다. 이 등록 정보는 개별 Bean 메소드가 아니라 세션 Bean에 대해서만 지정될 수 있습니다.
Java 가비지 콜렉션 조사를 통해 응용프로그램이 메모리를 이용하는 정도를 알아볼 수 있습니다. 가비지 콜렉션은 Java의 강점입니다. Java 응용프로그램은 응용프로그램 작성자의 메모리 관리 부담을 덜어 줌으로써 가비지 콜렉션을 제공하지 않는 언어로 작성된 응용프로그램보다 더 견고합니다. 응용프로그램이 오브젝트를 남용하지 않는한 이러한 강점은 유지됩니다. 가비지 콜렉션의 경우 제대로 작동하는 응용프로그램의 총 실행 시간 중 5-20%를 소모하는 것이 정상입니다. 관리하지 않으면, 가비지 콜렉션은 특히 SMP 서버 시스템에서 실행 중일 때 응용프로그램의 가장 큰 병목 현상 중 하나가 될 수 있습니다.
응용프로그램의 성능 정도를 평가하려면 가비지 콜렉션을 사용하십시오. 고정된 워크로드 실행 중에 가비지 콜렉션을 모니터하여 응용프로그램이 오브젝트를 과도하게 활용 중인지 여부를 알아볼 수 있습니다. 가비지 콜렉션을 사용하여 메모리 누출이 있는지 확인할 수도 있습니다.
응용프로그램의 성능 정도를 평가하려면 자원 분석기에서 가비지 콜렉션과 힙 통계를 사용하십시오. 가비지 콜렉션을 모니터함으로써 메모리 누출 및 오브젝트의 과도 사용을 발견할 수 있습니다.
이러한 유형의 조사를 하려면 최대 및 최소 힙 크기를 같은 값으로 설정해야 합니다. 생산 사용율이 거의 일치하는(사용자 오류 및 모든 것에 대해) 반복되는 대표적 워크로드를 선택하십시오. 응용프로그램 상태가 안정될 때까지 응용프로그램이 몇 분동안 실행되도록 하는 것도 중요합니다.
의미있는 통계를 보장하기 위해 응용프로그램의 상태가 고정될 때까지 고정된 워크로드를 실행하십시오. 대개 수 분이 소요됩니다.응용프로그램이 오브젝트를 지나치게 사용하고 있는지 확인하려면, 자원 분석기에서 JVMPI 프로파일러에 대한 카운터를 살펴보십시오. 가비지 콜렉션 호출 사이의 평균 시간은 단일 가비지 콜렉션 평균 지속 기간의 5 - 6배여야 합니다. 그렇지 않으면, 응용프로그램은 시간의 15% 이상을 가비지 콜렉션에 소비하고 있는 것입니다. 또한, 해제, 할당 및 이동한 오브젝트 수를 살펴보십시오.
정보에서 가비지 콜렉션 병목 현상이 나타나면, 두 가지 방식으로 그 병목 현상을 해결할 수 있습니다. 비용상 가장 효율적인 방식은 응용프로그램이 오브젝트 캐시 및 풀을 구현하도록 최적화하는 것입니다. 대상으로 할 오브젝트를 판별하려면 Java 프로파일러를 사용하십시오. 응용프로그램을 최적화할 수 없으면, 메모리, 프로세서 및 복제본을 추가하는 것도 도움이 될 수 있습니다. 추가 메모리는 각 복제본이 적절한 힙 크기를 유지할 수 있게 해줍니다. 추가 프로세서는 복제본이 병렬로 실행될 수 있도록 합니다.
Java에서의 메모리 누출은 가비지 콜렉션 병목 현상을 일으키는 위험한 요소입니다. 메모리 누출은 궁극적으로 시스템 불안정을 야기시키기 때문에 지나친 메모리 활용보다 더 좋지 않습니다. 시간이 지나면서 최종적으로 힙이 고갈되고 치명적인 메모리 부족 예외로 인해 Java가 실패할 때까지 가비지 콜렉션이 더 자주 발생하게 됩니다. 메모리 누출은 불필요한 오브젝트가 삭제되지 않는 참조사항을 수반할 경우에 발생합니다. 이는 대개 해시테이블과 같은 콜렉션 클래스에서 발생하는데, 이러한 테이블 자체는 실제 참조사항이 삭제된 경우에도 항상 오브젝트에 대한 참조를 수반하기 때문입니다.
응용프로그램이 생산 환경에서 전개된 후 즉시 손상되는 것이 일반적인 불평입니다. 높은 워크로드가 종종 원인일 수 있습니다. 이는 특히 높은 워크로드가 누출 확대를 가속화시키고 메모리 할당 장애가 발생하는 누출 응용프로그램의 경우에 해당됩니다.
메모리 누출 테스트는 숫자를 확대시키는 것과 관계가 있습니다. 메모리 누출은 가비지 콜렉션이 될 수 없는 바이트 또는 킬로바이트의 양으로 측정됩니다. 다루기 어려운 타스크는 이 양을 유용하며 사용할 수 없는 메모리의 예상 크기와 구별하는 것입니다. 숫자를 확대시켜 격차를 더 크게하고 불일치를 쉽게 식별할 수 있게 하면 이 타스크를 보다 쉽게 할 수 있습니다. 다음은 메모리 누출에 관한 중요한 결론의 목록입니다.
시스템 레벨이나 모듈 레벨에서 반복적 테스트를 사용할 수 있습니다. 모듈 테스트의 장점은 제어를 잘 할 수 있다는 것입니다. 모듈 내에서 발생하는 모든 것이 개인용으로 보존되고 메모리 사용율을 포함하여 외부 역효과를 만들어 내지 않도록 모듈이 설계될 때, 메모리 누출에 대한 테스트가 훨씬 더 쉬울 수 있습니다. 먼저, 모듈을 실행하기 전에 메모리 사용율이 기록된 후 고정된 테스트 케이스 집합이 반복적으로 실행됩니다. 테스트 실행 종료 시, 메모리 사용율이 상당히 변경된 경우 현재 메모리 사용율은 반복적으로 이전에 기록되어 점검된 것입니다. 실제 메모리 사용율 기록 시 가비지 콜렉션을 강제 실행시켜야 한다는 것을 기억하십시오. 이를 위해서는 가비지 콜렉션이 발생되게 하고 싶은 모듈에 System.gc()를 삽입하거나, 프로파일링 도구를 사용하여 이 이벤트가 강제로 발생되게 하십시오.
메모리 누출 테스트에 어느 테스트 케이스를 사용할지 선택할 때 다음을 고려하십시오.
자원 분석기는 메모리 누출이 있는지 판별하는데 도움이 됩니다. 최상의 결과를 얻기 위해서는 지속 기간을 증가시켜 실험을 반복해야 합니다(예: 1000, 2000 및 4000 페이지 요청). 사용되는 메모리의 자원 분석기 그래프에는 톱니 모양이 있어야 합니다. 그래프에서의 각 낙하는 가비지 콜렉션에 해당됩니다. 다음 중 하나가 발생하면 메모리 누출이 있습니다.
과도한 워크로드 동안 힙 소모가 가능성 있는 누출을 나타내면(Application Server가 지속적으로 100% CPU 사용율에 근접), 나중의 더 미약하거나 거의 유휴에 가까운 워크로드 동안 힙이 복구하는 것처럼 나타나며, 이는 힙 단편화의 표시입니다. 힙 단편화는 JVM이 가비지 콜렉션 주기 동안 메모리 할당 요청을 만족시키기에 충분한 오브젝트를 사용 가능하게 할 수 있으나, 힙에 있는 작은 사용 가능 메모리 영역들을 보다 큰 연속된 공간으로 밀집시킬 시간이 없을 때에 발생할 수 있습니다.
작은 오브젝트(512 바이트 미만)들이 사용 가능해 질 때 또 다른 형태의 힙 단편화가 발생합니다. 오브젝트는 사용 가능해 지나, 기억장치가 복구되지 않아 그 결과 메모리 단편화가 생깁니다.
JVM 고급 설정 명령행 인수에서 -Xcompactgc 플래그를 켜서 힙 단편화를 피할 수 있습니다. -Xcompactgc는 약간의 성능 저하로 각 가비지 콜렉션 주기가 단편화를 없애도록 보장합니다.
Java 힙 매개변수는 가비지 콜렉션의 작동에도 영향을 줄 수 있습니다. 힙 크기를 증가시키면 더 많은 오브젝트를 작성할 수 있습니다. 큰 힙을 채우려면 더 많은 시간이 소요되므로, 응용프로그램은 가비지 콜렉션이 발생하기 전에 더 오래 실행됩니다. 그러나 힙이 클수록 압축 시간이 더 길어집니다. 또한 가비지 콜렉션에도 더 많은 시간이 소요됩니다.
위의 그림은 각각이 다양한 Java 힙 설정을 사용하여 고정된 워크로드를 실행하는 세 개의 CPU 프로파일을 나타냅니다. 중간 프로파일에서, 설정은 초기 및 최대 힙 크기이거나 128MB입니다. 네 개의 가비지 콜렉션이 있습니다. 가비지 콜렉션의 총 시간은 총 실행의 약 15%입니다. 맨 위 프로파일에서 힙 매개변수를 256MB로 두 배 설정하면 가비지 콜렉션 사이의 작업 시간이 증가됩니다. 세 개의 가비지 콜렉션만 있지만, 각 가비지 콜렉션의 길이도 증가합니다. 세 번째 프로파일에서 힙 크기는 64MB으로 줄어들고 역효과가 나타납니다. 더 작은 힙을 사용하면 가비지 콜렉션 사이의 시간과 각 가비지 콜렉션의 시간이 더 짧아집니다. 세 가지 구성 모두 가비지 콜렉션의 총 시간은 약 15%입니다. 이는 Java 힙과, 오브젝트 이용에 대한 힙의 관계에 관한 중요한 개념을 보여줍니다. Java 응용프로그램에는 항상 가비지 콜렉션에 대한 비용이 존재합니다.
다양한 Java 힙 설정을 사용하여 일련의 테스트 실험을 실행하십시오. 예를 들어, 128M, 192M, 256M 및 320M를 사용하여 실험을 실행하십시오. 각 실험마다 총 메모리 사용을 모니터하십시오. 힙을 너무 크게 확장하면 페이징이 발생할 수 있습니다(vmstat 명령이나 Windows NT/2000 성능 모니터를 사용하여 페이징을 점검하십시오). 페이징이 발생하면, 힙의 크기를 줄이거나 더 많은 메모리를 시스템에 추가하십시오. 모든 실행이 완료되면 GCStats의 다음 통계를 비교하십시오.
사용 가능 힙이 85% 이상에서 정착하는 경우에는, Application Server 및 응용프로그램이 힙에 대해 할당된 메모리를 낮게 활용하므로 최대 힙 크기를 줄일 것을 고려하십시오.
Solaris tcp_close_wait_interval/tcp_time_wait_interval
Solaris tcp_fin_wait_2_flush_interval
Solaris tcp_keepalive_interval
다른 많은 TCP 매개변수가 있습니다. 이 매개변수들을 변경하면 사용자 환경에서 성능에 영향을 줄 수 있습니다. TCP/IP 스택을 조정하는데 대한 자세한 정보는 웹 사이트 Tuning your TCP/IP Stack and More를 참조하십시오.
세 가지 TCP 매개변수를 변경하기 전에 서버는 특정 최대 기간 동안 중지 상태였습니다. netstat 명령에서 포트 80에 대해 열린 많은 소켓이 CLOSE_WAIT 또는 FIN_WAIT_2 상태에 있음을 표시했습니다.
두 토폴로지 모두에서, ORB(Object Request Broker) 참조 기준 전달(pass-by-reference)이 선택되며 백엔드 데이터베이스가 각자 자신의 전용 시스템상에 있습니다.
또한, 네 개 시스템의 프로세서 활용도가 거의 100%이면 다섯 번째 시스템을 추가할 수 있습니다. 혹은, 웹 서버 기계가 용량만큼 실행 중이 아니며 웹 컨테이너 처리가 과도하지 않은 경우에는 토폴로지 B로 이동하여 네 개의 시스템에서 프로세서를 사용 가능하게 하십시오.
동일한 관계가 세션 관리자 연결 수에 적용됩니다. MaxAppls 설정은 적어도 연결
수 만큼이어야 합니다. 세션 및 데이터소스에 대해 동일한
데이터베이스를 사용 중이면, MaxAppls는 세션 관리자와 데이터소스에 대한 연결 수
설정을 합한 값이어야 합니다.
MaxAppls = (데이터소스에 대해 설정된 연결 수 + 세션 관리자의 연결 수) x 복제본 수
WAS 데이터베이스와 각각의 응용프로그램 데이터베이스에 대해 MaxAppls 설정값을 계산했으면, DB2에 대한 MaxAgents 설정값이 모든 MaxAppls의 합과 같거나 더 큰지 확인하십시오.
MaxAgents = 모든 데이터베이스에 대한 MaxAppls의 합
이 절에서는 Application Server가 실행될 하드웨어 선택 및 구성에 대한 고려사항에 대해 설명합니다.
최소한 프로세서당 512MB 메모리를 허용하십시오.
관리 클라이언트 호스트에서 호스트 이름 해석에 관한 자세한 정보는 WebSphere Application Server Admin Best Practices for Performance and Scalability 백서를 참조하십시오.
이 절에서는 서버 환경에서의 운영 체제 조정 고려사항에 대해 설명합니다.
참고: Windows NT/2000 운영 체제에서 WebSphere Application Server를 조정할 때에는 이 두 매개변수를 함께 사용해야 합니다.
ulimit -n 2000복제본이 있는 대형 SMP 시스템의 경우에는 다음 명령을 발행하십시오.
ulimit -unlimited
ulimit -a 명령을 사용하여 시스템 자원에 대한 모든 제한사항의 현재 값을 표시하십시오.
ulimit -n 1024
ulimit -a를 사용하여 시스템 자원에 대한 모든 제한사항의 현재 값을 표시하십시오.
특정 최대 기간 동안 서버가 느릿해질 수 있습니다. 이런 일이 발생하면 netstat 명령이 포트 80에 열려 있는 많은 소켓이 CLOSE_WAIT 또는 FIN_WAIT_2 상태에 있음을 보여줄 것입니다. 서버가 응답을 보내지 않지만 시스템 프로세스에서의 모든 활동으로 CPU 사용율은 계속 높은 상태에 있을 때 4분 동안이나 뚜렷한 지연이 발생했습니다.
ndd -get /dev/tcp tcp_time_wait_interval ndd -set /dev/tcp tcp_time_wait_interval 60000
최대 기간 동안 서버가 느릿해질 수 있습니다. netstat 명령이 포트 80에 열려 있는 많은 소켓이 CLOSE_WAIT 또는 FIN_WAIT_2 상태에 있음을 나타냈습니다. 서버가 응답을 보내지 않지만 시스템 프로세스에서의 모든 활동으로 CPU 활용도는 높은 상태에 있을 때 4분 동안이나 지연이 발생했습니다.
ndd -get /dev/tcp tcp_fin_wait_2_flush_interval ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 67500
ndd -get /dev/tcp tcp_keepalive_interval ndd -set /dev/tcp tcp_keepalive_interval 300000
고객이 다음과 같은 다른 Solaris TCP 매개변수를 수정하여 성공을 보고했습니다.
tcp_conn_req_max_q tcp_comm_hash_size tcp_xmit_hiwat
이러한 설정을 증가시킨 후에도 현저한 성능상의 차이점이 보이지 않았을 지라도, 시스템에 이점이 있었을 것입니다.
/etc/system 항목을 통해 설정:
set semsys:seminfo_semume = 1024
/etc/system 항목을 통해 설정:
semsys:seminfo_semopm = 200
HP-UX 11 설정값을 수정하여 WebSphere Application Server 성능을 현저하게 향상시킬 수 있습니다.
chatr +pi64M +pd64M /opt/WebSphere/AppServer/java/bin/PA_RISC2.0/native_threads/java
명령 출력은 프로세스 실행 파일의 현재 운영 체제 특성을 제공합니다.
이 변경에 대한 자세한 사항은 Hewlett Packard 웹 페이지를 참조하십시오.
connect requests dropped due to full queue
ndd -set /dev/tcp tcp_conn_request_max 1024
이 변경에 대한 자세한 사항은 다음 Hewlett Packard 웹 페이지를 참조하십시오.
| 커널 매개변수 | WebSphere Application Server 조정 | DB2 조정 | Oracle 조정 |
| maxdsiz | 조정되지 않음 | 조정되지 않음 | 조정되지 않음 |
| maxdsiz_64b | 조정되지 않음 | 조정되지 않음 | 조정되지 않음 |
| maxuprc | 512 | ||
| maxfiles | 2,048 | ||
| maxfiles_lim | 2,048 | ||
| nkthreads | 10,000 | ||
| max_thread_proc | 2,048 | ||
| nproc | 1,028 | ||
| nflocks | 8,192 | ||
| ninode | 2,048 | ||
| nfile | 8,192 | ||
| msgseg | 32,767 | ||
| msgmnb | 65,535 | ||
| msgmax | 65,535 | ||
| msgtql | 1,024 | ||
| msgmap | 258 | ||
| msgmni | 256 | ||
| msgssz | 16 | ||
| semmni | 512 | 70 | |
| semmap | 514 | ||
| semmns | 1,024 | 200 | |
| semmnu | 1,024 | ||
| shmmax | 966,367,642 | 1 GB | |
| shmmseg | 16 | 10 | |
| shmmni | 300 | 100 |
HP-UX 11 커널 매개변수에 대한 자세한 정보는 다음 Hewlett Packard 웹 페이지를 참조하십시오.
WebSphere Application Server 제품은 여러가지 웹 서버 브랜드 및 버전에 대한 플러그인을 제공합니다. 각 웹 서버 운영 체제 조합은 응용프로그램 성능에 영향을 주는 고유한 조정 매개변수를 가지고 있습니다.
이 절에서는 웹 서버와 연관된 성능 조정 설정에 대해 설명합니다.
IHS는 다중 프로세스, 단일 스레드 서버입니다. 자세한 정보는 IBM HTTP Server 조정에 관한 웹 페이지를 참조하십시오.
iPlanet Web server, Enterprise Edition의 기본 구성은 단일 프로세스, 다중 스레드 서버를 제공합니다.
웹 서버가 억압되고 있는지 알려면, 해당되는 perfdump 통계를 보십시오. 다음 데이터를 보십시오.
참고: sePlugin의 권한을 확인해야 할 수도 있습니다.
ListenBackLog 매개변수로 상태를 완화시켜 IIS가 대기열에 보존하는 요청 수를 늘리십시오.
MaxPoolThreads, PoolThreadLimit
IBM HTTP Server는 쉽게 구성됩니다. 대개는 기본 설정값이면 적당합니다.
스레드 활용도를 보는 방법: 로드 하에 사용되는 스레드 수를 발견할 수 있는 두 가지 방법이 있습니다.
다음 단계에 따라 IBM HTTP Server server-status를 사용하십시오.
각 WebSphere Application Server 프로세스에는 응용프로그램 성능에 영향을 주는 여러가지 매개변수가 있습니다. WebSphere Application Server 제품의 각 Application Server는 EJB 컨테이너와 웹 컨테이너로 구성됩니다.
WebSphere Application Server 관리 콘솔을 사용하여 관리 도메인의 응용프로그램, 웹 컨테이너, EJB 컨테이너, Application Server 및 노드를 구성하고 조정하십시오.
매개변수 활용도를 보는 방법: UNIX의 경우, ps -efl 명령을 사용하여 현재 프로세스 우선순위를 보십시오.
웹 서버에서 웹 컨테이너로 Servlet 요청을 보내기 위해 제품이 웹 서버 플러그인과 각 웹 컨테이너 사이에 전송 대기열을 설정합니다.
자원 분석기에서 구성된 스레드가 얼마만큼의 시간을 사용 중인지를 판별하는 최대화된 퍼센트라는 메트릭을 표시합니다. 이 값이 지속적으로 두 자리 수인 경우, 웹 컨테이너가 병목 현상일 수 있으며 스레드 수를 증가시켜야 합니다.
각 스레드에 대해 요청된 크기의 캐시가 작성됩니다. 스레드의 수는 웹 컨테이너 최대 스레드 크기 설정에 의해 결정됩니다.
참고: 캐시가 클수록 더 많은 Java 힙을 사용하므로, 최대 Java 힙 크기를 증가시켜야 할 수도 있습니다. 예를 들어, 각 캐시 항목이 2KB를 필요로 하고, 최대 스레드 크기가 25로 설정되고, URL 호출 캐시 크기가 100인 경우 5MB의 Java 힙이 필요합니다.
Bean 성능 정보를 보려면 자원 분석기를 사용하십시오.
Bean, 사용권한 및 증명서에 관한 보안 정보에 대해 캐시 처리가 이루어집니다. 캐시 제한시간이 만기되면, 캐시된 모든 정보가 유효하지 않게 됩니다. 정보에 대한 후속 요청은 데이터베이스 조회를 야기합니다. 간혹, 정보를 확보하기 위해서 LDAP 바인드나 기본 인증을 호출해야 하는 경우가 있으며, 두 경우 모두 비교적 성능면에서 조작 비용이 발생합니다.
사이트의 사용 패턴과 보안 필요성을 기초로 응용프로그램에 대한 최상의 타협안을 찾도록 실험하십시오.
다음 시스템 등록 정보는 해시 알고리즘의 리해싱 및 분배의 빈도에 영향을 미치는 캐시 1차 및 2차 해시테이블의 초기 크기를 결정합니다. 사용 가능 해시 값이 클수록 해시 충돌이 덜 발생하며 검색 시간이 느릴 것입니다. 여러 항목이 캐시 해시테이블을 구성하는 경우, 더 큰 용량으로 테이블을 작성하면 자동 리해싱이 테이블의 증대를 결정하는 것보다 항목이 보다 효율적으로 삽입될 수 있게 합니다. 리해싱이 수행될 때마다 모든 항목이 이동됩니다.
SAS(Secure Association Service) 기능은 SSL 연결이 JVM에서 (다른 JVM으로) 진행될 경우에만 SSL 연결을 설정합니다. 그러므로, 모든 Bean이 동일한 JVM 내에 같이 위치하면, SAS에서 사용하는 SSL이 성능을 저하시키지 않습니다.
서비스 탭 및 관리 도메인에 구성된 기본 서버나 추가 Application Server, ORB(Object Request Broker)에 대한 등록 정보 편집을 사용하여 이러한 매개변수를 설정하십시오.
경고: 참조 기준 전달은 위험하며 예기치 않은 결과를 야기할 수 있습니다. 오브젝트 참조가 원격 메소드에 의해 수정되면, 호출자가 그러한 변경을 볼 수도 있습니다.
Application Server에서 엔터프라이즈 Bean 요청에 대한 큰 워크로드를 예상하는 경우, ORB 구성이 매우 중요합니다. 다음 등록 정보를 주목하십시오.
JNIReaders를 사용하면 고정된 스레드 집합이 작성되어야 하므로 메모리를 덜 요구합니다. 초기화 동안 스레드가 한 번만 작성되며 스레드가 절대 소멸되지 않으므로 시간이 절약됩니다. JNIReader는 C-native 구현으로써 기본 리더 스레드보다 빨라야 합니다.
경고: JNIReader의 JNI 라이브러리 구현이 WebSphere Application Server bin 디렉토리에 있는지 확인하십시오. Intel 플랫폼의 경우에는 라이브러리가 Selector.dll이며, UNIX의 경우에는 libSelector.a 또는 libSelector.so입니다. Unix의 경우 접두부인 "lib"가 누락되면 파일 이름을 바꾸어야 합니다.
JVM 조정
JVM은 사용자의 응용프로그램의 성능뿐 아니라 WebSphere Application Server(기본적으로 Java 응용프로그램인)의 성능에 영향을 주는 몇 가지 조정 매개변수를 제공합니다.
일반적으로, Java 힙 크기가 증가하면 힙이 더 이상 물리적 메모리에 상주하지 않을 때까지 처리량이 향상됩니다. 힙이 디스크에 대한 스와핑을 시작하면 Java 성능이 현저하게 저하됩니다. 그러므로 최대 힙 크기는 물리적 메모리 내에서 힙을 포함하기에 충분한 작은 값으로 설정해야 합니다.
물리적 메모리 사용은 JVM과 다른 응용프로그램(예: 데이터베이스) 사이에 공유해야 합니다. 확실히 하기 위해, 더 작은 힙(예를 들어, 소형 메모리 시스템의 경우 64MB)을 사용하십시오.
소형 시스템(즉, 물리적 메모리가 1GB 미만)의 경우 128MB, 2GB 메모리가 있는 시스템의 경우 256MB, 그리고 대형 시스템의 경우 512MB를 최대 힙으로 사용하십시오. 시작 점은 응용프로그램에 따라 다릅니다.
성능 평가가 실행 중이고 자주 반복되는 결과가 필요하면 초기 및 최대 크기를 같은 값으로 설정하십시오. 그러면 실행 중에 힙이 커지지 않습니다. Java 응용프로그램의 작업 세트 크기를 알 수 없는 생산 시스템의 경우, 초기 설정을 최대 설정의 1-4배로 하는 것이 좋은 시작값입니다. 그리고나면, JVM이 힙 크기를 Java 응용프로그램의 작업 세트에 맞게 수정합니다.
JVM 매개변수를 설정하려면 관리 도메인에서 구성하는 추가 WebSphere Application Server나 기본 서버의 명령행 등록 정보를 사용하십시오.
WebSphere Application Server는 사용자가 선택하는 지원 데이터베이스와 확실하게 통합됩니다. 지원되는 데이터베이스 제품에 대한 정보는 www.ibm.com/software/webservers/appserv/library.html 웹 사이트에 있는 제품 필수조건을 참조하십시오. WebSphere Application Server는 응용프로그램에 대한 세션 상태 및 엔터프라이즈 Bean 데이터를 저장하는 것 외에도 관리를 위해 데이터베이스를 지속적인 보조 저장소로 사용합니다.
응용프로그램이 WebSphere Application Server 세션 상태, JDBC 데이터베이스 연결 풀링 또는 엔터프라이즈 Bean을 사용할 경우, 관리 도메인 내에서 이러한 자원 및 해당 데이터베이스 설정이 구성되는 방법에 특히 주의하십시오. WebSphere Application Server를 설치하는 동안 다른 이름을 사용할 수 있지만 WASnn이라는 이름의 데이터베이스가 형성됩니다. 여기서 nn은 릴리스 ID입니다. 이 문서에서는 WAS40이 사용된다고 가정합니다.
확장성을 위해, 특히 클러스터링을 사용할 경우 별도의 시스템에서 데이터베이스를 설정하였을 것입니다. 이는 WebSphere Application Server 데이터베이스, 응용프로그램 데이터베이스 및 WebSphere Application Server 세션 데이터베이스(지속 세션을 사용하는 경우)와 관련됩니다.
복제본을 사용하는 경우, 각 복제본마다 하나의 데이터소스 풀이 있습니다. 이는 데이터베이스 서버 최대 연결을 구성할 경우에 중요합니다.
자원 분석기를 사용하여 이 숫자들에 대한 값을 줄일 수 있는 최적의 풀 연결 수를 찾으십시오. 사용 퍼센트가 계속 낮으면 풀의 연결 수를 줄이는 것을 고려하십시오.
UNIX 플랫폼에서는 별도의 DB2 프로세스가 각 연결마다 작성됩니다. 이는 메모리가 적은 시스템의 성능에 바로 영향을 미치므로, 오류가 발생할 수 있습니다.
각 엔티티 EJB 트랜잭션은 특히 트랜잭션을 처리하기 위해 데이터베이스에 대한 추가 연결을 필요로 합니다. 데이터소스 연결 수를 계산할 때 이를 염두에 두십시오. 응용프로그램이 스레드당 둘 이상의 동시 연결을 필요로 하며, 또한 데이터베이스 연결 풀이 스레드 수에 비해 충분히 크지 않을 경우 교착 상태가 발생할 수 있습니다. 각 응용프로그램 스레드가 두 개의 동시 데이터베이스 연결을 필요로 하고 스레드 수가 최대 연결 풀 크기와 같다고 가정해 보십시오. 다음의 두 경우가 모두 적용될 경우에 교착 상태가 발생할 수 있습니다.
이 경우 교착 상태를 방지하기 위해서는 데이터베이스 연결 풀에 대해 설정한 값이 적어도 하나는 커야 하므로, 대기 중인 스레드 중 최소한 하나는 두 번째 데이터베이스 연결을 확보하여 완료될 수 있습니다.
교착 상태를 피하려면 응용프로그램이 스레드당 기껏해야 하나의 연결을 사용하도록 코딩하십시오. 스레드당 C 동시 데이터베이스 연결을 필요로 하도록 응용프로그램을 코딩하는 경우, 연결 풀은 최소한 다음 연결 수만큼 지원해야 합니다. 여기서 T는 최대 스레드 수입니다.
T * (C - 1) + 1
연결 풀 설정은 데이터베이스 서버가 지원하도록 구성되는 연결 수와 직접 관련됩니다. 풀에서 최대 연결 수를 늘리고 데이터베이스의 해당 설정은 늘리지 않으면, 응용프로그램이 실패하고 stderr.log 파일에 SQL 예외 오류가 표시됩니다.
참고: 준비된 명령문은 사전 컴파일로 이익을 얻는 매개변수 사용 SQL문의 처리를 위해 최적화됩니다. 데이터소스에 지정된 JDBC 드라이버가 사전 컴파일을 지원하는 경우, 준비된 명령문을 작성하면 사전 컴파일을 위해 이 명령문이 데이터베이스로 전송됩니다. 일부 드라이버는 사전 컴파일을 지원하지 않습니다. 이 경우, 준비된 명령문이 실행될 때까지 명령문이 데이터베이스로 전송되지 않을 수도 있습니다.
WebSphere Application Server 데이터소스는 준비된 명령문 오브젝트의 연관된 캐시는 물론 데이터베이스 연결 풀도 관리합니다. 준비된 명령문은 이를 실행하는 각 연결을 식별하는 태그를 사용하여 캐시됩니다. 사용되는 SQL문, 준비된 명령문 캐시, 데이터소스 및 데이터베이스 사이의 관계가 검토할 중요 사안입니다. 응용프로그램이 5개의 SQL 문 즉, 2개의 select, 1개의 delete, 1개의 insert 및 1개의 update를 사용한다고 가정하십시오.
위의 데이터소스는 데이터베이스로의 동시 연결을 최대 세 개까지 사용하여 구성됩니다. 연결이 이미 작성되었고 많은 SQL문이 실행되었습니다. 10개의 명령문을 보유하도록 준비된 명령문 캐시가 구성되었습니다. 연결 1과 2에 대해 캐시된 준비된 명령문은 세 개입니다. 연결 3에는 네 개의 명령문이 캐시되어 있습니다. 사용될 때 명령문은 준비된 명령문으로 컴파일되므로, 준비된 명령문 캐시는 응용프로그램의 데이터베이스 사용 패턴을 반영합니다. 준비된 명령문 캐시는 FIFO(first-in, first-out) 대기열을 구현합니다. 주어진 SQL문을 나타내는 준비된 명령문 오브젝트가 준비된 명령문 캐시에 여러번 나타날 수 있습니다. 특히 연결 풀의 모든 연결에 대해 한번만 나타날 수 있습니다. 예를 들어 명령문 1 및 2가 각 연결에 대해 한번씩, 세 번 나타납니다. 명령문 3은 연결 3에 대해 나타나지 않고 명령문 4와 5는 연결 3에 대해서만 나타납니다. 따라서 그러한 연결을 위해서는 재컴파일이 필요하므로 연결 1과 2에 대해 명령문 4와 5가 발생하는 경우 이 명령문들을 실행하는 데 더 많은 시간이 걸릴 수 있습니다. 이 예에 대한 더 나은 대안은 준비된 명령문 캐시의 크기를 15로 지정하는 것입니다(세 연결 각각에 대해 5개의 준비된 명령문).
자원 분석기는 캐시 버리기를 최소화하기 위해 이 설정을 조정할 수 있게 도울 수 있습니다. 전형적인 들어오는 클라이언트 요청 수를 나타내는 표준 워크로드를 사용하고, 고정된 반복 수를 사용하고, 표준 구성 설정 집합을 사용하십시오.
다음 지시사항에 따라 자원 분석기를 사용하십시오.
데이터소스 > 연결 풀링 > 명령문 캐시 크기에 대한 최상의 값은 0의 값이나 PrepStmt 캐시 버리기에 대한 최저 값을 확보하기 위해 사용된 설정입니다. 이는 전형적인 워크로드에 대해 가장 효율적인 수를 나타냅니다.
기타 JDBC 매개변수
준비된 명령문 캐시 크기를 설정하는 것 외에도, 다른 JDBC 드라이버 특정 등록 정보를 설정할 수
있습니다. 예를 들어, Oracle을 사용 중이면 다음 명령문을 사용하여 결과 세트를 가져오는 동안
페치할 행 수를 늘릴 수 있습니다.
name="defaultRowPrefetch", value="25"
데이터베이스에 대해서는 일반 탭에 이러한 사용자 정의 등록 정보 유형을 입력하십시오.
BUFFPAGE를 n의 값으로 설정하려면 DB2 명령 update db cfg for x using BUFFPAGE n을 발행하고 다음과 같이 NPAGES가 -1인지 확인하십시오.
db2 <-- go to DB2 command mode, otherwise the following "select" will not work as is
connect to x <-- (where x is the particular DB2 database name)
select * from syscat.bufferpools
(and note the name of the default, perhaps: IBMDEFAULTBP)
(if NPAGES is already -1, you are OK and no need to issue following command)
alter bufferpool IBMDEFAULTBP size -1
(re-issue the above "select" and NPAGES should now be -1)
최적화 레벨이 9이면 DB2는 액세스 계획을 최적화하는 데 많은 시간과 사용 가능한 모든 통계를 투입하게 됩니다.
자세한 정보는 DB2 문서 및 IBM DB2 웹 사이트를 참조하십시오.
runstats가 수행되었는지 보려면 DB2 CLP에서 다음 명령을 발행하십시오.
db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"
runstats가 수행되지 않았으면, nleaf 및 nlevels가 -1로 채워지고 stats_time은 빈 항목 "-"를 가질 것입니다.
runstats가 이미 수행되었으면, runstats가 완료되었을 때의 실시간 소인 역시 stats_time 밑에 표시될 것입니다. 이전 runstats에 대해 표시된 시간이 너무 오래된 것 같으면 runstats를 다시 실행하십시오.
새 설정은 즉시 영향을 미칩니다.
다음은 DB2 MinCommit와 관련된 여러가지 메트릭입니다.
세션 관리 매개변수를 설정하는데 대한 추가 정보는 InfoCenter 항목 4.4.1.1 세션 프로그래밍 모델 및 환경을 참조하십시오.
이 매개변수의 활용도는 trace on cmm 구성요소를 사용 가능하게 하여 볼 수 있습니다.
메시지를 직렬로 처리 즉, 하나의 메시지 Bean만이 하나씩 메시지를 처리하는데 사용되도록 하려면 1의 값을 사용해야 합니다.
20의 값이 최상의 처리량을 제공합니다. 이 값을 너머 증가시키면 처리량이 증가되지 않습니다. 메시지 유형 및 작업 양과 사용 가능한 자원에 기초하여 10과 20 사이의 값이 최대 메시지 처리량을 확보하기 위해 사용되어야 합니다.
메시지 처리량의 증가는 시스템 자원 및 리스너 구성과 같은 여러가지 요인에 따라 달라집니다. 시스템 자원은 프로세서 갯수 및 능력을 의미합니다. 리스너 구성은 활용되는 세션 수 및 JMS 상호 작용입니다. JMS 상호 작용에는 하부 MQ Server 관리자 자원에 대한 액세스를 공유하기 위한 경합이 포함됩니다.
다음 단계를 따르십시오.
시작 메뉴에서 프로그램 > 관리 도구 > 성능 모니터를 선택하십시오.