Serveur de base de données: Petite RAM rapide ou grande RAM lente?

33

Nous concevons actuellement nos nouveaux serveurs de base de données et nous avons trouvé un compromis. Je ne sais pas trop comment vous répondre.

Voici nos options: 48 Go à 1333 MHz ou 96 Go à 1066 MHz.

Je pense que la mémoire vive devrait être abondante pour un serveur de base de données (nous avons beaucoup de données, et quelques requêtes très volumineuses) au lieu d’être aussi rapide que possible. Apparemment, nous ne pouvons pas obtenir des puces de 16 Go à 1333 MHz, d’où les choix ci-dessus.

Alors, devrions-nous avoir beaucoup de RAM plus lente ou moins rapide?

Informaitons supplémentaires:

Nombre d'emplacements DIMM disponibles: 6
serveurs: unités centrales Dell: 6 processeurs (un seul connecteur en raison de l'octroi de licences Oracle).

database oracle memory Josh Smeaton
la source
12
OMI, 100% de plus de capacité de RAM bat 20% de vitesse de RAM supplémentaire.
Joe Internet
3
Surtout parce que ce n'est même pas 20%;)
TomTom
Merci tout le monde. J'étais assez sûr de cela aussi, mais je voulais une confirmation.
Josh Smeaton

Réponses:

59

Vous voudrez aller avec la grande et lente RAM. La différence entre les performances de la RAM est négligeable par rapport à la différence entre les performances de la RAM et les performances du disque.

Skyhawk
la source
Bien sûr, cela dépend de la taille de la base de données - des détails basiques mais néanmoins importants.
Morg.
Oui, et Josh a clairement précisé que le scénario en question impliquait "beaucoup de données".
Skyhawk
Pour certaines personnes, un million de lignes ressemble à «beaucoup de données», ce qui n’est guère une raison pour ne pas tout avoir en mémoire;)
Morg.
16

Bon, c'est très très très simple:

Votre base de données contient-elle 48 Go de RAM avec le système d’exploitation et tout le reste? si oui, prenez ça. Sinon, prenez 96Go

En outre, l'adaptation de la base de données à xyz Go de RAM signifie qu'elle s'adapte aux index, aux vues, etc.

Les commentaires SSD sont un non-sens total, la bande passante et le temps d'accès ne sont pas au même niveau et aucun SSD ne peut justifier de prendre moins de RAM.

Morg.
la source
5
C'est une information très importante. Si la base de données ne fait que 5 Go et n’est pas prévue pour être beaucoup plus grande, vous pourriez aussi bien choisir une plus petite quantité de RAM plus rapide.
Kibbee
13

Base de données seulement? Selon la base de données, je penserais que la plus grande RAM serait mieux. La différence de vitesse s’avère au mieux minime, mais les 48 Go supplémentaires feront / pourraient faire une énorme différence.

TomTom
la source
11

Définitivement grande RAM, vitesse soit damné.

L'accès aux données aléatoires pour la technologie RAM du XXe siècle '90 est inférieur à 100 ns. Cela utilise des puces pratiquement anciennes qui ne s'intègrent même pas physiquement dans un style contemporain.

L'accès à des données aléatoires pour les disques durs de pointe à 15 000 tr / min est mesuré en millisecondes. 100 ns est 10 000 fois plus courte (nano -> micro -> milli) que 1 ms. La RAM actuelle est plus rapide et le disque dur a besoin de plusieurs millisecondes pour accéder aux données. Je m'en fous si ma RAM était 50 000 fois plus rapide ou seulement 30 000 fois plus rapide qu'un disque dur, si je pouvais en avoir plus.

Paweł Brodacki
la source
5

Vous devez prendre votre attention sur certains points:

  • Mémoire de la mémoire La vitesse de la mémoire dépend de deux facteurs: la vitesse du bus et la latence. Habituellement, les puces avec plus de densité entraînent une latence plus élevée, ce qui signifie finalement moins de vitesse
  • Total des données d'index Le y le plus critique pour charger l'intégralité des données d'index en mémoire. Les données d'index sont les données les plus critiques dont vous avez besoin en mémoire (effet de pénalité accru sur les performances).
  • Vitesse du disque Avez-vous les données de base de données stockées dans SSD? Si la réponse est oui, faites particulièrement attention à la latence de la mémoire.
Nefeli
la source
2

MEMORY BANDWIDTH = / = SPEED!

L’information manquante la plus importante est probablement le minutage de la mémoire et le type de CPU / FSB. Réduisez le délai de charge de la mémoire du processeur de quelques cycles et vous obtiendrez deux fois plus de bande passante lors de certains calculs. Certaines bases de données n'utilisent pas d'énormes quantités de RAM pour des raisons techniques et de système d'exploitation. Quel serveur de base de données utilisez-vous? Type de CPU? L [123] niveaux de cache? type de requêtes à exécuter? taille de la base de données?

Silverfire
la source
2
-1. Faits faux dans 99,9% des cas.
TomTom
De quelle partie parlez-vous?
Silverfire
2
Toute base de données plus grande que la mémoire ralentit immédiatement. Les cycles cpu sont une blague comparé à - sauf s’il s’agit d’un cas OLAP très particulier - au temps de latence IO introduit La plupart des bases de données utilisent énormément de RAM - le samllest dataase SERVER que j'ai vu n'est pas une blague, car une base de données minuscule utilise beaucoup plus de RAM que la moyenne des stations de travail. Sauf si vous insistez pour utiliser une technologie obsolète ("os system limits"). Et ni la vitesse du processeur, ni le type FSB ne font la différence - les bases de données ont besoin de mémoire.
TomTom
0

Avant de dépenser trop d'argent sur du mauvais matériel, je faisais quelques tests et analyses avant d'acheter du matériel.

  • Tout d’abord, pensez à votre contrat de niveau de service.
  • des exigences strictes en termes de performances et de temps de réponse?

Votre choix devrait dépendre de nombreux facteurs:

  • sous différentes charges de travail et différents usages, quel est le goulot d'étranglement?
  • CPU, mémoire, stockage, réseau?
  • Est-il peut-être plus important de dépenser plus d'argent pour un stockage plus rapide que plus de mémoire?

  • CPU plus rapide que plus de mémoire? réseau plus rapide? refonte mineure sur le logiciel / sql?

  • votre analyse pourrait également être très pertinente pour les développeurs, les architectes de bases de données et de logiciels et les concepteurs de requêtes SQL .....

Si vous utilisez Windows, vous pouvez facilement exécuter perfmon pour voir certaines statistiques sur le système en cours d’exécution et vous aurez peut-être beaucoup de chance d’avoir une idée précise de vos besoins.

Manmathan
la source
1
Je suis un développeur et j'aide à peser dans cette décision. Il nous manque un véritable administrateur système, nous avons donc tous (6 d'entre nous) participé à la discussion. Nos serveurs actuels sont en 32 bits et sont incapables de faire beaucoup en raison de la limite de mémoire par processus. Notre réseau / stockage est (devrait être) bien pour le moment. Le backend de stockage est un SAN. Notre processeur n'est jamais maximisé. La plupart des coûts associés à nos requêtes sont liés aux E / S, qui devraient être allégés par la possibilité d'utiliser davantage de RAM. Nous passons également à RAC. Nous avons une idée claire de ce dont nous avons besoin. C'est la minutie qui est discutable.
Josh Smeaton