• Artikel

Benutzerlast und MAPI-Operationen

[Dieses Thema beschäftigt sich mit einem besonderen Problem, das von Exchange Server Analyzer angezeigt wird. Die Problembehandlung sollte nur auf Systeme angewendet werden, auf denen Exchange Server Analyzer ausgeführt wird und dieses spezielle Problem auftritt. Exchange Server Analyzer (als kostenloser Download verfügbar) trägt remote Konfigurationsdaten von allen Servern in der Topologie zusammen und analysiert diese Daten automatisch. Der sich ergebende Bericht enthält ausführliche Informationen zu wichtigen Konfigurationskonflikten, möglichen Problemen und Produkteinstellungen, die nicht den Standardeinstellungen entsprechen. Indem Sie diese Empfehlungen beachten, können Sie bessere Leistung, Skalierbarkeit, Zuverlässigkeit und Betriebszeit erzielen. Weitere Informationen zum Tool sowie zum Download der aktuellsten Version finden Sie unter "Microsoft Exchange Analyzers" unter der Adresse https://go.microsoft.com/fwlink/?linkid=34707.]  

Letztes Änderungsdatum des Themas: 2006-10-17

Microsoft® Exchange Server Analyzer hat festgestellt, dass einige wenige MAPI-Operationen auf dem Server einen erheblichen Anteil zu der Benutzerlast auf dem Server beitragen. Dies wird durch Abfrage von Operationen festgestellt, die, bezogen auf die insgesamt verbrauchte CPU-Zeit, mehr als 4 Prozent der CPU-Zeit verbrauchen, die für die Verarbeitung aller RPC-Anforderungen aufgewendet wird.

Hauptursachen für MAPI-Vorgänge mit hoher CPU-Auslastung

Wenn Administratoren eine schlechte Leistung von Exchange Server untersuchen möchten, sollten sie prüfen, ob die durchschnittliche Postfachgröße auf Servern mit schlechter Leistung hoch ist. Sie sollten feststellen, ob einzelne Ordner zu groß sind (mehr als 5.000 Elemente im Posteingang, bei den gesendeten oder den gelöschten Objekten oder im Kalender). Große Ordner und das Anwachsen des Postfachs können zu höherer CPU- und E/A-Last führen. Eine Zunahme der Anzahl von Sichten für jeden Ordner kann viele MAPI-Operationen ebenfalls mit zusätzlichem Overhead belasten.

Ansichten

Viele der häufig verwendeten und lange laufenden MAPI-Operationen stehen im Zusammenhang mit Ansichten. Zwei bekante davon sind Restrict und FindRow. Diese Operationen dauern nicht immer lange. Wenn deren Leistung also ein Problem darstellt, sollten Sie den Grund dafür ermitteln. Beachten Sie zusätzlich zu den folgenden Gründen auch, dass die Wartezeiten für Operationen zunehmen, wenn es einen Ressourcen-Engpass (im Allgemeinen einen Datenträger- oder CPU-Engpass) gibt.

noteAnmerkung:
Manchmal resultiert hoher Aufwand durch TaskQ User Known in Verbindung mit Restrict oder FindRow. Dies liegt daran, dass ein Teil der Arbeit für diese Operationen in einer TaskQ durchgeführt wird und der Aufwand TaskQ User Known zugerechnet wird.

Einschränkungen

Die MAPI-Operation Restrict dient dazu, solche Objekte auszusuchen, die bestimmten Kriterien entsprechen. Der Server erstellt eine Ansicht, also eigentlich eine Tabelle mit zugehörigen Kriterien, die als Einschränkung bezeichnet wird. Wenn es die Ansicht mit einer passenden Einschränkung bereits gibt, verwendet der Server die vorhandene Ansicht, um die Benutzeranforderung zu erfüllen. Das Verwenden dieser Ansicht verursacht relativ geringen Aufwand, während das Erstellen einer neuen Ansicht ziemlich aufwändig ist. In der Standardeinstellung werden im Speicher nur 11 Ansichten pro Ordner zwischengespeichert. Wenn der Server aufgefordert wird, eine zwöfte Ansicht zu erstellen, löscht er die älteste Ansicht im Zwischenspeicher und erstellt eine neue. Ansichten erhöhen den Overhead aller Aktionen auf Elemente, auf die die Beschränkungen dieser Sicht zutreffen.

Findrow

Clientanwendungen verschieben mithilfe der MAPI-Vorgänge SeekRow oder FindRow den Cursor zwischen den Datensätzen in einer Ansicht. SeekRowLegt fest, um wie viele Reihen der Cursor verschoben werden soll, und ist in Bezug auf die CPU-Zeit sehr wenig aufwändig. FindRow ist ziemlich aufwändig, weil damit der Cursor zum ersten Element in einer nicht materialisierten (wird nicht zwischengespeichert) Ansicht verschoben wird, die die Beschränkungskriterien erfüllt. Anschließend wird die Ansicht verworfen, nachdem die Client-Anwendung den Vorgang abgeschlossen hat. Die endgültigen CPU-Kosten von FindRow hängen von der Komplexität der Beschränkung und davon ab, wieviele Reihen der Speicher überprüfen muss, bis er das erste den Kriterien entsprechende Objekt findet. Auf diese Weise sind sie schwach mit der Anzahl der Elemente im Ordner korreliert.

Der möglicherweise hohe Kosten in Verbindung mit Restrict und FindRow lassen diese beiden als gute Kandidaten für Zwischenspeicherungsmodus erscheinen, weil damit der Server von den Kosten befreit wird. Seien Sie sich bewusst, dass der von diesen beanspruchte hohe Anteil an der CPU-Leistung manchmal durch gemeinsame Kalender verursacht sein kann. In diesem Fall hilft auch Zwischenspeicherung nicht. Hoher Verbrauch von CPU-Zeit durch diese Operationen könnte darauf hindeuten, dass viele oder aufwändige Ansichten erstellt werden oder dass viele Objekte in den Ordnern sind.

Weitere Informationen

Weitere Informationen finden Sie in den folgenden Ressourcen zu Exchange Server: