Fehlerbehebung bei SIP-Anwendungen
Verwenden Sie diese Task, um Fehler in SIP-Anwendungen zu beheben.
Informationen zu diesem Vorgang
Verwenden Sie die folgenden grundlegende Informationen zur Fehlerbehebung beim SIP-Container, wenn Sie Probleme im Zusammenhang mit SIP-Anwendungen beheben möchten.
- Die durchschnittliche CPU-Belastung des Systems sollte nicht höher als 60 - 70 % sein.
- Der Container sollte nicht mehr als 70 % der reservierten VM-Heapspeichergröße verbrauchen. Stellen Sie sicher, dass das System genügend physischen Hauptspeicher besitzt, um die VM-Heapspeichergröße unterzubringen. Aufrufanzahl und Überschreitungen des Sitzungszeitlimits haben weitreichende Auswirkungen auf die Nutzung des Heapspeichers.
- Die maximale Dauer der Garbage-Collection, die von der VM durchgeführt wird, in der der Container ausgeführt wird, sollte nicht mehr als 500 ms betragen. Die durchschnittliche Dauer sollte unter 400 ms liegen. Zur Messung dieser Werte kann die ausführliche Garbage-Collection verwendet werden. Mit dem PMI-Viewer können GC-Dauer, Nutzung des Heapspeichers, Anzahl der aktiven Sitzungen usw. in grafischer Form angezeigt werden.
Vorgehensweise
- Überprüfen Sie die Empfangsports in der Konfiguration.
- Verwenden Sie den Befehl netstat –an, um die Empfangsports anzuzeigen.
- Prüfen Sie, ob virtuelle Hosts definiert sind.
- Prüfen Sie, ob Hostaliasnamen definiert sind.
- Ist eine Anwendung installiert? Wenn ja, ist sie gestartet?
- Wenn Sie eine Proxy-Konfiguration haben, ist ein Standardcluster konfiguriert? Wenn Proxy und Server auf derselben Maschine ausgeführt werden, liegt ein Portkonflikt vor?
Ergebnisse
- Symptom: Es finden sehr viele Neuübertragungen statt, und die CPU fällt regelmäßig auf null, oder eine ThreadPoolQueueIsFullException
wird in den Protokollen angezeigt.
Lösung: Dieses Symptom weist gewöhnlich auf ein DNS-Problem hin, das durch Reverse-DNS-Lookup-Operationen verursacht wird und mit einem Tool wie Ethereal bestätigt werden kann. Wenn Datenerfassungen im Netz durchgeführt und viele DNS-Anfragen gesendet werden, die eine IP-Adresse enthalten und in der Antwort einen Hostnamen empfangen, könnte dies das Problem sein. Stellen Sie sicher, dass nscd aktiv ist, wenn Sie auf einer HP- oder einer anderen Plattform arbeiten, die Caching für den Namensservice erfordern. Die Plattform Microsoft Windows erfordert kein Caching für den Namensservice. Eine andere Lösung ist das Hinzufügen von Hostnamen zur Datei "/etc/hosts".
- Symptom: Es finden viele Neuübertragungen statt, und die CPU steigt regelmäßig auf 100 %.
Lösung: dieses Symptom weist gewöhnlich auf ein Problem bei der Garbage-Collection hin, das durch Aktivieren der ausführlichen Garbage-Collection (über die Administrationskonsole) und Überprüfen der Dauer der Garbage-Collection-Zyklen verifiziert werden kann. Zur Lösung dieses Problems aktivieren Sie die Garbage-Collection nach Objektalter, indem Sie das optionale JVM-Argument -Xgcpolicy:gencon definieren.
- Symptom: Es finden sehr viele Neuübertragungen statt, die Garbage-Collection nach Objektalter ist aktiviert, und die CPU steigt über längere Zeit hinweg auf 100 %.
Lösung: Dieses Symptom weist gewöhnlich darauf hin, dass SIP-Sitzungsobjekte nicht ungültig gemacht werden und auch nach langer Zeit keine Zeitlimitüberschreitungen auftreten. Eine Lösung ist, das Sitzungszeitlimit in der Datei sip.xml der Anwendung auf einen kleineren Wert zu setzen. Die Anwendung kann dieses am effizientesten lösen, indem sie bei Beendigung des Dialogs (d. h. nach dem Empfang von BYE) einen Invalidierungsaufruf für die Sitzung absetzt. Der folgende Eintrag in der Datei SystemOut.log gibt das Sitzungszeitlimit für jede im Container installierte Anwendung an:
SipXMLParser 3 SipXMLParser getAppSessionTTL Setting Expiration time: 7 Minutes, For App: TCK back-to-back user agent”
Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM® i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen. - Symptom: Es werden sehr viele Nachrichten vom Typ "480 Service Not Available" vom Container empfangen,
wenn neue INVITE-Nachrichten an den SIP-Container gesendet werden.
Außerdem sehen Sie die folgende Nachricht in der Datei SystemOut.log, wenn sich der Server in diesem Zustand
befindet: "LoadManager E LoadManager warn.server.oveloaded".
Lösung: Dieses Problem ist gewöhnlich darauf zurückzuführen, dass eine der konfigurierbaren Metriken des SIP-Containers überschritten wurde. Dazu gehören der Wert für die maximale Anzahl an Anwendungssitzungen und der Wert für die maximale Anzahl an Nachrichten pro Zeitraum für die Durchschnittsermittlung. Sie können dieses Problem beheben, indem Sie höhere Werte festlegen.
- Symptom: Es werden sehr viele Nachrichten erneut gesendet, und sehr viele Aufrufe werden nicht beendet und von Ausnahmen des Typs
OutOfMemory begleitet, die in der Datei SystemErr.log aufgezeichnet werden.
Lösung: Dieses Verhalten bedeutet gewöhnlich, dass die Größe des VM-Heapspeichers, die dem Container zugeordnet ist, nicht ausreicht und dass ein höherer Wert festgelegt werden muss. Sie können diesen Wert über die Administrationskonsole anpassen.
- Symptom: Sie empfangen eine Nachricht vom Typ "503 Service Unavailable", wenn Sie eine
SIP-Anforderungen an einen SIP-Proxy senden.
Lösung: Dieses Verhalten bedeutet gewöhnlich, dass im Proxy kein Standardcluster (bzw. keine Routing-Regel im Cluster, die der Nachricht entspricht,) definiert ist. Dies kann auch passieren, wenn der SIP-Proxy zwar ordnungsgemäß konfiguriert ist, aber die Back-End-SIP-Container gestoppt oder abgestürzt sind.
- Symptom: Sie empfangen eine Nachricht vom Typ "404 Not Found", wenn Sie eine SIP-Anforderung an einen
SIP-Proxy senden.
Lösung: Dieses Verhalten bedeutet gewöhnlich, dass kein virtueller Host für die Container im Standardcluster definiert ist. Es könnte aber auch ein Hinweis darauf sein, dass die Server im Standardcluster des Proxy keine SIP-Anwendung enthalten oder dass die Nachricht keiner der Anwendungen entspricht, die im Standardcluster installiert sind.
- Symptom: Es treten abnormale Speicherbedingungen auf.
Lösung: Dieses Verhalten kann ein Hinweis darauf sein, dass die maximale Größe des Heapspeichers zu klein gewählt worden ist. SIP-Anwendungen können eine beträchtliche Menge an Speicher belegen, weil die Sitzungen für eine lange Zeit aufrecht erhalten werden. Die maximale Heapspeichergröße von 512 MB reicht für die SIP-Workload nicht aus. Setzen Sie die maximale Heapspeichergröße für SIP-Anwendungen auf den empfohlenen Mindestwert von 768 MB (oder höher).
- Symptom: Sie empfangen eine Nachricht vom Typ "403 Forbidden", wenn Sie eine SIP-Anforderung
an einen SIP-Container senden.
Lösung: Gewöhnlich bedeutet dieser Fehler, dass keine geeignete SIP-Anwendung für die Bearbeitung der empfangenen SIP-Anforderung gefunden wurde (keine Zuordnungsregel, die der Nachricht entspricht).