test

Sun Java System Message Queue 3.7 UR1 관리 설명서

시스템 조정

다음 절에서는 운영 체제, JVM 및 통신 프로토콜에서 조정할 수 있는 내용을 설명합니다.

Solaris 조정: CPU 사용률, 페이징/스왑/디스크 입출력

운영 체제 조정에 대해서는 시스템 설명서를 참조하십시오.

Java 가상 머신 조정

기본적으로 브로커는 192MB의 JVM 힙을 사용합니다. 이 크기는 대량의 메시지 로드를 처리하기에 비해 너무 작은 경우가 많으므로 늘리는 것이 좋습니다.

브로커가 Java 객체에서 사용되는 JVM 힙 공간을 소진하는 데 이르면 브로커는 흐름 제어, 메시지 스왑 등 여러 기술을 사용하여 메모리를 확보합니다. 아주 드물게 메모리를 확보하고 메시지 유입을 줄이기 위해 클라이언트 연결을 닫는 경우도 있습니다. 따라서, 이러한 경우가 발생하지 않도록 최대 JVM 힙 공간을 충분하게 설정하는 것이 좋습니다.

하지만, 최대 Java 힙 공간을 너무 높게 설정하면 브로커가 전체 시스템 메모리가 부족해 질 때까지 Java 힙 공간을 계속해서 증가시킬 수 있습니다. 그렇게 되면 성능이 감소하거나, 예상치 않은 브로커 충돌이 발생하거나, 시스템에서 실행 중인 다른 응용 프로그램 및 서비스의 동작에 영향을 미칠 수 있습니다. 일반적으로 운영 체제 및 시스템에서 실행할 다른 응용 프로그램이 충분한 물리적 메모리를 사용할 수 있도록 해야 합니다.

일반적으로 정상 시스템 메모리와 최대 시스템 메모리를 평가하여 시스템 메모리 문제를 일으키지 않고 우수한 성능을 제공할 수 있도록 Java 힙 크기를 구성하는 것이 좋습니다.

브로커의 최소 및 최대 힙 크기를 변경하려면 브로커를 시작할 때 -vmargs 명령줄 옵션을 사용합니다. 예를 들면 다음과 같습니다.

/usr/bin/imqbrokerd -vmargs "-Xms256m -Xmx1024m"

이 명령은 시작 Java 힙 크기를 256MB로 설정하고 최대 Java 힙 크기를 1GB로 설정합니다.

어떤 경우든 브로커 로그 파일을 확인하거나 imqcmd metrics bkr -m cxn 명령을 사용하여 설정을 확인합니다.

전송 프로토콜 조정

응용 프로그램 요구에 맞는 프로토콜을 선택했으면 선택한 프로토콜을 기반으로 추가 조정하여 성능을 향상시킬 수 있습니다.

다음 세 가지 브로커 등록 정보를 사용하여 프로토콜의 성능을 수정할 수 있습니다.

TCP 및 SSL 프로토콜의 경우 이러한 등록 정보는 클라이언트와 브로커 사이의 메시지 전달 속도에 영향을 미칩니다. HTTP 및 HTTPS 프로토콜의 경우 이 등록 정보는 웹 서버에서 실행 중인 Message Queue 터널 서블릿과 브로커 사이의 메시지 전달 속도에 영향을 미칩니다. HTTP/HTTPS 프로토콜의 경우 성능에 영향을 미칠 수 있는 추가 등록 정보가 있습니다( HTTP/HTTPS 조정 참조).

프로토콜 조정 등록 정보에 대해서는 다음 절에서 설명합니다.

nodelay

nodelay 등록 정보는 지정된 프로토콜의 Nagle 알고리즘(TCP/IP에서 TCP_NODELAY 소켓 수준 옵션 값)에 영향을 미칩니다. Nagle 알고리즘은 WAN(Wide-Area Network) 같은 느린 연결을 사용하는 시스템에서 TCP 성능을 향상시키는 데 사용됩니다.

이 알고리즘이 사용되면 TCP는 여러 개의 작은 데이터 청크가 원격 시스템으로 보내지지 않도록 데이터를 큰 패킷으로 묶으려고 합니다. 소켓에 기록된 데이터가 필요한 버퍼 크기를 채우지 못하는 경우 프로토콜은 버퍼가 채워지거나 특정 지연 시간이 경과될 때까지 패킷 전송을 지연합니다. 버퍼가 채워지거나 시간 초과가 발생하면 패킷을 보냅니다.

대부분의 메시징 응용 프로그램에서 패킷을 지연 없이 보내는 경우(Nagle 알고리즘을 사용하지 않는 경우) 최고의 성능을 냅니다. 이는 클라이언트와 브로커 사이의 상호 작용이 대부분 클라이언트가 데이터 패킷을 브로커에게 보내고 응답을 기다리는 요청/응답 상호 작용이기 때문입니다. 예를 들어, 일반적인 상호 작용에는 다음이 포함됩니다.

이러한 상호 작용에서 대부분의 패킷은 버퍼 크기보다 작습니다. 이는 Nagle 알고리즘이 사용되는 경우 브로커가 사용자에게 응답을 보내기 전에 몇 밀리초를 지연함을 의미합니다.

하지만 Nagle 알고리즘은 연결이 느리고 브로커 응답이 필요하지 않은 경우 성능을 향상시킬 수 있습니다. 이런 것으로는 클라이언트가 비지속성 메시지를 보내는 경우나 클라이언트 확인을 브로커에서 확인하지 않는 경우(DUPS_OK_ACKNOWLEDGE 세션)를 들 수 있습니다.

inbufsz/outbufsz

inbufsz 등록 정보는 소켓에서 들어오는 데이터를 읽는 입력 스트립의 버퍼 크기를 설정합니다. 마찬가지로 outbufsz는 데이터를 소켓에 기록하기 위해 브로커가 사용하는 출력 스트림의 버퍼 크기를 설정합니다.

일반적으로 두 매개 변수 모두 보내거나 받는 평균 패킷보다 약간 큰 값으로 설정해야 합니다. 경험에 따르면 이 등록 정보 값을 평균 패킷에 1KB를 더한 크기(가장 가까운 KB값으로 반올림)로 설정하는 것이 좋습니다. 예를 들어, 브로커가 본문 크기가 1KB인 패킷을 받는 경우 패킷의 전체 크기(메시지 본문 + 헤더 + 등록 정보)는 약 1200바이트입니다. inbufsz가 2KB(2048바이트)인 경우 적당한 성능을 제공합니다. inbufsz나 outbufsz를 이 크기보다 더 늘리면 성능은 약간 늘어날 수 있지만 각 연결에 필요한 메모리가 늘어나게 됩니다.

HTTP/HTTPS 조정

앞의 두 절에서 설명한 일반 등록 정보 이외에도 HTTP/HTTPS 성능은 클라이언트가 Message Queue 터널 서블릿을 호스트하는 웹 서버에 대해 HTTP 요청을 얼마나 빨리 보낼 수 있는지에 따라 제한됩니다.

단일 소켓에서 다중 요청을 처리하도록 웹 서버를 최적화해야 할 수 있습니다. JDK 버전 1.4 이상에서는 웹 서버에 대한 HTTP 연결이 유지되어(웹 서버 소켓이 열린 상태로 유지) 다중 HTTP 요청을 처리할 때 웹 서버에서 사용되는 자원을 최소화합니다. JDK 버전 1.4를 사용하는 클라이언트 응용 프로그램의 성능이 이전 JDK 릴리스로 실행 중인 같은 응용 프로그램보다 느린 경우 성능을 향상시키기 위해 웹 서버의 연결 유지 구성 매개 변수를 조정해야 할 수 있습니다.

이러한 웹 서버 조정과 더불어 클라이언트가 웹 서버를 폴하는 간격도 조정할 수 있습니다. HTTP는 요청 기반 프로토콜입니다. 따라서 HTTP 기반 프로토콜을 사용하는 클라이언트는 웹 서버에서 메시지가 대기 중인지 주기적으로 확인해야 합니다. imq.httpjms.http.pullPeriod 브로커 등록 정보(및 해당 imq.httpsjms.https.pullPeriod 등록 정보)는 Message Queue 클라이언트 런타임이 웹 서버를 폴하는 간격을 지정합니다.

pullPeriod 값이 -1(기본값)인 경우 클라이언트 런타임은 이전 요청이 반환되자마자 서버를 폴하여 개별 클라이언트의 성능을 최대화합니다. 따라서 각 클라이언트 연결이 웹 서버의 요청 스레드를 독점하여 웹 서버 자원이 고갈될 수 있습니다.

pullPeriod 값이 양수인 경우 클라이언트 런타임은 주기적으로 웹 서버에 요청을 보내 보류 중인 데이터가 있는지 확인합니다. 이 경우 클라이언트가 웹 서버의 요청 스레드를 독점하지 않습니다. 따라서 많은 수의 클라이언트가 웹 서버를 사용 중인 경우 pullPeriod를 양수로 설정하면 웹 서버 자원을 절약할 수 있습니다.

파일 기반 영구 저장소 조정

파일 기반 영구 저장소 조정에 대한 자세한 내용은 지속성 서비스를 참조하십시오.