Charge des utilisateurs et opérations MAPI
[Cette rubrique est destinée à résoudre un problème spécifique signalé par l'outil Exchange Server Analyzer Tool. Ne l'appliquez qu'à des systèmes sur lesquels l'outil Exchange Server Analyzer Tool a été exécuté et qui ont rencontré ce problème spécifique. L'outil Exchange Server Analyzer Tool, disponible sous forme de téléchargement gratuit, collecte à distance des données de configuration de chaque serveur de la topologie et les analyse automatiquement. Il génère un rapport qui détaille les problèmes de configuration importants, les problèmes potentiels et les paramètres du produit qui ne sont pas définis par défaut. En suivant ces recommandations, vous pouvez accroître les performances, l'évolutivité, la fiabilité et la disponibilité. Pour plus d'informations sur l'outil ou pour télécharger les versions les plus récentes, consultez la rubrique sur les analyseurs Microsoft Exchange à l'adresse https://go.microsoft.com/fwlink/?linkid=34707.]
Dernière rubrique modifiée : 2006-10-17
L'outil Microsoft® Exchange Server Analyzer Tool a déterminé que quelques opérations MAPI sur le serveur contribuent à un pourcentage considérable de la charge des utilisateurs du serveur. Pour en arriver à cette conclusion, il recherche les opérations qui consomment plus de 4 % du temps processeur par rapport au temps processeur consacré au traitement de toutes les demandes RPC.
Causes courantes des opérations MAPI à pourcentage de temps processeur élevé
Un administrateur qui recherche la cause de faibles performances d'Exchange Server doit vérifier si la taille moyenne des boîtes aux lettres est élevée sur les serveurs qui offrent de faibles performances. Il doit déterminer si des dossiers individuels sont excessivement volumineux (plus de 5 000 éléments dans les dossiers Boîte de réception, Éléments envoyés, Éléments supprimés ou Calendrier). Les dossiers volumineux et l'augmentation de taille des boîtes aux lettres peuvent provoquer une hausse de la charge d'E/S et du processeur. L'augmentation du nombre de vues pour chaque dossier peut également allonger le temps de traitement de nombreuses opérations MAPI.
Vues
De nombreuses opérations MAPI courantes qui nécessitent beaucoup de temps sont liées aux vues. Parmi les plus évidentes, citons Restrict et FindRow. Ces opérations ne nécessitent pas toujours beaucoup de temps et si leur exécution pose problème, vous devez comprendre pourquoi. Notez également qu'en plus des raisons suivantes, dès qu'il existe un goulot d'étranglement pour les ressources (généralement au niveau du disque ou du processeur), les latences des opérations augmentent.
.gif "note") Remarque : |
|---|
| Parfois, le coût de TaskQ User Known peut être élevé avec les opérations Restrict ou FindRow. En effet, une partie du travail pour ces opérations est effectué dans un TaskQ et le coût est attribué à TaskQ User Known. |
Restrictions
L'opération MAPI Restrict permet de sélectionner des éléments correspondant à des critères particuliers. Le serveur crée une vue qui est effectivement une table avec des critères associés appelés restrictions. Si la vue qui a une restriction correspondante existe déjà, le serveur utilise la vue existante pour répondre à la demande de l'utilisateur. L'utilisation de cette vue engendre relativement peu de frais, contrairement à la création d'une nouvelle vue, qui est relativement chère. Par défaut, la banque d'informations ne met en cache que 11 vues pour chaque dossier. S'il est demandé au serveur de créer une onzième vue, celui-ci supprime la vue mise en cache la plus ancienne et crée une nouvelle vue. Les vues ajoutent du temps de traitement à toutes les actions effectuées sur les éléments qui correspondent aux restrictions des vues.
Findrow
Les applications clientes utilisent les opérations MAPI SeekRow ou FindRow pour déplacer le curseur entre les lignes d'une vue. L'opération SeekRow spécifie le nombre de lignes sur lesquelles déplacer le curseur et engendre très peu de frais en termes de temps processeur. L'opération FindRow est assez chère car elle déplace le curseur vers le premier élément d'une vue non matérialisée (non mise en cache) qui correspond aux critères de restriction, puis ignore la vue une fois que l'application cliente a terminé l'action. Le coût processeur final de l'opération FindRow dépend de la complexité de la restriction et du nombre de lignes que la banque d'informations doit passer en revue avant de trouver le premier élément qui correspond aux critères et est vaguement en corrélation avec le nombre d'éléments dans le dossier.
Le coût élevé pouvant se produire avec les opérations Restrict and FindRow en fait des candidats adéquats pour l'exécution du mode mis en cache, qui supprimerait le coût du serveur. Sachez que, parfois, le pourcentage de processeur élevé consommé par ces opérations peut simplement être provoqué par des calendriers partagés, auquel cas le mode mis en cache n'aiderait pas. Une consommation élevée du pourcentage de temps processeur par ces opérations peut indiquer un grand nombre de créations de vues, de vues chères ou d'éléments de dossiers volumineux.
Pour plus d'informations
Pour plus d'informations, voir les ressources Exchange Server suivantes :
- Guide des performances et de l'évolutivité d'Exchange Server 2003 (https://go.microsoft.com/fwlink/?LinkId=47576)
- Performances d'Exchange Server 2003 : 10 choses à savoir (https://go.microsoft.com/fwlink/?LinkID=56460).