1.1 – Cache et RAM

l’OS exceptée, au mépris de toutes les applications.

Seul l’OS, s’il s’estime stressé est autorisé à lui demander d’en restituer… Plus il a de mémoire et plus la base est petite, moins LRU se déclenchera. Dans un tel cas, des données vieilles de plusieurs années peuvent persister en mémoire, jusqu’à l’arrêt sur serveur. L’adéquation RAM/mise en cache peut être mesurée à l’aide des compteurs du moniteur de performance. Dès que cette adéquation commence à diminuer, les données doivent être lues sur le disque, et c’est là que le système bascule… Prenez conscience que le temps de lecture d’un bit dans une RAM est de l’ordre de 10 nano secondes tandis que celui d’un disque est de l’ordre de 10 ms. Entre les deux, un écart de 1 000 000. Oui, j’ai bien dit UN MILLION. Une lecture disque est un million de fois moins rapide qu’une lecture mémoire.

Cette différence doit toutefois être amendée par le fait que d’un côté, entre la mémoire et le processeur il existe tout un circuit électronique et des micro programmes pour charger et décharger le processeur, et que de l’autre côté, le disque lui même possède souvent un cache, ce qui fait que l’un dans l’autre, l’écart effectif est plus proche d’un rapport de mille que du million… En conclusion, dès que le ratio de mise en cache commence à diminuer singulièrement, les performances baissent de manière très sensible. Une baisse de ce ratio de 20 % est déjà très sensible. Au delà, la file d’attente des demandes de lecture du disque se met à s’allonger démesurément et l’on se retrouve dans une situation d’engorgement digne du périphérique un vendredi soir vers 17 heures avec chaussée extérieure un accrochage et chaussée intérieure une voie immobilisée par une panne d’essence !

Mais, nous avons déjà comment optimiser notre base de données SQL : il suffit d’y ajouter de la RAM ! C’est si vrai que les pros de la chose, déterminent les caractéristiques des serveurs qu’ils vont devoir acheter en calculant ce qui doit être mis en cache. Non, toute la base ne doit pas tenir en mémoire. Mais ce qui doit y être, c’est la "fenêtre de données", c’est à dire la frange des données réellement et couramment exploitée à l’instant T. Par exemple pour une comptabilité, ce qui constitue la fenêtre des données c’est à 50 % le mois en cours, 30 % le trimestre en cours, 20 % l’année en cours et 10 % le reste… Ce qui fait qu’une base de données comptable avec une moyenne de 4 Go par année et un historique de 6 ans, aura besoin de : (4 / 12 ) * 0,5 + (4 / 4) * 0,3 + 4 * 0,2 + 4 * 6 *0,1 = 3,67 Go de RAM !

Bien entendu, il faut rajouter à cela le cache de procédures (généralement assez minime face aux données), les accès client (qui peut être conséquent s’il y a de nombreux utilisateurs), et l’OS. Par exemple, dans un tel cas, avec un nombre d’utilisateurs ne dépassant pas 200, j’aurais tendance à préconiser une RAM de 6 à 8 Go. Mais encore faut-il que le modèle de données soit en adéquation avec le fenêtrage! Nous verrons que la façon de modéliser, et en particulier la structure des clefs a une influence si importante que le calcul de fenêtrage va s’avérer très en dessous de la réalité… Première commandement : la RAM doit être en adéquation avec le volume des données à traiter.

Tout ce qui peut être fait pour augmenter la RAM et en diminuer son contenu, va dans le sens de l’amélioration des performances. S’il suffisait de rajouter toujours de la RAM, mon papier se terminerait ici… Mais notons déjà que toutes les éditions et versions d’OS Windows Server et de MS SQL Server et en particulier celles en 32 bits ne permettent pas n’importe quelle quantité de RAM en ligne. Cela va de 2 Go à 64. Autrement dit, il faut aussi l’économiser, c’est ce que nous allons voir ci-après.