Les performances du processeur sont-elles pertinentes pour un serveur de base de données?

C'est une question purement théorique. Disons que j'ai une application déployée sur plusieurs serveurs.

1. Un équilibreur de charge,
2. Serveurs d'applications multiples / évolutifs
3. Un serveur de base de données (unique) (pour le moment)

Sur les deux premières parties, je sais quoi rechercher. Mais qu'en est-il du serveur de base de données? Quel type de matériel devrais-je rechercher?

• La fréquence du processeur est-elle pertinente pour un serveur de base de données?
• Plusieurs processeurs principaux sont-ils pertinents?
• La RAM est-elle plus importante que le CPU?

PS: Supposons que la base de données choisie est MySQL ou PostgreSQL.

Pour PostgreSQL, la puissance du processeur peut être très pertinente, en particulier si un pourcentage assez élevé de l’ensemble actif de vos données tient dans la RAM. La plupart des bases de données avec lesquelles j'ai travaillé avaient la plupart du temps comme principal goulot d'étranglement le processeur (Je viens de vérifier vmstat sur un serveur hébergeant des sites Web contenant des millions de visites par jour et hébergeant plus de 5 To d'espace de base de données. Je n'ai jamais vu plus de 2% de temps d'attente sur le disque, mais un pic de 12% de temps processeur.)

Etant donné que PostgreSQL est basé sur les processus, tout processus unique ne peut s’exécuter qu’à un seul cœur, mais dans un mélange semblable à celui que nous avons sur le serveur mentionné ci-dessus, avec un volume élevé de petites requêtes, le processeur total dans tous les cœurs est primordial. Pour la même puissance totale de processeur, PostgreSQL ™ réussira généralement mieux avec moins de cœurs plus rapides que beaucoup de cœurs plus lents.

Jusqu'au point où un pourcentage élevé de votre ensemble de données actif est mis en cache, l'ajout de RAM affichera généralement plus d'avantages que l'argent ajouté à l'ajout de cœurs. Une fois que vous avez suffisamment de mémoire cache, l'avantage de la RAM supplémentaire diminue et il vaut mieux augmenter la puissance du processeur.

Pour plus de détails sur ce sujet en ce qui concerne PostgreSQL, je ne pense pas qu'il existe une meilleure source que PostgreSQL 9.0 High Performance de Greg Smith . (Divulgation complète, j’étais un critique technique du livre, mais je n’obtiens aucun avantage financier en fonction des ventes.)

Strictement du point de vue de MySQL, c'est une question très chargée

La fréquence du processeur est-elle pertinente pour un serveur de base de données?

Bien que le processeur et la carte mère soient plus rapides, d’autres goulots d’étranglement peuvent gêner. Ces goulots d'étranglement comprennent:

• Disque I / O
• Maximum de connexion
• La latence du réseau
• Requête de performance par connexion

Chaque petit avantage est utile, mais je dois dire non, car la vitesse du processeur n'améliore pas en soi les goulots d'étranglement susmentionnés. Après tout, à quoi bon un RaceCar de Formule 1 qui porte un parachute ouvert ou un gorille de 800 livres au volant?

Plusieurs processeurs principaux sont-ils pertinents?

Cela dépend entièrement de la version de MySQL que vous utilisez. MySQL 5.1, le plugin InnoDB, MySQL 5.5 et la XtraDB de Percona Server ont tous des paramètres. VOUS DEVEZ BIEN CONFIGURER pour que InnoDB puisse accéder à tous les cœurs. La véritable incitation à le faire provient du fait que certaines versions plus anciennes de MySQL LEFT UNCONFIGURED sont plus rapides que les versions plus récentes, comme indiqué dans mes articles précédents:

• Comment puis-je effectuer correctement une cuisson MySQL?
• Pourquoi mysql 5.5 plus lent que 5.1 (linux, en utilisant mysqlslap)
• Query fonctionne longtemps dans certaines versions plus récentes de MySQL
• Multi cœurs et performances MySQL

Par conséquent, si vous ne souhaitez pas configurer InnoDB pour accéder à tous les processeurs, le fait de disposer de plusieurs cœurs ne vous rapporte absolument rien .

La RAM est-elle plus importante que le CPU?

Oh oui, en effet. La configuration de la mémoire pour MySQL implique la configuration

• tampons pour InnoDB et MyISAM
• Options par connexion pour les tris, les jointures, la lecture et les tables temporaires
• limites de connexion maximales
• opération d'insertion en vrac
• mise en cache des requêtes

Demander trop peu ou trop de n'importe quelle combinaison de ces choses et MySQL revient vous mordre. Un processeur plus rapide avec MySQL mal configuré pour la RAM permet à MySQL de vous mordre plus vite.

• Non
• Non
• Oui

En termes simples, vous avez besoin de performances de RAM et d'E / S (latence + vitesse de lecture + vitesse d'écriture) pour les bases de données.

Le choix de 4 ou 6 cœurs ou de 2,5 GHz vs 3 GHz n’est pas vraiment pertinent (je suppose que vous n’avez pas à choisir entre un P3-450 avec 32 Go de RAM ou le dernier Xeon avec 1 Go de RAM).

Si vous êtes lié au processeur, alors vous avez d'autres problèmes (mauvaise conception, mauvais index, permutation, serveur non dédié, etc.)