SIP 애플리케이션 문제점 해결

이 주제를 사용하여 SIP 애플리케이션의 문제점을 해결할 수 있습니다.

이 태스크 정보

SIP 애플리케이션의 문제점을 해결할 때 다음 SIP 컨테이너 문제점 해결 기본 기능을 사용하십시오.

  • 시스템의 평균 CPU 사용량은 60%-70%을 초과해서는 안됩니다.
  • 컨테이너는 할당된 VM 힙 크기의 70%를 초과하여 사용해서는 안됩니다. 시스템이 VM 힙 크기를 수용할 수 있도록 충분한 실제 메모리를 갖도록 하십시오. 호출 로드 및 세션 제한시간은 힙 사용량에 큰 영향을 미칠 수 있습니다.
  • 컨테이너가 실행 중인 VM의 최대 가비지 콜렉션(GC) 시간은 500ms를 초과해서는 안되며 평균은 400ms 미만이어야 합니다. 자세한 GC는 이 값을 측정하는 데 사용할 수 있으며 PMI 뷰어는 그래픽 형식에서 GC 시간, 힙 사용량, 활성 세션 등을 보는 데 사용할 수 있습니다.

프로시저

다음 문제점 해결 체크리스트를 사용하여 SIP 애플리케이션의 문제점을 해결하십시오.
  • 구성에서 청취 포트를 확인하십시오.
  • netstat –an을 사용하여 청취 포트를 보십시오.
  • 가상 호스트 정의 여부를 검사하십시오.
  • 호스트 별명이 정의되었는지 확인하십시오.
  • 애플리케이션이 설치되었습니까? 시작되었습니까?
  • 프록시 구성의 경우: 기본 클러스터가 구성되었습니까? 프록시 및 서버가 시스템에 있으면 포트 충돌이 있습니까?

결과

문제점이 해결되지 않으면, 다음 SIP 컨테이너 증상 및 솔루션을 사용하여 특정 증상을 확인하십시오.
  • 증상: 수많은 재전송, CPU가 정기적으로 0으로 떨어지거나 ThreadPoolQueueIsFullException 예외가 로그에 표시됩니다.

    솔루션: 일반적으로 이 증상은 역방향 DNS 검색에 의해 발생하는 DNS 문제점이며 Ethereal 등의 도구를 사용하여 확인할 수 있습니다. 네트워크 캡처를 하고 IP 주소를 포함하는 많은 DNS 조회를 전송하고 응답으로 호스트 이름을 다시 가져오는 경우 이 문제점이 발생할 수 있습니다. HP 또는 네임 서비스 캐싱이 필요한 일부 기타 플랫폼에 있는 경우 nscd가 실행 중인지 확인하십시오. Microsoft Windows 플랫폼에서는 네임 서비스 캐싱이 필요하지 않습니다. 또 다른 솔루션은 호스트 이름을 /etc/hosts 파일에 추가하는 것입니다.

  • 증상: 수많은 재전송, CPU가 정기적으로 100%로 증가합니다.

    솔루션: 일반적으로 이 증상은 가비지 콜렉션에 의해 발생하며 자세한 GC(관리 콘솔에서 액세스할 수 있음)를 켜고 GC 주기의 길이를 관찰하여 확인할 수 있습니다. 여기서 솔루션은 JVM 선택적 인수를 -Xgcpolicy:gencon으로 설정하여 세대별 가비지 콜렉션을 사용 가능하게 만드는 것입니다.

  • 증상: 수많은 재전송, CPU가 장기간 100%로 증가하고 세대별 가비지 콜렉션을 사용할 수 있습니다.
    솔루션: 일반적으로 이 증상은 SIP 세션 오브젝트가 장기간 무효화되지 않거나 시간제한이 적용되지 않아서 발생합니다. 한 가지 솔루션은 애플리케이션의 sip.xml 파일에서 세션 제한시간 값을 더 작은 값으로 설정하는 것입니다. 이 문제점을 해결하는 가장 효율적인 방법은 대화 상자가 완료될 때(예, BYE 수신 후) 애플리케이션이 세션에 대한 무효화를 호출하는 것입니다. SystemOut.log 파일의 다음 항목은 각 애플리케이션에 대한 세션 제한시간 값이 컨테이너에 설치되었음을 나타냅니다.
    SipXMLParser  3 SipXMLParser getAppSessionTTL Setting Expiration time: 7 Minutes, For 	App: TCK back-to-back user agent”
    참고: 이 주제는 하나 이상의 애플리케이션 서버 로그 파일을 참조합니다. 권장되는 대안은 분배 및 IBM® i 시스템에서 SystemOut.log, SystemErr.log, trace.logactivity.log 파일을 사용하는 대신 HPEL(High Performance Extensible Logging) 로그를 사용하고 인프라를 추적하도록 서버를 구성하는 것입니다. 원시 z/OS® 로깅 기능과 연계하여 HPEL을 사용할 수도 있습니다. HPEL을 사용하는 경우 서버 프로파일 바이너리 디렉토리의 LogViewer 명령행 도구를 사용하여 모든 로그에 액세스하고 정보를 추적할 수 있습니다. HPEL 사용에 대한 자세한 정보는 HPEL을 사용한 애플리케이션 문제점 해결 정보를 참조하십시오.
  • 증상: 새 INVITE 메시지를 SIP 컨테이너에 전송할 때 컨테이너로부터 "480 서비스를 사용할 수 없음" 메시지가 여러 번 수신됩니다. 또한 서버가 이 상태일 때 다음 메시지가 SystemOut.log에 표시될 수 있습니다. "LoadManager E LoadManager warn.server.oveloaded".

    솔루션: 일반적으로 이 증상은 SIP 컨테이너 구성 가능 메트릭 중 하나가 초과되어 발생합니다. "최대 애플리케이션 세션" 값 및 "평균 기간당 최대 메시지" 값이 포함됩니다. 솔루션은 해당 값을 더 높게 조정하는 것입니다.

  • 증상: 완료되지 않은 재전송 및 호출이 많으며 SystemErr.log의 OutOfMemory 예외가 동반됩니다.

    솔루션: 일반적으로 이 증상은 컨테이너에 연관된 VM 힙 크기가 충분하지 않으며 상향 조정되어야 함을 의미합니다. 관리 콘솔에서 이 값을 조정할 수 있습니다.

  • 증상: SIP 프록시에 SIP 요청을 전송할 때 "503 서비스를 사용할 수 없음"이라는 내용이 수신됩니다.

    솔루션: 일반적으로 이 증상은 기본 클러스터(또는 메시지에 일치하는 클러스터 라우팅 규칙)가 프록시에 설정되지 않았음을 나타냅니다. SIP 프록시는 올바르게 구성되어 있으나 백엔드 SIP 컨테이너는 중지 또는 고장난 경우에도 이 증상이 나타날 수 있습니다.

  • 증상: SIP 프록시에 SIP 요청을 전송할 때 "404 찾을 수 없음"이라는 내용이 수신됩니다.

    솔루션: 일반적으로 이 증상은 기본 클러스터에 상주하는 컨테이너에 대해 가상 호스트가 설정되지 않았음을 나타냅니다. 또한 프록시의 기본 클러스터 내의 서버가 SIP 애플리케이션을 포함하지 않거나 메시지가 기본 클러스터 내에 설치된 애플리케이션 중 하나와 일치하지 않음을 나타낼 수도 있습니다.

  • 증상: "메모리 부족" 유형의 동작이 발생합니다.

    솔루션: 이 증상은 최대 힙 크기가 너무 낮게 설정되어 있어서 발생할 수 있습니다. SIP 애플리케이션은 세션이 장기간의 호출 보유 시간 동안 존재하므로 메모리를 매우 많이 이용할 수 있습니다. 512MB라는 최대 힙 크기가 SIP 통신량 워크로드에 충분한 메모리를 제공하지 못합니다. SIP 애플리케이션에 대한 최대 힙 크기를 최소 권장값인 768MB 이상으로 설정하십시오.

  • 증상: SIP 컨네이너에 SIP 요청을 전송할 때 "403 금지"라는 내용이 수신됩니다.

    솔루션: 일반적으로 이 증상은 수신된 SIP 요청을 처리할 적절한 SIP 애플리케이션을 찾지 못했음(메시지와 일치하는 일치 규칙이 없음)을 의미합니다.


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



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