La bataille de la fragmentation: les clés de la victoire

Ma première réaction a été d’ouvrir l’Analyseur de performances (Performance Monitor) et d’examiner si l’un des « quatre piliers », à savoir le processeur, la mémoire, le disque et le réseau, avaient un lien avec le ralentissement. Le compteur % Temps processeur (% Processor Time) de l’objet Processeur (Processor) se situait dans la plage normale pour notre serveur de base de données, le compteur Pages libres (Free Pages) de l’objet SQL Server : Gestionnaire de tampons (SQL Server: Buffer Manager) indiquait plus de 2000 pages disponibles et le compteur Total des octets/s (Bytes Total/sec) de l’objet Interface réseau (Network Interface) indiquait une valeur de l’ordre de 1/20e de la capacité d’un réseau Ethernet Gigabit.

Toutefois, le compteur Octets disque/s (Disk Bytes/sec) de l’objet Disque physique (Physical Disk) indiquait systématiquement une valeur de 100 à 200 pour cent supérieure à la normale pour notre serveur. L’utilisation du disque semblait être donc la source du problème. Dans ce cas, apparemment le disque dur avait une activité suffisamment excessive pendant une période prolongée pour ralentir toutes les autres opérations. Comme ADO.NET recourt à un algorithme relativement agressif pour ajouter des connexions au pool de connexions, même une petite augmentation du délai de conservation d’une connexion par le processus d’un utilisateur multiplie le nombre de connexions.

Plus de connexions vers la même source de données accroît généralement la probabilité de conflits de verrous sur les données accédées couramment, ce qui entraîne à son tour un ralentissement des réponses de SQL Server aux requêtes. Tout comme un véhicule roulant lentement aux heures de pointe ralentira les autres automobilistes, une petite augmentation du temps de réponse au niveau d’un serveur de base de données peut avoir un effet de ralentissement en cascade sur les performances au sein d’un environnement applicatif très actif.