none
CRM 4.0 Async Service Performance RRS feed

  • Frage

  • Hallo,

    ich habe folgendes Problem. Die Performance des AsyncService ist unterirdisch.
    Das eingesetzte System ist ein Windows Server 2008 64 Bit (8 Gbyte RAM) mit CRM 4.0 Rollup Update 5, SQL Server 2005 SP3 alles auf derselben Maschine.

    In letzter Zeit kommt es immer öfters vor, dass der Async Service lange zum
    abarbeiten der Aufträge braucht.
    Die AsyncOperationBase hat derzeit insgesamt 869557 Datensätze.
    Wir haben die SQL Skripte zum löschen sowie zur Index erstellung bereits
    abgearbeitet und lassen diese 1 mal die Woche laufen.

    Es wird viel mit Workflows und Workflow Aktivitäten gearbeitet.
    Bei einem letzten Import Update von 3900 Kontakten mit dem gleichzeitigen
    Aufruf von 3 Workflows, brauchte das System von 17:00 bis 14:00 des
    darauffolgenden Tages zur Abarbeitung. Zwischenzeitlich wurde zwar die
    Aktivierung von Workflows noch aktzeptiert, der eigentliche Workflow jedoch
    nicht gestartet, da keine neuen Systemjobs mehr erzeugt wurden.
    Ein Server Neustart brachte nur kurzfristig eine Verbesserung jetzt ist das
    Verhalten dasselbe wie vorher.

    Hat jemand Ideen, woran es liegen könnte? Tips wonach man sehen sollte/könnte?

    Die Auslastung des Systems liegt im normalen Rahmen während der Abarbeitung
    der Systemjobs liegt der AsyncService bei ca. 25 CPU Last und der W3WP
    zwischenzeitlich bei ca. 17.

    Das Problem tritt auf unserem Entwicklungssystem nicht auf. Daher würde ich
    die Ursache Workflows fast ausschließen wollen.
    Das Eventlog zeigt keine Fehler, SQL Log sagt nichts aus, im IIS Log steht auch nichts, Tracing von CRM bringt keinerlei Fehler.
    Die Workflows werden auch nicht abgebrochen es dauert nur seeeeeeeeeehr lange bis alle endlich abgearbeitet sind.
    Das System an sich arbeitet sehr performant, aufrufen von Berichten, speichern und anlegen sowie Ändern von Entitäten ist kein Problem. Nur Businesslogik schläft...

    Gruß Micha

    Donnerstag, 1. Oktober 2009 13:22

Antworten

Alle Antworten

  • Hallo Micha,

    hast du mal versucht ob http://support.microsoft.com/kb/968520 eine Linderung bringt?
    Donnerstag, 1. Oktober 2009 14:19
  • Hallo cKeller,

    ja haben wir, die Async Table ist anschließend von über 3 Millionen auf knapp 870000 Datensätze runter.
    Diese müssen aber drinbleiben da wir eine History von knapp 3 Monaten rückwärts brauchen.

    Was komisch ist, wenn ich den Async Service Prozess beende und ihn neustarte dann rennt dieser für einige Zeit wieder im "normalen" Tempo.
    Irgendwo verschluckt er sich dann nach ein paar Minuten.

    Weitere Vorschläge?

    Donnerstag, 1. Oktober 2009 14:35
  • Hallo ckeller,

    ja das Skript haben wir bereits laufen lassen. Wie oben beschrieben wurde die Async Table von ca. 3,5 Millionen auf 870000 Datensätze verkleinert.
    Bei MS stand mal was das die Performance erst bei einigen Millionen Datensätzen runtergeht?

    Komisch ist auch, dass der Async Service nach jedem Neustart für einige Zeit wieder normal arbeitet und anschließend wieder in den Dornröschen Schlaf verfällt.
    Andere Vorschläge?
    Donnerstag, 1. Oktober 2009 15:09
  • Hallo Michael,

    welches RU habt ihr denn installiert? Das Problem ist seit dem RU 3 oder 4 behoben, bedarf aber einem einmaligen manuellen Eingriff in die Registry, der gerne vergessen wird.
    Siehe: http://support.microsoft.com/kb/974896/

    Welche Historie benötigt ihr in der AsyncTable? Wann welcher Workflow gelaufen ist?
    Viele Grüße

    Michael Sulz
    axcentro GmbH
    MVP für Microsoft Dynamics CRM
    Donnerstag, 1. Oktober 2009 15:16
  • Hallo Michael,

    schande über mich: ich lese gerade im ersten Post, dass du Skripts aus dem KB-Artikel ja schon anwendest... Sorry.

    Handelt es sich um ein dauerhaftes Problem oder tritt es nur beim Import auf (wie im ersten Post beschrieben)?
    Sind die Workflows mit CRM-Boardmitteln erstellt oder sind eigene Aktivitäten eingebaut worden? Rufen sich die Workflows gegenseitig auf?
    Sind evtl. Plugins im Spiel?

    Die Tatsache, dass der Dienst nach einem Neustart schnell ist und dann (immer) langsamer wird könnte z.B. auch auf eine Endlosschleife in Plugins oder WF-Aktivitäten hindeuten.
    Donnerstag, 1. Oktober 2009 15:22
  • Hallo Michael,

    wir haben das RU 5 installiert, die Registry fixes sind nicht installiert, da wir die Einträge manuell per Bulkdelete bzw. SQL-Job entfernen müssen.
    Wir brauchen die History von mindestens 4 Monaten rück. Und bei den Registry Werten wird gleich alles rausgehauen.

    Daher rufen wir das SQL Skript aus dem KB Artikel 1 mal die Woche auf und lassen auch die Indizies etc. aktualisieren.
    Nachtrag: Wir brauchen die History wann welcher Workflow gelaufen ist und ob es einen Systemjob gab, der ihn aufrufen sollte. Also den WorkflowExpansionTask, um evtl. Fehler nachvollziehen zu können.

    Donnerstag, 1. Oktober 2009 15:27
  • Hallo ckeller,

    das Problem tritt erst seit 2 Monaten auf und wird schlimmer.

    Es tritt nicht nur beim Import auf, beim Import werden nur gleich mehrere Workflows ausgeführt.
    Es sind unterschiedliche Workflows 1 mit CRM Boardmitteln und 2 mit eigenen Workflowaktivitäten. Die Workflows rufen sich nicht gegenseitig auf sondern warten auf die Aktualisierung eines bzw. mehrerer Attribute bzw. Neuerstellung eines Kontakts. Sie führen dann Aktualisierungen an anderen Entitäten durch, die wiederum keine Aktualisierung des Kontakts auslösen oder schreiben Nachrichten in eine MessageQueue.


    Je mehr Datensätze zum Abarbeiten in der Async Table vorhanden sind desto mehr Datensätze werden auch nach Neustart abgearbeitet... Komischerweise...

    Es waren ca. 9000 Neustart anschließend ca. 6000
    Neustart anschließend 3000
    Neustart anschließend 2200.

    Tracen von CRM ergab mal anfänglich 1 Fehlermeldung.
    "

    Application |User: 00000000-0000-0000-0000-000000000000 |Level: Warning |
    RelatedInformationControl.AddTipsCategory
    at RelatedInformationControl.AddTipsCategory(Context context, String
    entityName, String contextName)
    at RelatedInformationControl.CheckForContext(Control control, String
    formType, Int32 formEntityTypeCode, AppForm form)
    at RelatedInformationControl.CheckForContext(Control control,
    FormDescriptor formDescriptor, AppForm form)
    at CrudForm.BuildFormModel(FormDescriptor formDescriptor)
    at CustomizableForm.Execute(Entity entity, String formType)
    at CustomizableForm.Execute(Entity entity)
    at BasicActivityPage.ConfigureForm()
    at SchedulableActivityBasePage.ConfigureForm()"



    Die taucht derzeit aber nicht mehr auf und hat denke ich mit dem Problem auch nichts zu tun.

    Donnerstag, 1. Oktober 2009 15:38
  • Hallo Michael,

    kannst du Probleme mit DNS, Wartezeiten beim Schreibzugriff auf die MessageQueues, etc. ausschließen? Handelt es sich um Workflows die lange laufen?
    Hast du dir die Systemaufträge im CRM angesehen? Sind hier viele Aufträge mit Status 'Auf Ressourcen wird gewartet', 'Es wird gewartet' oder 'In Bearbeitung' vorhanden?
    Evtl. sind da irgenwelche Leichen dabei, die Ressourcen blockieren.

    Du sagst dass die Probleme im Entwicklungssystem nicht auftreten. Ist es identisch mit dem Produktivsystem (Datenmenge, Versionsstände, Anbindung an andere Systeme)?
    Donnerstag, 1. Oktober 2009 18:55
  • Hallo ckeller,

    Probleme mit DNS kann ich ausschließen, Wartezeiten beim Schreibzugriff njein. Das könnte ich mal prüfen. Ich sehe leider die Messages in der Warteschlange nicht, da diese von dort an einen anderen Rechner ausgeliefert werden. Bei den diversen Tests, wurden die Messages aber soweit ich das sehen kann auf dem Zielrechner immer zeitnah, fast synchron übermittelt.
    Die Systemaufträge im CRM zeigen sehr viele "In Bearbeitung". Die werden ja auch in irgendeiner Reihenfolge abgearbeitet. Sprich nach X Zeit sind auch alle ohne Fehler abgeschlossen. Nur bis dahin dauert es viel zu lange. Er startet ja dann für 3900 Kontakte 3 Workflows, also pro Kontakt 3 Systemjobs "WorkflowExpansionTask" und dann anschließend die Workflows.

    Das Entwicklungssystem ist von der Hardware nicht identisch. Das Entwicklungssystem ist nicht so gut ausgestattet wie das Life-System. 2 Kern gegen 8 Kern CPU.
    Der SQL Server läuft im Entwicklungssystem auch nicht auf derselben Maschine. Die RU vom CRM sind identisch, alle Plugins, WF-Aktivitäten und Customizations auch.

    Die Datenmenge ist nicht 100% identisch. Aber die Tests die ich mal ausgeführt habe wurden im Test-System mit größeren Datenmengen 11400 Kontakte durchgeführt. Das System hat dann zwar knapp 2h gebraucht um alles abzuarbeiten aber es lief gut durch.



    Freitag, 2. Oktober 2009 06:16
  • Hallo Michael,

    hast du mal genauere Performanceprüfungen auf dem Lifesystem durchgeführt, um den vermutlichen Flaschenhals zu finden?
    Es gibt im Performancemonitor spezielle Einträge extra für das CRM.
    Du solltest auch einmal die Performance der Festplatte, z.B. die Warteschlangenlänge und des SQL-Servers überprüfen.

    Eine entsprechende Beschreibung für die CRM Einträge findest du hier:
    http://rc.crm.dynamics.com/rc/regcont/en_us/OP/articles/crm_perf_counters.aspx
    Viele Grüße

    Michael Sulz
    axcentro GmbH
    MVP für Microsoft Dynamics CRM
    Freitag, 2. Oktober 2009 06:39
  • Hallo Michael,

    danke für den Hinweis. Das werde ich mal tun. Die Performance der Festplatte inklusive Warteschlange hatte ein Kollege getestet. Die war ok.
    Freitag, 2. Oktober 2009 08:20
  • So wie aussieht, ist die async Table immer noch zu groß.
    Derzeit waren es ca. 890000 Datensätze. Unser Testsystem gab bei knapp 440000 Datensätzen so langsam den Geist auf.

    Ich finde recht armselig.
    Montag, 12. Oktober 2009 11:04