Être administrateur de base de données peut parfois être très difficile lorsque vous devez résoudre des problèmes de performances. Le serveur de base de données n'est qu'un composant de l'écosystème d'applications et il est régulièrement accusé d'être le problème de performances. SQL Server est l'une de ces boîtes noires que beaucoup ne comprennent pas, tout comme le SAN et le réseau. Les administrateurs de base de données de production qui surveillent leurs serveurs peuvent identifier rapidement si SQL Server fonctionne en dehors de sa ligne de base normale, mais il existe deux domaines principaux sur lesquels nous avons peu de visibilité :le SAN et le réseau. Les administrateurs de bases de données doivent régulièrement travailler avec d'autres ingénieurs lorsqu'il s'agit de résoudre des problèmes de performances qui ne sont pas directement liés à SQL Server. Nous pouvons facilement suivre les performances du disque en surveillant sys.dm_io_virtual_file_stats , dont j'ai parlé dans Monitoring Read/Write Latency ; Cependant, le suivi des problèmes de performances réseau dans SQL Server n'est pas aussi simple.
De mauvaises performances réseau peuvent être un tueur silencieux pour les performances des applications et mon expérience personnelle a montré que c'était le cas à de nombreuses reprises. Souvent, une application commençait à avoir des problèmes de performances et l'ingénieur d'application disait que le serveur d'applications avait l'air bien et commençait à pointer du doigt la base de données. Je recevais un appel pour examiner le serveur de base de données et toutes les indications montraient que le serveur de base de données était en bonne santé (et c'est là que la surveillance des indicateurs de performance clés et le fait d'avoir une base de référence aident !). Puisque les équipes d'application et de base de données disaient que tout allait bien, nous demandions à l'équipe réseau de vérifier les choses. L'équipe du réseau examinerait certaines choses et donnerait également le tout clair de son côté. Chaque équipe dépannait et examinait ses systèmes respectifs prenait du temps, tandis que les performances des applications souffraient toujours. Le problème serait alors aggravé jusqu'à ce que toutes les équipes soient invitées à rejoindre un pont de conférence pour résoudre les problèmes ensemble. Finalement, quelqu'un commencerait un test de réseau plus approfondi et déterminerait que nous avions soit une saturation de port, soit un routage, soit un autre problème de réseau complexe. Quelques clics ou changer quelque chose de leur côté finiraient par résoudre la lenteur de l'application.
Le problème de réseau le plus important que j'ai rencontré avec les clients concerne généralement la bande passante lors de l'exécution de sauvegardes. De nombreuses grandes entreprises migrent vers un réseau 10 Go pour l'infrastructure de base, mais lorsque vous travaillez avec un réseau physique et virtuel, il est facile de mal configurer un paramètre ou un port et de le faire tomber à 1 Go. Pour le trafic réseau d'application régulier, vous ne remarquerez peut-être pas la dégradation des performances, mais dès que vous commencerez à essayer de copier des centaines de Go de données pour les sauvegardes, ce 1 Go deviendra saturé et vos tâches de sauvegarde et de restauration en souffriront.
Pour les administrateurs de base de données, il peut être difficile d'amener les autres à approfondir des problèmes qu'ils ne pensent pas être leur problème, car les indicateurs initiaux ne révèlent pas le problème. Être capable de vous armer de données avant de contacter d'autres équipes aidera à les impliquer. En utilisant iPerf pour effectuer un test initial de bande passante, vous pouvez rapidement déterminer si vous obtenez les vitesses de réseau que vous êtes censé obtenir. Par exemple, si vous utilisez un réseau de 10 Go entre le serveur d'applications et le serveur de base de données et que vous exécutez un test et que vous n'obtenez que 1 Go, vous savez que quelque chose ne va pas. Si vous pouvez documenter ce résultat, vous pouvez demander en toute confiance à vos ingénieurs réseau de se pencher sur un problème de bande passante.
Comment commencer à utiliser iPerf ? Vous devez d'abord télécharger l'outil sur iPerf.fr. Depuis que je travaille sur Windows Server 2012, j'ai téléchargé les binaires Windows sur ma machine. Une fois que vous avez téléchargé et décompressé le package, vous devrez exécuter le programme à partir d'une ligne de commande. J'ai téléchargé iPerf 3.0.11 qui est sorti depuis presque un an. Assurez-vous de lire la documentation de cet utilitaire. Comme il s'agit d'un outil en ligne de commande, il existe des dizaines d'options que vous pouvez utiliser. Dans l'exemple ci-dessous, je n'en utiliserai que quelques-unes, mais selon votre situation, vous devrez peut-être utiliser d'autres options telles que la spécification du port ou l'augmentation de la taille des paquets. Veuillez noter que les commandes d'option sont sensibles à la casse.
Pour utiliser iPerf, vous devez utiliser au moins deux serveurs pour tester la bande passante. Une fois que vous avez copié les binaires sur les deux serveurs, vous devez d'abord démarrer l'écouteur iPerf sur l'un des serveurs. Pour ce faire, je vais lancer la commande suivante :
iperf3 -sCette commande exécute iPerf en mode serveur et n'autorisera qu'une seule connexion à la fois.
Sur le deuxième serveur, vous devrez lancer iPerf en utilisant plusieurs options client. Nous allons d'abord spécifier -c pour spécifier le mode client. Nous utiliserons également -t pour spécifier le temps d'exécution de chaque test et -P pour spécifier le nombre de connexions simultanées à établir. Nous voulons spécifier plusieurs connexions afin de pouvoir exercer une pression appropriée sur le réseau. Pour ce test, je vais exécuter la commande suivante :
iperf3 -c (nom du serveur ou adresse IP du premier serveur) -t 30 -P 10La commande ci-dessus lancera un test de transmission de 30 secondes avec 10 connexions simultanées.
J'ai exécuté ce test sur deux machines virtuelles sur mon Dell M6800, il n'y avait donc pas de réseau physique pour ces machines virtuelles.
Du serveur 2 se connectant au serveur 1, j'ai transféré 7,57 Go avec une bande passante de 2,17 Gbits/sec. Pas mal pour quelques machines virtuelles sur un ordinateur portable.
Statistiques réseau / Sortie iPerf :Serveur 2 se connectant au Serveur 1
Du serveur 1 se connectant au serveur 2, j'ai transféré 6,98 Go avec une bande passante de 2,00 Gbits/sec. Comme vous pouvez le voir, il y a une légère différence dans les chiffres mais toujours relativement proche. Si ces chiffres avaient été radicalement différents, j'aurais dû en rechercher la cause.
Statistiques réseau / sortie iPerf :Serveur 1 se connectant au Serveur 2
Il est important de faire ces tests avant de passer en production et de prendre l'habitude de répéter régulièrement ces tests sur vos serveurs de production. Vous devez savoir ce qui est normal, si vous ne le surveillez pas, vous ne pouvez pas le mesurer. Si vous savez que des mises à jour du micrologiciel sont en cours sur vos serveurs, l'hôte virtuel ou tout équipement réseau central, un test iPerf avant et après les modifications pourrait vous alerter rapidement pour identifier tout effet secondaire négatif.
Il est également important d'effectuer ce test sur tous les serveurs qui s'interfacent directement avec le serveur de base de données et sur tous les serveurs avec lesquels le serveur de base de données s'interface directement, tels que les périphériques de sauvegarde réseau. IPerf fonctionne à la fois sur Windows et Linux, ce qui facilite les tests entre les deux systèmes d'exploitation.
Pour les DBA, le réseau ne doit plus être une boîte noire dont vous ne savez rien. L'utilisation d'iPerf peut vous alerter de tout problème de bande passante avec le réseau entre votre serveur de base de données et tout autre serveur. Il n'y a aucune raison de ne compter que sur PING et TRACERT pour un dépannage réseau limité. Téléchargez iPerf et commencez à documenter la bande passante de votre réseau.
