Si votre base de données est très gourmande en écriture, utilisez RAID 10, et non RAID 6. Avec des disques SAS très rapides et très performants.
Achetez un châssis plus grand que ce dont vous avez besoin afin de pouvoir vous y adapter. J'ai récemment ajouté un quadruple cœur à mon serveur de base de données de production et je peux vous dire que, pour une fois dans ma carrière, j'étais vraiment content d'avoir acheté la carte mère à double socket même si je n'avais besoin que de quatre cœurs au départ. Le fait que l'utilisation du processeur soit passée de 60 % en moyenne avec de longs pics à 100 % à 30 % en moyenne avec de rares pics à 100 % a eu un impact énorme sur nos performances. Ne pas avoir à migrer complètement d'une machine à l'autre pour obtenir cela était vraiment génial - insérer une autre puce dans le socket supplémentaire prenait environ 20 minutes. En ce qui concerne la mémoire vive, il faut en mettre autant que la machine peut en supporter.
Pour mémoire, notre système de production utilise le système SAS, notre système de développement utilise le système SATA. Nous pouvons clairement sentir et quantifier la différence ; les requêtes qui peuvent prendre 1,5 seconde sur notre machine de production chargée peuvent prendre 3 secondes sur notre serveur de développement non chargé. Il s'agit bien sûr d'une anecdote et il existe d'autres différences, mais nous avons remarqué que c'est l'IO qui tue. 1,5 seconde n'est pas une grosse affaire, n'est-ce pas ? Sauf qu'en production, c'est une différence de 1,5 seconde * x utilisateurs * y requêtes par heure.
Encore une réflexion sur l'IO : nous avons pris soin de configurer nos tables les plus utilisées de manière à ce qu'elles se trouvent sur des groupes de fichiers contenant plusieurs fichiers. Ainsi, si BigOverUsedTable se trouve sur FileGroup1, que FileGroup1 contient quatre fichiers et que votre base de données dispose de 8 cœurs, quatre cœurs seront utilisés pour effectuer la requête "select big number crunching nasty query from BigOverUsedTable", alors que dans le cas contraire, un seul processeur sera utilisé. Nous avons tiré cette idée de cet article de MSDN :
http://msdn.microsoft.com/en-us/library/ms944351.aspx
Extrait de TFA :
"Les groupes de fichiers utilisent des threads parallèles pour améliorer l'accès aux données. Lorsqu'une table est accédée de manière séquentielle, le système crée un thread séparé pour chaque fichier en parallèle. Lorsque le système effectue une recherche pour une table dans un groupe de fichiers comportant quatre fichiers, il utilise quatre threads distincts pour lire les données en parallèle. En général, l'utilisation de plusieurs fichiers sur des disques distincts améliore les performances. Un trop grand nombre de fichiers dans un groupe de fichiers peut entraîner un trop grand nombre de threads parallèles et créer des goulots d'étranglement".
Nous avons quatre fichiers dans notre groupe de fichiers sur une machine à 8 cœurs à cause de ce conseil. Cela fonctionne bien.
