Il y a quelques mois, j’ai été réveillé par la sonnerie insistante de mon terminal BlackBerry, laquelle m’informait que j’avais un message de priorité élevée. Tous les clients qui utilisaient l’une de mes bases de données m’appelaient pour se plaindre que notre application Web nécessitait 20 à 30 secondes pour charger les pages qu’ils consultaient le plus fréquemment.Les performances s’étaient dégradées progressivement au cours des dernières semaines et en étaient à un point tel que la simple connexion de quelques utilisateurs provoquait l’arrêt du système. Il fallait que je trouve la source du dysfonctionnement et vite. Le présent article explique comme j’ai pu remonter à l’origine du problème, celle-ci étant due, comme j’ai pu le découvrir, à l’action combinée de la fragmentation de tables et fichiers de base de données et d’une mauvaise densité de page. Il présente ensuite les actions prises pour corriger le problème.
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.
Téléchargez gratuitement cette ressource
IBM Cloud Pak for Security : Quelles avancées avec IDC ?
IBM Cloud Pak for Security est une plateforme de sécurité intégrée ouverte conçue pour fournir des éclairages approfondis sur les menaces pour plusieurs environnements. Découvrez comment obtenir des informations sur les menaces et les risques, orchestrer les actions, automatiser les réponses sans devoir faire migrer vos données.
