Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

SQL Server : Quels sont les problèmes de performance les plus fréquent ? Partie 1/5 : Le système disque.

Faisons rapidement un TOP 5 des problèmes les plus fréquent sur un serveur de base de données équipé de SQL Server (et de tous les moteurs de base de données relationnel en passant).

Partie 1 : Problème de performance disque

C'est le problème numéro 1, le système disque est sous dimensionné car beaucoup de gens pense qu'un serveur de base de données ne consomme que des ressources processeur… Mais les données doivent bien être lues quelque part ? Et plus elles sont importantes, plus lent est leur lecture et leur traitement. Une manière de « compenser » le manque de disque ou un système peu performant est d'ajouter de la mémoire et ainsi maximiser les données présentes dans le cache et limiter les lectures sur le disque.

L'une des raisons de ce sous dimensionnement c'est que souvent les administrateurs en charge des machines d'arrête sur le capacité interne en nombre de disque des serveurs. Or il existe des « extender » en rack pour ajouter environ 20 / 40 disques et qui permettent de les connecter au serveur. Les solutions plus dispendieuses tels que les SAN (Storage Area Network, qui une banque de disque déportée sur le réseau avec ses contrôleurs disque et des interfaces réseau spécifiques) n'est donc pas une obligation dès que l'on dépasse 8 disques (nombre courant maxi de disque interne sur des serveurs) !

De plus le choix du niveau RAID pour des disques interne doit bien être réfléchit (http://blogs.codes-sources.com/christian/archive/2007/01/15/syst-me-articles-sur-le-raid.aspx) ainsi que la qualité du contrôleur, le niveau de cache, la protection du cache par batterie. Gardez en tête que 2 nombres seront vos références pour mesurer la vélocité d'un tel système : Mo/s pour ce qui est des lectures / écritures séquentielles, IO/s pour ce qui est des lectures / écritures aléatoires. Un disque SSD, par exemple, est très bon en nombre d'IO/s, mais assez décevant en Mo/s particulièrement en écriture.

Et enfin la séparation données (MDF/NDF), journaux de transactions (LDF) est indispensable. C'est le minimum syndical sur vos serveurs, car le type d'IO de ces 2 types de fichier est très différent et les uns risquent de bloquer les autres. Même avec des contrôleurs RAID récent équipé d'une bonne quantité de cache le phénomène est visible. Seuls les SAN permettent un tant soit peu de rendre la chose plus transparente, même si tous les gros déploiements suivent la même règle de séparation des LUNS (volume SAN) des données et journaux. Idéalement vous pourrez découper vos volumes de la manière suivante :

  • 1 volume pour le système
  • 1 volume pour le fichier d'échange (SWAP, même si ce dernier ne sera pas utilisé volontairement par SQL Server, il pourra servir à d'autres services et applications)
  • 1 volume pour les métadonnées (bases de données systèmes, fichier MDF des bases de données utilisateurs)
  • x (si possible autant que de CPU) volumes pour les données
  • y (si possible autant que de CPU) volumes pour les index non ordonnés (non-clustered)
  • 1 volume pour tempdb (données)
  • 1 volume pour tempdb (journal de transaction)
  • 1 volume pour les journaux de transactions des autres bases de données.
  • 1 volume pour l'import / export / backups /etc.

Par volume j'entends regroupement de disques via un agrégat RAID, ce n'est pas un disque, mais un ensemble. Cette réparation est « idéale », avec moins de disques certains volumes peuvent être regroupés (Journaux avec journaux et données avec données). Le minimum serait :

  • 1 volume système + SWAP
  • 1 volume données
  • 1 volume tempdb (Données)
  • 1 volume journaux de transaction (bases utilisateur + tempdb)

Les backups, si possible, sur un autre volume que les fichiers de données ou de journaux de transactions.

Partie 2 :
http://blogs.codes-sources.com/christian/archive/2009/04/27/sql-server-quels-sont-les-probl-mes-de-performance-les-plus-fr-quent-partie-2-5-contention-li-aux-verrous-interblocages-deadlock.aspx

Bonne configuration disque...

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Publié mardi 7 avril 2009 09:00 par christian

Commentaires

Pas de commentaires
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01