이 문서에서는 EAP_HOME 변수를 사용하여 JBoss EAP 설치 경로를 나타냅니다. 이 변수를 JBoss EAP 설치의 실제 경로로 바꿉니다.

관리형 도메인 호스트에서 개별 서버를 원격으로 모니터링하도록 JBoss EAP를 구성하려면 아래 절차를 따르십시오.

사전 구성된 JConsole 래퍼 스크립트는 JBoss EAP와 함께 번들됩니다. 이 래퍼 스크립트를 사용하면 필요한 모든 라이브러리가 클래스 경로에 추가되고 JConsole 내에서 JBoss EAP 관리 CLI에도 액세스할 수 있습니다.

Java VisualVM은 Oracle JDK에 포함되어 있으며 JAVA_HOME/bin/jvisualvm 에 있습니다. Oracle JDK를 사용하지 않는 경우 VisualVM 웹 사이트에서 VisualVM 을 다운로드할 수도 있습니다. VisualVM은 IBM JDK에서 작동하지 않습니다.

다음 섹션에서는 VisualVM을 사용하여 로컬 또는 원격 JBoss EAP JVM에 연결하는 방법을 설명합니다. VisualVM 사용에 대한 자세한 내용은 VisualVM 설명서 를 참조하십시오.

가비지 컬렉션 로그를 검사하면 Java 성능 문제, 특히 메모리 사용과 관련된 문제를 해결할 때 유용할 수 있습니다.

로그 파일을 작성하는 추가 디스크 I/O 활동 외에 가비지 컬렉션 로깅을 활성화해도 서버 성능에는 큰 영향을 미치지 않습니다.

가비지 컬렉션 로깅은 OpenJDK 또는 Oracle JDK에서 실행되는 독립 실행형 JBoss EAP 서버에 대해 기본적으로 활성화되어 있습니다. JBoss EAP 관리형 도메인의 경우 호스트 컨트롤러, 프로세스 컨트롤러 또는 개별 JBoss EAP 서버에 대해 가비지 컬렉션 로깅을 활성화할 수 있습니다.

Java 힙 덤프는 특정 시점에서 생성된 JVM 힙의 스냅샷입니다. 힙 덤프를 만들고 분석하면 Java 애플리케이션의 문제를 진단하고 해결하는 데 유용할 수 있습니다.

사용 중인 JDK에 따라 JBoss EAP 프로세스의 Java 힙 덤프를 생성 및 분석하는 다양한 방법이 있습니다. 이 섹션에서는 Oracle JDK, OpenJDK 및 IBM JDK의 일반적인 방법에 대해 설명합니다.

OpenJDK 및 Oracle JDK 환경의 경우 jstack 유틸리티를 사용하여 Java 스레드 진단 정보를 사용할 수 있습니다.

관리 CLI 특성으로 생성된 런타임 통계를 확인하여 관리되는 실행자 서비스의 성능을 모니터링하고 예약된 실행자 서비스의 성능을 모니터링할 수 있습니다. 독립 실행형 서버 또는 호스트에 매핑된 개별 서버에 대한 런타임 통계를 볼 수 있습니다.

[standalone@localhost:9990 /] /subsystem=ee/managed-executor-service=default:read-resource(include-runtime=true,recursive=true)

[standalone@localhost:9990 /] /subsystem=ee/managed-scheduled-executor-service=default:read-resource(include-runtime=true,recursive=true)

[domain@localhost:9990 /] /host=<host_name>/server=<server_name>/subsystem=ee/managed-executor-service=default:read-resource(include-runtime=true,recursive=true)

[domain@localhost:9990 /] /host=<host_name>/server=<server_name>/subsystem=ee/managed-scheduled-executor-service=default:read-resource(include-runtime=true,recursive=true)

프로덕션 환경에서 힙 크기를 사전 할당하고 수정하려면 초기 및 최대 힙 크기 옵션을 동일한 크기로 설정해야 합니다.

프로덕션 힙 크기는 오버헤드의 공간을 허용하기 위해 테스트된 최대값보다 최소 25% 이상이어야 합니다.

처리량 가비지 컬렉터라고도 하는 병렬 가비지 컬렉터는 서버 클래스 머신의 Java 8의 기본 가비지 컬렉터 이지만, Red Hat은 G1 가비지 컬렉터를 사용하는 것이 좋습니다. 이 가비지 컬렉터는 Java 9 이후의 기본값일 것으로 예상됩니다. G1 가비지 컬렉터는 일반적으로 대부분의 시나리오에서 CMS 및 병렬 가비지 컬렉터보다 더 나은 성능을 제공합니다.

가비지 컬렉션 로깅 옵션

가비지 컬렉션 로깅은 독립 실행형 JBoss EAP 서버에 대해 기본적으로 활성화됩니다. JBoss EAP 관리형 도메인에 대한 가비지 수집 로깅을 활성화하려면 가비지 수집 활성화를 참조하십시오.

JBoss EAP JVM에 대해 대규모 페이지를 활성화하면 메모리에 잠긴 페이지가 있고 일반 메모리와 같이 디스크로 교체할 수 없습니다.

특히 메모리를 많이 사용하는 애플리케이션의 경우 대규모 페이지를 사용할 경우 힙을 호출하거나 디스크에 스왑할 수 없으므로 항상 쉽게 사용할 수 있습니다.

큰 페이지를 사용하는 한 가지 단점은 시스템에서 실행 중인 다른 프로세스에서 메모리에 대한 빠른 액세스가 없을 수 있으므로 이러한 프로세스에 대해 과도한 페이징이 발생할 수 있다는 것입니다.

다른 성능 구성 변경과 마찬가지로 테스트 환경 변경의 영향을 테스트하는 것이 좋습니다.

공격적 최적화(AggressiveOpts) JVM 옵션을 사용하면 환경에 대한 성능이 향상될 수 있습니다. 이 옵션은 향후 Java 릴리스에서 기본값으로 예상되는 Java 성능 최적화 기능을 제공합니다.

Red Hat Enterprise Linux 및 Solaris 플랫폼의 경우 JBoss EAP JVM 프로세스에 적절한 ulimit 값을 구성해야 합니다. "soft" ulimit 는 일시적으로 초과할 수 있지만 "hard" ulimit 는 리소스를 사용하기 위한 엄격한 수단입니다. 적절한 ulimit 값은 환경과 애플리케이션에 따라 달라집니다.

JBoss EAP 프로세스에 적용된 제한이 너무 낮은 경우 JBoss EAP를 시작할 때 다음과 같은 경고가 표시됩니다.

WARN  [org.jboss.as.warn.fd-limit] (main) WFLYSRV0071: The operating system has limited the number of open files to 1024 for this process; a value of at least 4096 is recommended.

JBoss EAP 관리형 도메인 호스트에는 호스트 컨트롤러와 프로세스 컨트롤러를 위한 별도의 JVM이 있습니다. 호스트 컨트롤러 및 프로세스 컨트롤러 의 역할에 대한 자세한 내용은 JBoss EAP 구성 가이드를 참조하십시오.

호스트 컨트롤러 및 프로세스 컨트롤러 JVM 설정을 조정할 수 있지만 대규모 관리형 도메인 환경에서도 호스트 컨트롤러 및 프로세스 컨트롤러의 기본 JVM 구성으로 충분해야 합니다.

호스트 컨트롤러 및 프로세스 컨트롤러 JVM에 대한 기본 구성은 총 도메인 크기 200대의 JBoss EAP 서버에 대해 10대의 JBoss EAP 서버를 실행하는 최대 20개의 JBoss EAP 호스트의 관리형 도메인 크기로 테스트되었습니다.

대규모 관리형 도메인에 문제가 발생하는 경우 해당 환경에서 호스트 컨트롤러 또는 프로세스 컨트롤러 JVM을 모니터링하여 힙 크기와 같은 JVM 옵션에 적절한 값을 결정해야 할 수 있습니다.

빈 인스턴스 풀은 SLSB(상태 비저장 세션 빈) 및 MDB(Message Driven Beans)에 사용됩니다. 기본적으로 SLSB는 인스턴스 풀 default-slsb-instance-pool 을 사용하며 MDB는 인스턴스 풀 default-mdb-instance-pool 을 사용합니다.

빈 인스턴스 풀의 크기는 한 번에 생성할 수 있는 특정 엔터프라이즈 빈의 인스턴스 수를 제한합니다. 특정 엔터프라이즈 빈의 풀이 가득 차면 클라이언트는 차단하고 인스턴스를 사용할 수 있을 때까지 기다립니다. 클라이언트가 풀의 시간 제한 속성에 설정된 시간 내에 인스턴스를 가져오지 않으면 예외가 발생합니다.

빈 인스턴스 풀의 크기는 derive-size 또는 max- pool-size 를 사용하여 구성됩니다. derive -size 특성을 사용하면 다음 값 중 하나를 사용하여 풀 크기를 구성할 수 있습니다.

derive-size 가 정의되지 않은 경우 빈 인스턴스 풀 크기에 max-pool-size 값이 사용됩니다.

특정 인스턴스 풀을 사용하도록 엔터프라이즈 빈을 구성할 수 있습니다. 이를 통해 각 엔터프라이즈 빈 유형에서 사용할 수 있는 인스턴스를 보다 세부적으로 제어할 수 있습니다.

/subsystem=ejb3:undefine-attribute(name=default-slsb-instance-pool)

기본적으로 default 라는 빈 스레드 풀은 비동기 엔터프라이즈 빈 호출 및 엔터프라이즈 빈 타이머에 사용됩니다.

필요한 경우 다른 빈 스레드 풀을 사용하도록 각 엔터프라이즈 빈 서비스를 구성할 수 있습니다. 이는 빈 스레드 풀에 대한 각 서비스의 액세스를 보다 세부적으로 제어하려는 경우에 유용할 수 있습니다.

적절한 스레드 풀 크기를 결정할 때 한 번에 처리할 동시 요청 수를 고려하십시오.

/subsystem=ejb3/thread-pool=POOL_NAME:add(max-threads=MAX_THREADS)

/subsystem=ejb3/thread-pool=my_thread_pool:add(max-threads=30)

/subsystem=ejb3/service=SERVICE_NAME:write-attribute(name=thread-pool-name,value=THREAD_POOL_NAME)

/subsystem=ejb3/service=async:write-attribute(name=thread-pool-name,value=my_thread_pool)

빈 배포에서 런타임 메타데이터를 사용할 수 있으므로 빈의 성능을 모니터링할 수 있습니다.

런타임 메타데이터는 다음 유형의 빈에 사용할 수 있습니다.

빈 애플리케이션에는 코드 또는 배포 설명자에 있는 주석으로 메타데이터가 포함됩니다. 애플리케이션은 두 옵션을 모두 사용할 수 있습니다. 사용 가능한 런타임 데이터에 대한 자세한 내용은 JBoss EAP 관리 모델의 tekton 3 하위 시스템을 참조하십시오.

/deployment=<deployment_name>/subsystem=ejb3/<bean_type>=<bean_name>:read-resource(include-runtime)

/deployment=ejb-management.jar/subsystem=ejb3/singleton-bean=ManagedSingletonBean:read-resource(include-runtime)

{
    "outcome" => "success",
    "result" => {
        "async-methods" => ["void async(int, int)"],
        "business-local" => ["sample.ManagedSingletonBean"],
        "business-remote" => ["sample.BusinessInterface"],
        "component-class-name" => "sample.ManagedSingletonBean",
        "concurrency-management-type" => undefined,
        "declared-roles" => [
            "Role3",
            "Role2",
            "Role1"
        ],
        "depends-on" => undefined,
        "execution-time" => 156L,
        "init-on-startup" => false,
        "invocations" => 3L,
        "jndi-names" => [
            "java:module/ManagedSingletonBean!sample.ManagedSingletonBean",
            "java:global/ejb-management/ManagedSingletonBean!sample.ManagedSingletonBean",
            "java:app/ejb-management/ManagedSingletonBean!sample.ManagedSingletonBean",
            "java:app/ejb-management/ManagedSingletonBean!sample.BusinessInterface",
            "java:global/ejb-management/ManagedSingletonBean!sample.BusinessInterface",
            "java:module/ManagedSingletonBean!sample.BusinessInterface"
        ],
        "methods" => {"doIt" => {
            "execution-time" => 156L,
            "invocations" => 3L,
            "wait-time" => 0L
        }},
        "peak-concurrent-invocations" => 1L,
        "run-as-role" => "Role3",
        "security-domain" => "other",
        "timeout-method" => "public void sample.ManagedSingletonBean.timeout(javax.ejb.Timer)",
        "timers" => [{
            "time-remaining" => 4304279L,
            "next-timeout" => 1577768415000L,
            "calendar-timer" => true,
            "persistent" => false,
            "info" => "timer1",
            "schedule" => {
                "year" => "*",
                "month" => "*",
                "day-of-month" => "*",
                "day-of-week" => "*",
                "hour" => "0",
                "minute" => "0",
                "second" => "15",
                "timezone" => undefined,
                "start" => undefined,
                "end" => undefined
            }
        }],
        "transaction-type" => "CONTAINER",
        "wait-time" => 0L,
        "service" => {"timer-service" => undefined}
    }
}

/deployment=ejb-management.jar/subsystem=ejb3/message-driven-bean=NoTimerMDB:read-resource(include-runtime)

{
    "outcome" => "success",
    "result" => {
        "activation-config" => [
            ("destination" => "java:/queue/NoTimerMDB-queue"),
            ("destinationType" => "javax.jms.Queue"),
            ("acknowledgeMode" => "Auto-acknowledge")
        ],
        "component-class-name" => "sample.NoTimerMDB",
        "declared-roles" => [
            "Role3",
            "Role2",
            "Role1"
        ],
        "delivery-active" => true,
        "execution-time" => 0L,
        "invocations" => 0L,
        "message-destination-link" => "queue/NoTimerMDB-queue",
        "message-destination-type" => "javax.jms.Queue",
        "messaging-type" => "javax.jms.MessageListener",
        "methods" => {},
        "peak-concurrent-invocations" => 0L,
        "pool-available-count" => 16,
        "pool-create-count" => 0,
        "pool-current-size" => 0,
        "pool-max-size" => 16,
        "pool-name" => "mdb-strict-max-pool",
        "pool-remove-count" => 0,
        "run-as-role" => "Role3",
        "security-domain" => "other",
        "timeout-method" => undefined,
        "timers" => [],
        "transaction-type" => "CONTAINER",
        "wait-time" => 0L,
        "service" => undefined
    }
}

ejb3 하위 시스템에서 default-stateful- bean-session-timeout 특성을 사용하여 서버 인스턴스에 배포된 모든 상태 저장 세션 빈(SFSB)에 대한 기본 글로벌 시간 초과 값을 구성할 수 있습니다.

default-stateful-bean-session-timeout 특성을 사용하면 ejb3 하위 시스템에서 다음 관리 CLI 작업을 사용할 수 있습니다.

특성 동작은 서버 모드에 따라 다릅니다. 예를 들면 다음과 같습니다.

기본적으로 속성 값은 -1 로 설정되며 배포된 SFSB는 시간 초과되지 않도록 구성됩니다. 그러나 속성에 대해 다음 두 가지 유형의 유효한 값을 구성할 수 있습니다.

속성에 대해 설정한 새 값을 확인하는 두 가지 방법이 있습니다.

이 섹션에서는 최적의 데이터 소스 또는 리소스 어댑터 성능을 위해 구성할 수 있는 선택한 풀 속성에 대한 조언을 자세히 설명합니다. 이러한 각 특성을 구성하는 방법에 대한 자세한 내용은 다음을 참조하십시오.

콘솔 로깅을 비활성화하면 JBoss EAP 성능이 향상될 수 있습니다. 콘솔에 로그를 출력하는 것은 프로덕션 환경의 개발 및 테스트 환경에 유용할 수 있지만 대부분의 경우 필요하지 않습니다.

JBoss EAP 루트 로거에는 standalone -full-ha 를 제외한 모든 기본 독립 실행형 서버 프로필에 대한 콘솔 로그 핸들러가 포함되어 있습니다. 기본 관리형 도메인 프로필에는 콘솔 핸들러가 포함되지 않습니다.

이상적인 성능을 위해 프로덕션 환경의 로깅 수준을 적절하게 구성해야 합니다. 예를 들어 INFO (정보 ) 또는 DEBUG(디버그) 수준은 개발 또는 테스트 환경에 적합할 수 있지만 대부분의 경우 프로덕션 환경 로깅 수준을 WARN 또는 ERROR 와 같이 더 높은 값으로 설정해야 합니다.

로그 파일의 스토리지 위치를 잠재적인 성능 문제로 고려해야 합니다. I/O 처리량이 좋지 않은 파일 시스템 또는 디스크 구성에 로그를 저장하면 전체 플랫폼의 성능에 영향을 줄 수 있습니다.

로깅이 JBoss EAP 성능에 영향을 미치지 않도록 하려면 많은 공간이 있는 고성능 전용 디스크로 로그 위치를 설정합니다.

버퍼 캐시는libvirt 하위 시스템에서 처리하는 정적 파일을 저장합니다. 여기에는 이미지, 정적 HTML, CSS 및 JavaScript 파일이 포함됩니다. 각 Undertow 서블릿 컨테이너에 대한 기본 버퍼 캐시를 지정할 수 있습니다. 서블릿 컨테이너에 최적화된 버퍼 캐시가 있으면 정적 파일을 제공하기 위한 Undertow 성능이 향상될 수 있습니다.

버퍼 캐시의 버퍼는 지역에 할당되며 고정된 크기의 버퍼입니다. 각 버퍼 캐시에 대해 구성 가능한 세 가지 특성이 있습니다.

버퍼 크기, 영역당 버퍼 수 및 최대 영역 수를 곱하여 버퍼 캐시에서 사용하는 최대 메모리 크기를 계산할 수 있습니다. 예를 들어 기본 버퍼 캐시는 리전당 1024바이트 * 1024 버퍼 * 10 regions = 10MB입니다.

정적 파일의 크기를 기반으로 버퍼 캐시를 구성하고 개발 환경에서 예상되는 로드를 테스트한 결과를 구성합니다. 성능에 미치는 영향을 결정할 때 버퍼 캐시 성능 이점과 사용된 메모리의 균형을 고려하십시오.

Undertow 바이트 버퍼 풀은 풀링된 NIO 바이트Buffer 인스턴스를 할당하는 데 사용됩니다. 모든 리스너에는 바이트 버퍼 풀이 있으며 각 리스너에 다른 버퍼 풀과 작업자를 사용할 수 있습니다. 바이트 버퍼 풀은 다른 서버 인스턴스 간에 공유할 수 있습니다.

성능에 큰 영향을 주는 기본 바이트 버퍼 풀 특성은 버퍼 크기입니다. 기본값은 시스템의 RAM 리소스를 기반으로 계산되며 대부분의 경우 충분합니다. 이 특성을 수동으로 구성하는 경우 대부분의 서버에 이상적인 크기는 16KB입니다.

다음 Jakarta Server Pages 구성 옵션은 Jakarta Server Pages를 Java 바이트 코드로 컴파일하는 방법에 대한 최적화를 제공합니다.

애플리케이션 및 환경에 따라 특정 트래픽 유형(예: 특정 포트의 트래픽)에 고유한 다중 리스너를 구성한 다음 각 리스너에 대한 옵션을 구성할 수 있습니다.

다음은 HTTP, HTTPS 및 NetNamespace 리스너에서 구성할 수 있는 선택된 성능 관련 옵션입니다.

각각 고유한 성능 구성이 있고 다양한 I/O 작업을 처리하는 별도의 작업자를 여러 개 만들 수 있습니다. 예를 들어 HTTP I/O를 처리하는 하나의 작업자와 Jakarta Enterprise Beans I/O를 처리하는 다른 작업자를 생성한 다음 특정 로드 요구 사항에 맞게 각 작업자의 속성을 별도로 구성할 수 있습니다.

구성 가능한 작업자 속성 목록은 IO 하위 시스템 속성 부록 을 참조하십시오.

성능에 큰 영향을 미치는 worker 속성은 작업자가 사용할 수 있는 총 I/O 스레드 수를 설정하는 작업-스레드와 특정 작업에 사용할 수 있는 최대 스레드 수를 설정하는 task-max-threads 입니다. 이러한 두 속성의 기본값은 서버의 CPU 개수에 따라 계산됩니다.

작업자를 생성하고 구성하는 방법에 대한 지침은 JBoss EAP 구성 가이드를 참조하십시오.

/subsystem=io/worker=default:read-resource(include-runtime=true,recursive=true)

the io 하위 시스템의 버퍼 풀은 I/O 작업에 특히 사용되는 풀링된 NIO 버퍼 인스턴스입니다. 작업자 와 마찬가지로 특정 I/O 작업을 처리하는 전용 버퍼 풀을 별도의 버퍼 풀을 생성할 수 있습니다.

구성 가능한 버퍼 풀 속성 목록은 IO 하위 시스템 속성 부록 을 참조하십시오.

성능에 큰 영향을 주는 주요 버퍼 풀 특성은 buffer-size 입니다. 기본값은 시스템의 RAM 리소스를 기반으로 계산되며 대부분의 경우 충분합니다. 이 속성을 수동으로 구성하는 경우 대부분의 서버에 이상적인 크기는 16KB입니다.

버퍼 풀을 생성하고 구성하는 방법에 대한 지침은 JBoss EAP 구성 가이드를 참조하십시오.

관리 CLI 또는 JMX를 통해 JBoss EAP 클러스터링을 모니터링하도록 jgroups 하위 시스템에 대한 통계를 활성화할 수 있습니다.

가능한 경우 JGroups 트래픽의 네트워크 인터페이스가 전용 VLAN(Virtual Local Area Network)의 일부여야 합니다. 이를 통해 클러스터 통신을 다른 JBoss EAP 네트워크 트래픽과 분리하여 클러스터 네트워크 성능, 처리량 및 보안을 보다 쉽게 제어할 수 있습니다.

클러스터 성능을 향상시키기 위해 고려해야 할 또 다른 네트워크 구성은 점보 프레임을 활성화하는 것입니다. 네트워크 환경에서 지원하는 경우 MTU(최대 전송 단위)를 늘려 점보 프레임을 활성화하면 특히 처리량이 높은 환경에서 네트워크 성능을 향상시킬 수 있습니다.

점보 프레임을 사용하려면 네트워크의 모든 NIC 및 스위치가 이를 지원해야 합니다. Red Hat Enterprise Linux의 점보 프레임 활성화에 대한 자세한 내용은 Red Hat 고객 포털을 참조하십시오.

JGroups에 포함된 메시지는 여러 개의 작은 메시지를 더 큰 번들로 어셈블하여 네트워크 성능을 향상시킵니다. 네트워크를 통해 다수의 작은 메시지를 클러스터 노드로 보내는 대신 최대 번들 크기에 도달할 때까지 메시지를 대기열에 추가하거나 더 이상 전송할 메시지가 없습니다. 대기 중인 메시지는 더 큰 메시지 번들로 조합된 다음 전송됩니다.

이 번들은 특히 네트워크 통신에 더 많은 오버헤드가 있는 TCP 환경에서 통신 오버헤드를 줄입니다.

번들 크기 튜닝의 성능 향상은 환경 및 번들이 어셈블되는 동안 통신 지연에 따라 더 효율적인 네트워크 트래픽이 분산되는지 여부에 따라 달라집니다.

다음 관리 CLI 명령을 사용하여 max_bundle_size 를 구성합니다.

/subsystem=jgroups/stack=STACK_NAME/transport=TRANSPORT_TYPE/property=max_bundle_size:add(value=BUNDLE_SIZE)

예를 들어 기본 udp 스택에 대해 max_bundle_size 를 60K 로 설정하려면 다음을 실행합니다.

/subsystem=jgroups/stack=udp/transport=UDP/property=max_bundle_size:add(value=60K)

jgroups 하위 시스템은 자체 스레드 풀을 사용하여 클러스터 통신을 처리합니다. JGroups에는 개별적으로 구성할 수 있는 기본,내부,oob 및 타이머 기능에 대한 스레드 풀이 포함되어 있습니다. 각 JGroups 스레드 풀에는 keepalive-time,max- threads,min-threads 및 queue- length 에 대한 구성 가능한 속성이 포함되어 있습니다.

각 스레드 풀 속성에 적절한 값은 환경에 따라 달라지지만 대부분의 경우 기본값으로 충분해야 합니다.

JGroups 스레드 풀 구성 방법에 대한 지침은 JBoss EAP 구성 가이드를 참조하십시오.

jgroups 하위 시스템에는 UDP 및 TCP 스택 모두에 대해 구성 가능한 전송 및 수신 버퍼가 있습니다.

JGroups 버퍼의 적절한 값은 환경에 따라 달라지지만 대부분의 경우 기본값으로 충분해야 합니다. 버퍼 크기에 적절한 값을 조정하려면 개발 환경에서 부하에서 클러스터를 테스트하는 것이 좋습니다.

JGroups 전송 및 수신 버퍼를 구성하는 방법에 대한 지침은 JBoss EAP 구성 가이드를 참조하십시오.