프록시 서버 문제점 해결

이 주제를 통해 프록시 서버와 관련하여 발생할 수 있는 문제점을 해결할 수 있습니다.

이 태스크 정보

[z/OS]프록시 서버 오류는 joblog에 기록됩니다. 프록시 서버 관련 문제점이 있는 경우 다음 목록을 참조하십시오.

[AIX Solaris HP-UX Linux Windows][IBM i]프록시 서버 오류는 SystemOut.log, proxy.log또는 local.log 파일에 로그됩니다. 프록시 서버 관련 문제점이 있는 경우 다음 목록을 참조하십시오.

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

프로시저

  • 프록시 서버가 작성되었지만 시작할 수 없습니다.
    포트 충돌의 SYSOUT 파일을 확인하십시오. netstat -a 명령을 사용하여 프록시 서버와 연관된 엔드포인트를 이미 사용되었는지 확인하십시오. 관리 콘솔에서 > 서버 > 프록시 서버 > <서버 이름> > 포트를 클릭하면 해당 포트를 확인할 수 있습니다.
    UNIX 시스템에서 특권이 없는 사용자로서 프록시 서버를 시작하는 데 실패하면 로그에서 다음 메시지를 확인하십시오.
    ChannelFramew E   CHFW0029E: Error initializing chain HTTPS_PROXY_CHAIN because of 
    예외 
    com.ibm.wsspi.channel.framework.exception.RetryableChannelException: Permission 
    denied
    TCPPort       E   TCPC0003E: TCP Channel TCP_7 initialization failed.  The socket 
    bind failed for host * and port 80.  포트가 이미 사용 중입니다.
    
    PROXY_HTTP_ADDRESS 및 PROXY_HTTPS_ADDRESS 전송 체인의 포트를 1024보다 큰 값으로 변경하십시오.
  • 프록시 서버는 관리 포트를 통해 웹 컨테이너로 요청을 라우트합니다.
    프록시 서버는 몇 개의 웹 컨테이너 앞에 위치합니다. 웹 컨테이너가 9061, 9081 등과 같은 비기본 포트를 청취하도록 구성해야 합니다. 이 시나리오는 여러 애플리케이션 서버가 동일한 시스템에 있는 기본적인 경우로, 구성에서 새롭고 다양한 포트가 사용되도록 합니다. 이 시나리오에서는 프록시 서버가 예상되는 포트인 9081을 사용하는 대신 관리 포트 9061을 통해 웹 컨테이너로 애플리케이션 요청을 라우트할 수도 있습니다.

    대상 애플리케이션과 연관된 가상 호스트에 웹 컨테이너의 청취 포트 번호를 추가하십시오. 이 프로세스를 수행하면 프록시 서버가 올바른 포트 번호를 통해 웹 컨테이너로 요청을 라우트합니다.

  • 프록시 서버가 시작되었지만 프록시 서버의 엔드포인트를 통해 애플리케이션 자원에 액세스할 수 없습니다.
    프록시 서버 엔드포인트가 애플리케이션과 연관된 가상 호스트의 호스트 별명 중 하나인지 확인하십시오.
  • 프록시 서버가 다른 코어 그룹으로 라우트됩니다.
    셀의 코어 그룹 간에 코어 그룹 브릿지가 있는지, 또한 브릿지로 선택한 프로세스가 다시 시작되었는지 확인하십시오. 코어 그룹 간에 방화벽이 있는 경우, 코어 그룹 브릿지 트래픽에 필요한 올바른 포트가 열려 있는지 확인하십시오.
  • 프록시 서버가 다른 셀로 요청을 라우트할 수 없습니다.
    코어 그룹 브릿지 설정을 검토하십시오. HMGR0149E 오류 메시지가 임의의 서버(일반적으로 코어 그룹 브릿지 기능을 수행하는 서버)에서 로그되는 경우, 통신을 허용하도록 셀의 보안 설정을 수정해야 합니다.

    여러 셀 간의 셀 보안 구성에 대한 자세한 정보는 LTPA(Lightweight Third Party Authentication) 키 내보내기 주제를 참조하십시오.

  • 프록시에 대한 요청을 작성할 때 공백 페이지 수신
    다음 조치를 고려하십시오.
    • 가상 호스트를 업데이트하십시오. 대상 애플리케이션 및 라우팅 규칙이 포트를 청취하는 프록시 서버를 포함하는 가상 호스트에 지정되는지 확인하십시오(기본값: HTTP 80, HTTPS 443). 포트를 청취하는 프록시 서버를 애플리케이션 또는 라우팅 규칙 가상 호스트에 추가하거나 proxy_host 가상 호스트를 사용하십시오.
    • 충돌 프로세스를 중지하십시오. 시스템에서 프록시 서버 포트(기본값: HTTP 80, HTTPS 443)를 사용하는 다른 프로세스(예: Apache, IBM HTTP Server 등)가 실행되지 않는지 확인하십시오. 이 문제점이 발생하는 경우 프록시 서버가 정상적으로 시작되는 것처럼 보이지만 영향을 받는 청취 포트에 대한 요청을 수신할 수 없습니다. 다음과 같이 시스템을 확인하십시오.
      1. 프록시 서버를 중지하십시오.
      2. netstatps 명령을 사용하여 시스템을 조회하고 문제 프로세스가 프록시 서버가 청취하는 포트를 사용하는지 여부를 판별하십시오.
      3. 문제 프로세스가 있는 경우, 해당 프로세스를 중지하고 시스템 시작 시 해당 프로세스가 시작되지 않도록 시스템을 구성하십시오.
    • 프록시 라우팅을 사용 가능하게 하십시오. 애플리케이션의 웹 모듈에 프록시 라우팅을 사용할 수 있는지 확인하십시오. 프록시 라우팅은 기본적으로 사용할 수 있으므로 프록시 특성을 수정하지 않는 경우 이 솔루션을 무시하십시오. 그렇지 않은 경우, 프록시 속성을 수정하는 방법에 대한 지침은 ‘애플리케이션으로의 라우팅 사용자 지정’ 을 참조하십시오.
    • 직접 요청을 테스트하십시오. 애플리케이션 서버에 대한 직접 요청을 통해 대상 애플리케이션이 설치되었는지 확인하십시오. 응답이 수신되지 않는 경우 프록시 서버가 아닌 애플리케이션 서버 관련 문제점입니다. 애플리케이션 서버에서 직접 응답을 받을 수 있게 되면 프록시 서버를 통해 이 방법을 확인하십시오.
  • HTTP 프록시 서버로부터 404 (파일 찾을 수 없음) 오류가 발생했습니다.
    다음 조치를 고려하십시오.
    • 가상 호스트를 업데이트하십시오. 대상 애플리케이션 및 라우팅 규칙이 포트를 청취하는 프록시 서버를 포함하는 가상 호스트에 지정되는지 확인하십시오(기본값: HTTP 80, HTTPS 443). 포트를 청취하는 프록시 서버를 애플리케이션 또는 라우팅 규칙 가상 호스트에 추가하거나 proxy_host 가상 호스트를 사용하십시오.
    • 프록시 라우팅을 사용 가능하게 하십시오. 애플리케이션의 웹 모듈에 프록시 라우팅을 사용할 수 있는지 확인하십시오. 프록시 라우팅은 기본적으로 사용할 수 있으므로 프록시 특성을 수정하지 않는 경우 이 솔루션을 무시하십시오. 그렇지 않은 경우, 프록시 속성을 수정하는 방법에 대한 지침은 ‘애플리케이션으로의 라우팅 사용자 지정’ 을 참조하십시오.
    • 직접 요청을 테스트하십시오. 애플리케이션 서버에 대한 직접 요청을 통해 대상 애플리케이션이 설치되었는지 확인하십시오. 응답이 수신되지 않는 경우 프록시 서버가 아닌 애플리케이션 서버 관련 문제점입니다. 애플리케이션 서버에서 직접 응답을 받을 수 있게 되면 프록시 서버를 통해 이 방법을 확인하십시오.
  • 애플리케이션 또는 라우팅 규칙에 대한 SSL( SSL ) 요청을 수행할 수 없습니다.
    애플리케이션 또는 라우팅 규칙의 가상 호스트에 프록시 서버 SSL 포트(기본값: 443)에 대한 호스트 별명이 포함되는지 확인하십시오.
  • 프록시 서버에 연결할 수 없습니다 ... 요청 제한시간이 초과되었습니다.
    충돌 프로세스를 중지하십시오. 시스템에서 프록시 서버 포트(기본값: HTTP 80, HTTPS 443)를 사용하는 다른 프로세스(예: Apache, IBM HTTP Server 등)가 실행되지 않는지 확인하십시오. 이 상황이 발생하는 경우 프록시 서버가 정상적으로 시작되는 것처럼 보이지만 영향을 받는 청취 포트에 대한 요청을 수신할 수 없습니다. 다음과 같이 시스템을 확인하십시오.
    1. 프록시 서버를 중지하십시오.
    2. netstatps 명령을 사용하여 시스템을 조회하고 문제 프로세스가 프록시 서버가 청취하는 포트를 사용하는지 여부를 판별하십시오.
    3. 문제 프로세스가 있는 경우, 해당 프로세스를 중지하고 시스템 시작 시 해당 프로세스가 시작되지 않도록 시스템을 구성하십시오.
  • HTTP 오류 발생 시(예: 404) 오류 페이지 애플리케이션으로부터 응답을 받지 못했습니다.
    오류 페이지 URI가 올바르게 입력되었는지 확인하십시오. 또한 백엔드 서버에서 HTTP 오류 응답을 처리하는 경우 원격 오류 처리 옵션을 선택했는지 확인하십시오. 자세한 내용은 ‘사용자 지정 오류 페이지 정책 개요’‘프록시 서버 설정’의 ‘사용자 지정 오류 페이지 정책’ 섹션을 참조하십시오.
  • 프록시 서버를 추적할 때 사용할 수 있는 패키지
    모든 추적에 다음 패키지가 모두 필요하지는 않지만 잘 알지 못하는 경우 모두 사용하십시오.
    • *=info
    • WebSphere Proxy=all
    • GenericBNF=all
    • HAManager=all
    • HTTPChannel=all
    • TCPChannel=all
    • WLM*=all
    • DCS=all
    • ChannelFrameworkService=all
    • com.ibm.ws.dwlm.*=all
    • com.ibm.ws.odc.*=all
  • SSL 의 온/오프 로드를 어떻게 활성화하나요?
    SSL(Secure Socket Layer) 온/오프 로드는 관리 콘솔의 전송 프로토콜이며 전송 프로토콜은 웹 모듈 특성입니다. 웹 모듈 속성을 구성하는 방법은 ‘애플리케이션 라우팅 사용자 지정’을 참조하십시오. 전송 프로토콜은 라우팅 규칙에 지정된 일반 서버 클러스터에 원래 포함되므로 라우팅 규칙에 대한 SSL(Secure Socket Layer) 온/오프 로드 또는 전송 프로토콜 특성은 없습니다.
  • IBM HTTP Server 또는 웹 서버 플러그인 앞에 있는 경우, 가상 호스트에 포트를 추가할 필요가 없도록 프록시 서버를 구성하는 방법은 무엇입니까?
    제품이 추가하는 개인용 헤더와 같이 요청에 포함된 보안 관련 정보를 프록시 서버가 신뢰하도록 하려면 프록시 서버 신뢰 보안 프록시 목록에 요청의 제안자를 추가하십시오. 예를 들어, IBM HTTP Server 또는 프록시 서버에 요청을 전송하는 웹 서버 플러그인을 프록시 서버 신뢰 보안 프록시 목록에 추가하십시오. 웹 서버 플러그인은 요청의 가상 호스트 정보를 포함하는 제품 추가 개인용 헤더 정보를 전송할 수 있습니다. 프록시가 웹 서버 플러그인 또는 클라이언트의 개인용 헤더를 신뢰하지 않는 경우 프록시 서버가 프록시 서버 HTTP 및 HTTPS 포트를 가상 호스트에 추가해야 하는 고유한 개인용 헤더를 추가합니다. 일반적으로 웹 서버 플러그인이 프록시 서버에서 사용되는 경우 이는 프록시 서버를 백엔드 서버로 사용하기 위한 목적입니다. 따라서 프록시 서버 포트를 노출할 필요가 없도록 플러그인을 신뢰된 보안 프록시로 추가해야 합니다. 플러그인에서 프록시 서버로 요청을 전달하는 방법은 프록시 서버와 함께 사용할 웹 서버 플러그인을 구성하는 방법에 대한 자세한 정보를 제공합니다. 프록시 서버 설정에서는 신뢰할 수 있는 보안 프록시를 설정하는 방법에 대한 자세한 정보를 제공합니다.
  • 프록시 서버가 스트레스로 인해 정지된 것처럼 보이거나 너무 많은 파일 열기 예외가 ffdc 또는 SystemErr.log에 표시됩니다.
    연결 로드가 높은 경우 파일 시스템 설명자를 모두 사용하여 프록시 서버가 정지된 것처럼 보이거나 ffdc 디렉토리 또는 SystemError.log 파일에 파일이 너무 많이 열려 있음 예외가 발생합니다. 이러한 경우는 소켓을 열 수 없기 때문입니다. 이 문제점을 완화하려면 운영 체제 레벨 및 프록시 서버 레벨에서 다음 매개변수 중 하나 이상을 수정하여 프록시 서버에 대한 연결의 사용을 최적화하십시오.
    • [Windows]Windows 2003 및 XP용 운영 체제 튜닝
      • TcpTimedWaitDelay - TCP/IP가 닫힌 연결을 해제하고 그의 자원을 다시 사용하기 전에 경과해야 하는 시간을 판별하십시오. 닫힘과 해제 사이의 이 간격을 TIME_WAIT 상태 또는 2MSL(twice the maximum segment lifetime) 상태라고 합니다. 이 기간 동안, 클라이언트와 서버로의 연결을 다시 여는 비용은 새 연결을 설정하는 비용보다 저렴합니다. 이 항목의 값을 줄이면 TCP/IP가 닫힌 연결을 더 빨리 해제할 수 있어서 새 연결을 위해 더 많은 자원을 제공할 수 있습니다. 실행 중인 애플리케이션에서 빠른 해제와 새 연결의 작성이 필요하고 TIME_WAIT 상태에 있는 많은 연결로 인해 처리량이 낮은 경우 이 매개변수를 조정하십시오.
        다음과 같이 값을 보거나 설정하십시오.
        1. regedit 명령을 사용하여 레지스트리 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters 하위 키에 접근한 후, 새 REG_DWORD 값을 생성하고 이름을 ` TcpTimedWaitDelay `로 지정하십시오.
        2. 값을 10진수 30(16진수 0x0000001e)으로 설정하십시오. 이 값은 대기 시간을 30초로 설정합니다.
        3. 시스템을 중지했다가 다시 시작하십시오.
        정보
        기본값 0xF0, 대기 시간을 240초(4분)로 설정합니다.
        권장 값 최소값 0x1E, 대기 시간을 30초로 설정합니다.
      • MaxUserPort - 애플리케이션이 시스템에서 사용 가능한 사용자 포트를 요청할 때 TCP/IP가 지정할 수 있는 가장 높은 포트 번호를 판별합니다. 다음과 같이 값을 보거나 설정하십시오.
        1. regedit 명령을 사용하여 해당 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters registry 하위 키에 접근한 후, 새 REG_DWORD 값을 생성하고 이름을 ' MaxUserPort '로 지정하십시오.
        2. 이 값은 최소 십진수 32768로 설정하십시오.
        3. 시스템을 중지했다가 다시 시작하십시오.
        정보
        기본값 없음
        권장 값 최소값은 10진수 32768입니다.
    • [Linux]Linux® 용 운영 체제 튜닝
      • timeout_timewait 매개변수 - TCP/IP가 닫힌 연결을 해제하고 그의 자원을 다시 사용하기 전에 경과해야 하는 시간을 판별하십시오. 닫힘과 해제 사이의 이 간격을 TIME_WAIT 상태 또는 2MSL(twice the maximum segment lifetime) 상태라고 합니다. 이 기간 동안, 클라이언트와 서버로의 연결을 다시 여는 비용은 새 연결을 설정하는 비용보다 저렴합니다. 이 항목의 값을 줄이면 TCP/IP가 닫힌 연결을 더 빨리 해제할 수 있어서 새 연결을 위해 더 많은 자원을 제공할 수 있습니다. 실행 중인 애플리케이션에서 빠른 해제와 새 연결의 작성이 필요하고 TIME_WAIT 상태에 있는 많은 연결로 인해 처리량이 낮은 경우 이 매개변수를 조정하십시오. 다음 명령을 발행하여 timeout_timewait 매개변수를 30초로 보거나 설정하십시오.
        echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout           
      • Linux 파일 설명자(ulimit) - 지원되는 열린 파일 수를 지정합니다. 기본 설정이 보통 대부분의 애플리케이션에 대해 충분합니다. 이 매개변수에 설정된 값이 너무 낮으면 파일 열기 오류, 메모리 할당 장애 또는 연결 설정 오류가 발생할 수 있습니다.

        다른 쉘의 구문은 ulimit 명령에 대한 UNIX 참조 페이지를 확인하여 이 값을 보거나 설정하십시오. KornShell 쉘(ksh)에 대해 ulimit -n 65535 명령을 발행하여 ulimit 명령을 65535로 설정하십시오. 시스템 자원에 대한 모든 한계의 현재 값을 표시하려면 ulimit -a 명령을 사용하십시오.

        정보
        기본값 1024
        권장 값 65535
    • [AIX]AIX® 용 운영 체제 튜닝
      • TCP_TIMEWAIT - TCP/IP가 닫힌 연결을 해제하고 그의 자원을 다시 사용하기 전에 경과해야 하는 시간을 판별하십시오. 닫힘과 해제 사이의 이 간격을 TIME_WAIT 상태 또는 2MSL(twice the maximum segment lifetime) 상태라고 합니다. 이 기간 동안, 클라이언트와 서버로의 연결을 다시 여는 비용은 새 연결을 설정하는 비용보다 저렴합니다. 이 항목의 값을 줄이면 TCP/IP가 닫힌 연결을 더 빨리 해제할 수 있어서 새 연결을 위해 더 많은 자원을 제공할 수 있습니다. 실행 중인 애플리케이션에서 빠른 해제와 새 연결의 작성이 필요하고 TIME_WAIT 상태에 있는 많은 연결로 인해 처리량이 낮은 경우 이 매개변수를 조정하십시오. 다음 명령을 발행하여 TCP_TIMEWAIT 상태를 15초로 보거나 설정하십시오.
        /usr/sbin/no -o tcp_timewait =1          
      • AIX 파일 설명자(ulimit) - 허용되는 열린 파일 수를 지정합니다. 기본 설정이 보통 대부분의 애플리케이션에 대해 충분합니다. 이 매개변수에 설정된 값이 너무 작으면 파일을 열거나 연결을 설정할 때 오류가 발생하여 메모리 할당 오류가 표시될 수 있습니다. WebSphere® Application Server 의 자원 부족을 방지하려면 WebSphere Application Server 프로세스가 실행되는 사용자 계정의 자원에 대한 한계 (ulimit) 를 제거하십시오.
        다음과 같이 ulimit 설정을 변경하여 이 값을 보거나 설정하십시오.
        1. 명령 창을 여십시오.
        2. smitty users를 입력하여 AIX 구성 프로그램을 여십시오.
        3. 사용자의 특성 표시또는 변경을 선택하십시오.
        4. WebSphere Application Server가 실행되는 사용자 계정의 이름을 입력하십시오.
        5. Enter를 누르십시오.
        6. 다음 설정을 표시된 값으로 변경하십시오.
          정보
          소프트 파일 크기 -1
          소프트 CPU 시간 -1
          소프트 스택 크기 -1
          소프트 코어 파일 크기 -1
          하드 파일 크기 -1
          하드 CPU 시간 -1
          하드 스택 크기 -1
          하드 코어 파일 크기 -1
        7. Enter를 눌러 변경사항을 저장하십시오.
        8. 계정을 로그아웃한 후 다시 로그인하십시오.
        9. 제품을 다시 시작하십시오.
        정보
        기본값 2000
        권장 값 제한 없음
    • [HP-UX]HP-UX 용 운영 체제 튜닝

      HP-UX nfile 커널 매개변수 - 지정된 시간에 시스템에서 열릴 수 있는 파일의 최대 수를 지정합니다. 충분한 수를 지정하지 않으면 시스템 처리 용량이 제한될 수 있습니다.

      HP-UX ninode 커널 매개변수 - 메모리에 있을 수 있는 열린 inode의 최대 수를 지정합니다. 열린 inode는 각각의 고유한 열린 파일과 연관됩니다. 따라서, ninode 매개변수에 지정한 값은 동시에 열려야 하는 고유한 파일 수보다 커야 합니다.

    • [Solaris]Solaris 용 운영 체제 튜닝
      • Solaris 파일 디스크립터(ulimit) - 지원되는 열린 파일 수를 지정합니다. 이 매개변수에 지정된 값이 너무 낮으면 파일 열기 오류, 메모리 할당 장애 또는 연결 설정 오류가 발생할 수 있습니다. 다른 쉘의 구문은 ulimit 명령에 대한 UNIX 참조 페이지를 확인하여 이 값을 보거나 설정하십시오.
        • 시스템 자원에 대한 모든 한계의 현재 값을 표시하려면 ulimit -a 명령을 실행하십시오.
        • KornShell 쉘(ksh)에 대해 ulimit 명령을 65535로 설정하려면 ulimit -n 65535 명령을 실행하십시오.
        • 프로세스에 대해 열릴 수 있는 최대 파일 수는 rlim_fd_max 및 글로벌 커널 한계에 대한 rlim_fd_cur 설정에 영향을 받습니다. /etc/system 파일의 이러한 설정 값을 늘려야 할 수 있습니다.
        Solaris 10은 커널 매개변수 설정에 새 메커니즘을 제공합니다. 다음 명령 중 하나를 실행하여 Solaris 10의 파일 디스크립터 커널 매개변수의 최대 수에 대한 한계를 새로 지정하십시오.
        1. 현재 쉘 세션에 대한 값을 변경하려면 다음을 수행하십시오.
          prctl -n process.max-file-descriptor -r -v 65535 $$
        2. 시스템 전체에서 변경하려면 다음을 수행하십시오.
          projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)'
          system
          

          이 명령이 모든 사용자 및 모든 프로젝트에 대한 설정을 변경하므로 이 명령을 실행할 때 주의해야 합니다.

        3. 사용자 루트에서 소유하는 모든 프로젝트에 대한 값을 변경하려면 다음을 수행하십시오.
          projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)'
          user.root
        4. 루트가 아닌 사용자가 소유하는 모든 프로젝트에 대한 값을 변경하려면 다음을 수행하십시오.
          projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)'
          user.username
      • TCP_TIME_WAIT_INTERVAL - 연결 제어 블록이 닫혀 있는 시간을 TCP/IP에 알려줍니다. 애플리케이션이 TCP/IP 연결을 완료하면, 지정한 시간 동안 제어 블록이 보존됩니다. 높은 연결 비율이 발생할 때, TCP/IP 연결의 큰 백로그가 누적되어 서버 성능을 저하시킬 수 있습니다. 서버는 특정 최대 기간 중에 정지할 수 있습니다. 서버가 정지하는 경우, netstat 명령은 HTTP 서버에 대해 열린 많은 소켓이 CLOSE_WAIT 또는 FIN_WAIT_2 상태에 있음을 표시합니다. 최고 4분 정도의 눈에 띄는 지연이 발생할 수 있고 그 동안 서버는 어떤 응답도 전송하지 않지만, 시스템 프로세스의 모든 활동과 함께 CPU 이용률이 여전히 높습니다.
        get 명령을 사용하여 현재 간격을 판별하거나 set 명령을 사용하여 간격을 30초로 지정하여 이 값을 보거나 설정하십시오. 예를 들어,
        ndd -get /dev/tcp tcp_time_wait_interval     
        ndd -set /dev/tcp tcp_time_wait_interval 30000  
        정보
        기본값 240000 밀리초(4분)
        권장 값 60000 밀리초
    • 프록시 서버 조정
      • 지속 요청 - 지속 요청은 기존 TCP 연결을 통해 전송되는 요청입니다. 클라이언트로부터의 TCP 연결을 통해 받는 요청 수를 늘려 성능을 극대화할 수 있습니다. 이 값은 인스턴스 GIF 등에 대해 임베드된 최대 오브젝트 수를 웹 페이지 + 1에 나타내야 합니다.

        WebSphere Application Server 관리 콘솔에서 ‘서버(Servers) > 프록시 서버(Proxy Servers) > server_name > 프록시 서버 전송 방식(Proxy server transports) > HTTP_PROXY_CHAIN/HTTPS_PROXY_CHAIN’을 클릭하여 이 값을 확인하거나 설정할 수 있습니다.

        정보
        기본값 100
        권장 값 웹 페이지 + 1에 임베드된 최대 오브젝트 수를 나타내는 값
      • 아웃바운드 연결 풀 크기 - 대상 서버에 대한 프록시 서버 풀 아웃바운드 연결 및 풀에 상주하는 연결 수를 구성할 수 있습니다. 연결 풀을 비우거나 비어 있는 경우 프록시 서버가 대상 서버에 대한 새 연결을 작성합니다. 동시 로드가 많은 경우, 최적의 성능을 나타낼 수 있는 예상 동시 클라이언트 로드 값으로 연결 풀 크기를 늘리십시오.

        WebSphere Application Server 관리 콘솔에서 ‘서버(Servers ) > 프록시 서버(Proxy Servers) > server_name > 프록시 서버 전송(Proxy server transports) > HTTP 프록시 서버 설정( Proxy Server Settings )’을 차례로 클릭하여 이 값을 확인하거나 설정할 수 있습니다. 컨텐츠 서버 연결 섹션에서 서버당 최대 연결 수 필드를 연결된 클라이언트의 예상 최대 수 이상으로 늘리십시오. 변경사항을 저장하고 프록시 서버 노드에 대한 변경사항을 동기화한 후 프록시 서버를 다시 시작하십시오.

        정보
        권장 값 예상 동시 클라이언트 로드와 일치하는 값
      • 아웃바운드 요청 제한시간 - 프록시 서버와 함께 사용하는 백엔드 애플리케이션 서버의 로드가 많아 적절한 시간 안에 응답할 수 없습니다. 따라서 백엔드 애플리케이션 서버 서버가 응답할 때까지 프록시 서버에 대한 연결이 차단됩니다. 이 문제는 프록시 서버가 대상 서버로부터의 응답을 대기하는 시간을 구성하여 완화하십시오. 이 값은 아웃바운드 요청 제한시간 값입니다. 프록시 서버가 느린 백엔드 애플리케이션 서버를 대기하는 시간을 관리함으로써 연결 속도가 빨라지고 다른 요청 작업에 사용됩니다.
        관리 콘솔에서 ‘서버(Servers) ’> ‘서버 유형(Server Types )’ > ‘ WebSphere 프록시 서버( proxy servers )’ > ‘proxy_server_name’ > ‘ HTTP 프록시 서버 설정( Proxy Server Settings )’을 차례로 클릭하여 이 값을 확인하거나 설정할 수 있습니다. 컨텐츠 서버 연결 섹션에서, 아웃바운드 요청 제한시간을 클라이언트 관점에서 허용 가능한 응답 시간을 나타내는 값으로 설정하십시오.
        정보
        기본값 120
        권장 값 클라이언트 관점에서 허용 가능한 응답 시간을 나타내는 값