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 cette ressource
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez les dernières tendances et solutions IT autour des univers de Poste de travail, Affichage et Collaboration, Impression et Infrastructure, et notre dossier Green IT sur les actions engagés par inmac wstore pour réduire son impact environnemental
Les articles les plus consultés
- 9 défis de transformation digitale !
- ActiveViam fait travailler les data scientists et les décideurs métiers ensemble
- Dark Web : où sont vos données dérobées ?
- Stockage autonome, Evolutivité & Gestion intelligente, Pure Storage offre de nouvelles perspectives aux entreprises
- Les projets d’intégration augmentent la charge de travail des services IT
