Dépannage des problèmes de traitement lent de demande RPC
Dernière rubrique modifiée : 2008-11-12
Lorsque vous utilisez Microsoft Office Outlook en mode MAPI, Outlook exécute les opérations du client en tant que RPC (remote procedure calls) entre le client et le serveur. Si l'utilisateur travaille en mode connexion, ces RPC se produisent de façon synchrone. Tout retard de réponse du serveur à ces demandes synchrones affecte directement l'expérience de l'utilisateur et la réactivité d'Outlook. En revanche, la plupart des opérations effectuées lorsque vous travaillez en mode mis en cache se produisent sur la copie locale de la boîte aux lettres de l'utilisateur ou sont envoyées au serveur sous la forme de RPC asynchrones (en arrière-plan). Généralement, les RPC asynchrones n'affectent pas la réactivité de l'expérience globale du client Outlook lui-même.
Lorsque le service de banque d'informations de Microsoft Exchange démarre pour la première fois sur un serveur, il s'enregistre avec le service RPC et reçoit une allocation de 500 threads RPC. Les clients se connectent et déconnectent au threads individuels lorsqu'ils effectuent leurs opérations quotidiennes. Cela inclut la lecture et l'envoi de courriers, la création de rendez-vous et tâches et l'affichage de calendriers. Le compteur de performance des demandes MSExchangeIS\RPC indique combien de threads sont actuellement en utilisation (« détenus » par des clients). Le compteur de performance MSExchangeIS\Opérations RPC/s reflète le nombre d'opérations que le serveur a reçu lors de la seconde précédente. Si le nombre de demandes RPC augmente régulièrement au fil du temps, cela montre clairement que le serveur ne peut pas traiter les opérations client assez rapidement. Lorsque le compteur de performance des demandes MSExchangeIS\RPC atteint 500, tous les threads RPC sont utilisés, et les clients ne pourront pas soumettre de nouvelles demandes tant que toutes les opérations sur un thread existant n'ont pas été réalisées et le thread libéré.
Le compteur de performance MSExchangeIS\Opérations RPC/sec reflète une charge de travail courrante du serveur, c’est pourquoi il est extrêmement utile pour identifier les goulots d'étranglement dans le traitement d’Exchange, en particulier si les administrateurs connaissent les valeurs attendues pour leur serveur durant les périodes de pic et les opérations normales. Les serveurs qui présentent de résultats lorsqu'ils reçoivent 300 opérations RPC par seconde peuvent rencontrer des difficultés lors du traitement de 1 500 opérations RPC par seconde. Les administrateurs devraient toujours consulter le compteur MSExchangeIS\Opérations RPC/s et mettre en corrélation les changements de cette valeur avec les changements dans le nombre de demandes RPC.
Si les clients se plaignent de mauvaises performances d'Exchange, et si les demandes MSExchangeIS\RPC et les MSExchangeIS\Opérations RPC/s sont tous les deux bas ou à zéro, cela montre clairement que le goulot d'étranglement ne se trouve pas sur le serveur lui-même. Le problème est ici dû à un élément externe au serveur empêchant l'information d'atteindre le serveur. Les administrateurs devraient examiner les performances d'Active Directory et du réseau, la configuration client et d'autres domaines qui peuvent empêcher les données d'atteindre le serveur Exchange.
Si les demandes MSExchangeIS\RPC continuent à augmenter alors que les MSExchangeIS\Opérations RPC/s restent faibles, alors cela signifie que le serveur ne peut gérer la charge de travail existante. Les administrateurs devraient vérifier les composants matériels, y compris la mémoire physique, le stockage et les capacités du processeur, ou diminuer le nombre d'utilisateurs sur le serveur.
Si les demandes MSExchangeIS\RPC continuent à augmenter régulièrement alors que les MSExchangeIS\Opérations RPC/s diminuent régulièrement, alors cela signifie que le serveur Exchange est la source du goulot d'étranglement. Dans cette situation, quelque chose empêche la banque d'informations de réaliser les opérations RPC et les threads RPC associés restent alloués. Au fur et à mesure que des threads sont alloués, le serveur dispose de moins en moins de threads pour les nouvelles opérations, et le nombre de nouvelles opérations baisse. Si le serveur finit par atteindre 500 demandes RPC en attente, les nouvelles opérations RPC seront refusées. C'est en général causé soit par des ressources physiques de stockage insuffisantes (mémoire ou disque) ou un problème de processus à l'intérieur de la banque d'informations ou d'un composant intégré (antivirus, journalisation, etc.)
Le tableau suivant inclut les compteurs les plus importants pour le dépannage et l'isolation des problèmes de traitement des RPC.
Compteurs de performance pour le traitement des RPC
| Compteur | Valeurs attendues |
|---|---|
MSExchangeIS\Demandes RPC Indique le nombre de demandes RPC MAPI en cours traitées par le service de banque d'informations de Microsoft Exchange. Le service de banque d'informations de Microsoft Exchange peut prendre en charge jusqu'à 500 demandes RPC simultanément avant de rejeter les nouvelles demandes client. |
|
MSExchangeIS\Latence RPC moyenne Indique la latence moyenne, exprimée en millisecondes, de toutes les opérations RPC des 1 024 derniers paquets RPC. Consultez la rubrique « limitation du client » plus loin de cette rubrique pour plus d'informations sur les effets sur les clients lorsque la latence moyenne RPC générale du serveur augmente. |
|
MSExchangeIS\Opérations RPC/s Indique le nombre actuel d'opérations RPC qui soumises à la banque d'information chaque seconde. |
|
MSExchangeIS\Nombre de paquets RPC lents Indique le nombre de paquets RPC parmi les 1024 derniers paquets qui ont présenté des latences supérieures à deux secondes. |
|
Contrôle côté client
Microsoft Office Outlook 2003 et Office Outlook 2007 incluent des fonctionnalités de contrôle côté client. Le contrôle côté client est utilisé pour trouver des erreurs client et des problèmes de latence. Vous pouvez activer les contrôle côté client sur un serveur Exchange en modifiant le registre du serveur. Lorsqu'il est activé, Outlook 2007 et les clients Outlook 2003 envoient des données au serveur en se basant sur le statut et l'état de la connexion, qui inclut les demandes RPC qui ont échoué et les conditions d'erreur. Ces informations sont regroupées sur le serveur et journalisées dans des entrées du journal des événements. Pour obtenir la procédure détaillée d'activation du contrôle coté-client dans Outlook, consultez la rubrique Comment activer Contrôle côté client.
Limitation du client
Exchange 2007 inclut une nouvelle fonctionnalité de limitation du client RPC qui permet aux administrateurs de gérer les performances de leurs utilisateurs finaux. La fonction de limitation de client RPC a été introduite pour empêcher des applications clientes d'envoyer un trop grand nombre d'opérations RPC par seconde au serveur Exchange, susceptibles d'affecter les performances globales du serveur. Ces applications clientes incluent des moteurs de recherche de bureau qui effectuent des recherches dans chaque objet d'une boîte aux lettres d'utilisateur, des applications personnalisées servant à gérer des données situées dans les boîtes aux lettres Exchange, les produits d'archivage de messages de type professionnel et des boîtes aux lettres avec les fonctions CRM et de balisage automatique du courrier électronique activées. La limitation des clients permet à Exchange de détecter et d'empêcher la monopolisation du serveur par quelques utilisateurs. Quand le serveur Exchange détecte que l'activité d'un client a un effet disproportionné sur le serveur, ce dernier envoie une demande d'interruption au client afin de réduire l'impact sur les performances du serveur. Pour des informations détaillées sur les fonctionnalités de limitation des clients disponibles dans Exchange 2007, consultez la rubrique Limitation du client.