Question Plus de RAM ou plus de cœurs pour un serveur de base de données MySQL?


Voici le scénario sur lequel j'aimerais avoir votre avis d'expert:

J'ai actuellement environ 2 Go de base de données, peut-être le double en un an. Je souhaite commander des performances optimales pour le serveur de base de données dédié que je vais commander, qui servira de back-end pour un site à fort trafic utilisant WordPress, un forum et mediawiki. La majeure partie du trafic de base de données doit être en lecture seule.

La question est donc la suivante: ai-je vraiment besoin de plus de 4 Go de RAM? Et devrais-je choisir 8 cœurs ou seulement 4? Est-ce que l'un est plus important que l'autre?

[edit] Juste comme une suite, fini par faire une bonne affaire sur un serveur à 8 cœurs avec 8 Go de RAM, donc c'est parti. Content de savoir que j'aurai beaucoup de place pour grandir.


5
2018-01-09 07:29


origine


N'oubliez pas que vous aurez besoin de binaires d'applications et de systèmes d'exploitation 64 bits pour tirer le meilleur parti de la mémoire vive de 4 Go. - petertonoli
Bien sûr, j'utilise le 64 bits partout, sur chaque machine que je touche. - The How-To Geek


Réponses:


question interessante. Essayez d’abord de définir le goulot d’étranglement de votre application actuelle. D'après votre description et vos connaissances pratiques, je suppose que vous avez quatre goulots d'étranglement possibles:

  • nic
  • RAM
  • débit hd
  • vitesse CPU)
  • cpu (cœurs)

Maintenant, la mémoire vive ne serait pas un problème, car, puisque votre base de données n’est que de 2 Go, vous pouvez non seulement tamponner toutes les clés et les induire, mais en fait toute la base de données de la RAM ayant une taille de 2 Go, si vous taillez (MyISAM-) key_buffer et / ou innodb_buffer_pool_cache en conséquence ! Vous iriez probablement bien même avec ram <dbsize, car généralement toutes les parties d’une base de données ne sont pas utilisées en même temps (ymmv).

Bien entendu, ram est également utilisé pour les tables de mémoire, le tri et le classement, ainsi que pour certaines opérations de jointure. Par conséquent, vous devez examiner la complexité des requêtes de votre base de données et déterminer si elle renvoie des ensembles de résultats très volumineux. Je ne le sais pas, mais je ne crois pas que WordPress ni Mediawiki n'y effectuent des opérations vraiment complexes. Il suffit donc d’obtenir une quantité modérée de bélier.

La HD est le goulet d'étranglement habituel pour toute base de données volumineuse, mais la vôtre peut néanmoins être mise en cache dans la mémoire RAM, et vous dites que vous avez principalement lu des opérations, alors je dirais: pour une base de données volumineuse normale, la règle de base est la suivante: débit HD est un goulot d'étranglement principal, donc: 1. achetez des disques durs, et 2. n'achetez pas nécessairement les plus rapides, mais achetez-en beaucoup. Dans votre cas, je dirais: tout est mis en cache de toute façon.

En ce qui concerne les noyaux: MySQL peut certes tirer parti de nombreux cœurs, mais il en a surtout besoin pour des calculs complexes, des programmes de procédures et des opérations de tri et de fusion. Des requêtes Siple telles que "Select * from table" ou même select * from table où ... "ne bénéficieront pas beaucoup de davantage de cœurs. De nombreuses connexions en tireront un avantage mineur. Je suppose que vous devriez préférer un processeur plus rapide à plusieurs cœurs.

Je crois que vous devriez vérifier le nic comme principal goulot d'étranglement et pensez à un deuxième (troisième, quatrième ...) nic, en fonction de la quantité de trafic sur votre interface principale.

Donc, pour résumer le tout, je dépenserais mon argent dans (dans cet ordre): - plus d'un nic (s'il s'agit bien d'un goulot d'étranglement) - un processeur rapide - 2 - 4 noyaux - RAM 2-4G avec possibilité de brancher 8G plus tard (de toute façon moins cher que les noyaux) - Le meilleur sous-système de disque possible (vous n'avez pas besoin de beaucoup maintenant, mais cela vous aidera à développer plus tard)

Salut, Nik.


6
2018-01-09 08:18



N'oubliez pas que plus vous achetez de disques, plus vous devez appliquer de stratégies de sauvegarde et de récupération pour chaque disque. - icelava


Comme le dit nikb, il est important de comprendre votre application, mais au lieu de le savoir, je suggérerais la règle générale suivante.

À moins qu’une partie seulement de votre base de données ne soit lue ou écrite régulièrement, aucune quantité de cœurs supplémentaires ne correspondra aux avantages en termes de performances de disposer de toutes vos bases de données et données auxiliaires (index, etc.) en mémoire. Des noyaux supplémentaires seront utiles si vous avez beaucoup de clients simultanés frappant votre ou vous faites beaucoup de travail de fond tels que les rapports ou l’indexation.

Si j'étais vous, je choisirais un serveur double socket assez récent basé sur la série Intel 55xx et n'achèterais qu'un processeur à 4 cœurs, hyperthread, avec 3 modules de mémoire DDR de 4 Go (ne laissez pas quelqu'un vous vendre 2/4 / 8 etc, utilisation de 55xx 3,6,9 etc ok). De cette manière, vous pourrez non seulement ajouter très rapidement et facilement un deuxième processeur identique dans le futur, mais ces puces étant compatibles avec les futures puces à 8 cœurs, vous pouvez toujours échanger celui que vous avez initialement.

J'espère que cela aidera.


6
2018-01-09 09:11



C'est utile à savoir, je ne savais pas que la RAM utilisée par 55xx était une série de 3. - The How-To Geek
Oui, triple canal, bêtement rapide :) - Chopper3
Oui super rapide mais il faut absolument être configuré en triple (ou 6x pour double prise). Et construisez-le par préférence avec moins de modules DIMM (3x2 Go plutôt que 6x1 Go, 3x4GB plutôt que 6x2GB ou 12x1GB). Un nombre inférieur de DIMM prend en charge des vitesses de DIMM plus rapides et la différence peut aller jusqu'à 30%. La différence entre une mémoire RAM Xeon 55xx très mal configurée (par exemple, 4 Go en tant que DIMM 4x1 Go fonctionnant à 800 Mhz avec seulement 2 canaux) et bien configurée (3 Go en tant que DIMM 3x1 Go fonctionnant à 1333 Mhz) est sévère - la bande passante maximale théorique va d'environ 12 Go / s à environ 30 Go / sec. - Helvick


La suggestion de Nikb est valable. Un domaine supplémentaire à considérer:

Combien de RAM (ou de cœurs de processeur ou de systèmes de disques) une instance de votre application / application architexture peut-elle accéder?

J'ai vu une situation dans laquelle une application sur un serveur quadcore avec 14 Go de RAM s'exécutait très lentement, alors que l'utilisation du processeur était inférieure à 25% et que l'utilisation de la RAM était faible. Il s'est avéré que le moteur d'application ne pouvait accéder qu'à 1,5 Go de RAM. L'instance d'application était saturée, même si la machine n'était que légèrement affectée.


0
2018-01-10 10:21