[Gelöst] AX Clients frieren für eine bestimmte Zeit x ein

Hallo zusammen,

wir haben folgendes Problem:

In unregelmäßigen Abständen frieren alle Clients, welche mit einem AOS verbunden sind für eine nicht gleiche Zeit ein. In diesem Zeitraum kann man sich zudem nicht mit dem AOS verbinden und wartet für den Zeitraum des "Hängens" in einem weißen Bildschirm, bis der Hänger vorbei ist.

Dieses Verhalten taucht in unregelmäßigen Abständen auf und ist aktuell nicht reproduzierbar.

Kennt jemand evtl. ein derartiges Verhalten bzw. kann jemand Ansätze zur Lösungsfindung liefern?

Unsere Umgebung sieht grob so aus:
Dynamics AX 2009 RU 4

2x AOS 64bit für Clientsitzungen
2x AOS 64bit für Stapelverarbeitung

Falls sonst noch offene Fragen sind bitte einfach nachfragen.

Vielen Dank im Voraus für die Hilfe.

Zuletzt geändert von matgo am 24. Februar 2011 10:30, insgesamt 1-mal geändert.

Hallo,

das könnte ganz unterschiedliche Ursachen haben. Das Einfrieren zeigt ja häufig, dass die Sitzung auf eine Antwort der Datenbank wartet.
Ich kenne ein ähnliches Problem, was aus "hängenden" Statements am SQL-Server resultierte, die unverhältnismäßig lange liefen. Wurden die Statements direkt am SQL-Server ausgeführt, war die Ausführungsgeschwindigkeit normal. In dieser Zeit wurden parallel keine oder nur sehr langsam andere Prozesse ausgeführt. Neuanmeldungen waren nicht mehr möglich.

Es kann aber auch ein Problem im Netzwerk vorliegen.
Aber für den Anfang würde ich raten, zuerst mit der Analyse der Datenbank zu beginnen, wenn dies noch nicht gemacht wurde.

Gibt es denn in den Ereignisprotokollen Meldungen des AOS oder der Datenbank?
Wie ist während des Stillstands der Zustand des Datenbankservers?
Sind während des Stillstands die Sitzungen aller AOS betroffen?
Wurde der Datenbankserver länger nicht mehr neu gestartet?

Gruß
Ina

Hallo,

ich kann mich Ina nur anschließen. Das Problem kann durch mehrere Dinge ausgelößt werden.
So aus dem Stand hört es sich aber für mich an, als wenn der/die AOS Server entweder kurzzeitig überlastet sind oder diese auf die Datenbank warten.
Aber auch Netzwerkprobleme kann man nicht generell ausschließen.

Normlerweise sollte im Ergeignisprotokoll der AOS-Server etwas zu finden sein, was schon mal einen groben Anhaltspunkt liefert.

Ich persönlich würde als erstes einige Logfiles anschalten um das Problem genauer analysieren zu können (z.B. Deadlocks, Lange Abfragen, etc.)
Auch ein Performanceprotokoll der AOS-Server (Perfromancemonitor) sollte nicht schaden.

Wenn es nun erneut zu den beschriebenen Problemen kommt, kann man entsprechend der Uhrzeit in den Logs nachsehen, was das System zu diesem Zeitpunkt gemacht hat und dann weitere Schritte einleiten.

Hallo zusammen,

vielen Dank für die Antworten.

Gibt es denn in den Ereignisprotokollen Meldungen des AOS oder der Datenbank?

Auf den AOSen erscheinen keine spezifischen Meldungen im Eventlog. Gibt es hier Möglichkeiten zusätzliche Events zu loggen?

Wie ist während des Stillstands der Zustand des Datenbankservers?

Den Zustand des Datenbankservers werden wir genauer beobachten. Augenscheinlich gab es keine Besonderheiten/Ausfälle.

Sind während des Stillstands die Sitzungen aller AOS betroffen?

Beim Stillstand sind alle Sitzungen eines AOS betroffen. Aber die einzelnen AOSe zu unterschiedlichen Zeitpunkten.

Wurde der Datenbankserver länger nicht mehr neu gestartet?

DB-Server wurde schon seit mehreren Monaten nicht neu gestartet. Folgend als evtl. Ansatzpunkt die Serverdaten des SQL-Servers ( SQL Server 2008 SP 1, 136 GB RAM, intern 2x 73 GB SAS (RAID 1), 4x 6Core Intel Xeon E7450 2,4 GHz )

Es kann aber auch ein Problem im Netzwerk vorliegen.

- Das Netzwerkmonitoring lieferte bisher folgende Ergebnisse:
Generelle Netzwerklatenzzeiten zwischen AOS und SQL Server liegen bei ~1ms
Antwortzeiten auf Ports des SQL Server <200ms
Welche weiteren Schritte könnten hier noch zur Fehlerfindung beitragen?

Ich persönlich würde als erstes einige Logfiles anschalten um das Problem genauer analysieren zu können (z.B. Deadlocks, Lange Abfragen, etc.)

Auf welcher Ebene sollte dies stattfinden? Tracing auf AX-Ebene und Auswertung beispielsweise mit dem AX-Traceparser oder auf Datenbankebene?
Was sind hier Deine empfohlenen Einstellungen zur Durchführung eines Loggings? Hier kommen doch recht schnell große Datenmengen an Logfiles zusammen.

Den Performancemonitor für die AOS-Server werden wir aktivieren und eine Rückmeldung geben.


Viele Grüße Mathias

Ich persönlich würde als erstes einige Logfiles anschalten um das Problem genauer analysieren zu können (z.B. Deadlocks, Lange Abfragen, etc.)

Auf welcher Ebene sollte dies stattfinden? Tracing auf AX-Ebene und Auswertung beispielsweise mit dem AX-Traceparser oder auf Datenbankebene?
Was sind hier Deine empfohlenen Einstellungen zur Durchführung eines Loggings? Hier kommen doch recht schnell große Datenmengen an Logfiles zusammen.

Dass beim Einschalten der Logfiles schnell sehr große Datenmengen zusammenkomen ist leider so, da man ja nicht sagen wann es wiedre zu dem Problem kommt.

Ich würde zuerst nur Logfiels für Deadlocks und lange Abfragen anschalten (auf AX-Ebene).

Ist dir bekannt, ob es Reports oder Funktionen gibt, welche sehr lange laufen und/oder große Berechnungen ausführen?
Es könnte sein, das ein User z.B. einen Report aufruft, welche komplexe Berechnungen ausführt uns somit den AOS kurzfristig "blockiert".
Auch denkabr wäre es, wenn eine komlexe Funktion durch einen Benutzer auf dem AOS ausgeführt wird, dass diese den AOS "blockiert" (z.B. ein komplexer PPS-Lauf).

Hallo,

aktuell gibt es leider noch keinen Erfolg zu vermelden.
Es konnte auch keine parallele zwischen Tätigkeiten der Benutzer und den "Hängern" gezogen werden.
Da sämtliche Logs keine Auffälligkeiten zeigten liegt der Fall als SupportRequest bei Microsoft.

Falls es Neuigkeiten gibt melde ich mich.
Falls jemandem noch etwas einfällt sind wir für alle Hinweise offen.

Gruß

Hallo,

Nutzt ihr das AIF? Wenn der IIS "unscharfe" Abfragen an den AOS übergibt kommt es auf meinen Testsystemen zu einem ähnlichen Verhalten. Einzige Möglichkeit ist dann den AOS-Dienst auf der betroffenen Maschine neu zu starten, oder die Wartezeit "auszusitzen".

Gruß
Holger

Hallo zusammen,

vielen Dank noch einmal für die Hilfe.
Der Grund für das Verhalten war, wie es scheint, ein Absturz eines AOS-Servers, der beim Absturz wohl etwas im Shared-Applikations-Pfad "zerschossen" hat. Der Absturz hatte am Vortag des ersten direkten Auftretens stattgefunden.
Nach dem Löschen der aoi-Datei und dem Neu-Kompilieren der Anwendung verhält sich AX bisher wieder "normal". Falls es noch mehr detaillierteres zu berichten gibt melde ich mich noch einmal.

Viele Grüße

Vielen Dank für deine Rückmeldung.
Es ist immer gut zu wissen, was für Fehler auftreten können.

Viele Grüße
Ina

Hi Mathias,

...Der Grund für das Verhalten war, wie es scheint, ein Absturz eines AOS-Servers...

wenn sich das Problem gelöst hat, könntest du bitte auch dieses Thema entsprechend auf gelöst setzen (siehe meine Fußnote)?

Danke.

Hallo Axel,

danke für den Hinweis. Ist erledigt.

Gruß Mathias