MySQL : Disque ou Ram ?

[Jukien]

Bonjour,

Un nouveau projet, tout beau tout neuf, est sur le point d'être lancé.

Ce projet utilise intensivement une BDD MySQL en écriture (de 1 à 15 requêtes par seconde), mais beaucoup moins en lecture.

Cette base est constituée à 98% de tables au format InnoDB, truffés d'index.

Une de ces tables fait actuellement 500 Mo, mais atteindra les 2/3 Go dans peu de temps.

Deux choix se présentent pour le dédié (budget 50 max, mais je devrais réussir à pousser jusqu'à 60 euros) :

- OVH :: SP Mini (Core2Duo 2x2.33 Ghz, 2 Go DDR2, DD 2 x 500 Go)

http://www.ovh.com/fr/particulier/produits...erplan_mini.xml

- Kimsufi :: 4XL (Quad Q6600 4x2.40 Ghz, 4 Go DDR, 1 x 250 Go)

http://www.kimsufi.com/

Sachant que je me contre-fiche des SLA (tout est redondé), et que la consommation en Bande Passante sera ultra-faible, que me conseillez-vous ?

J'ai fait quelques tests sur mon PC, le processeur n'est pas vraiment chargé, ça ne semble donc pas être un critère de choix.

Par contre, pour la RAM et le DD, c'est une autre histoire : Est-il préférable de disposer de deux fois plus de RAM, ou d'un joli RAID 0 ?

Merci de votre lecture, et merci pour vos éventuelles réponses.

[Kioob]

Hello,

et coté sécurité des données (RAID 1), ça n'a pas d'importance ?

Et tes 15 requêtes par seconde, elles modifient de gros volumes de données ? Parce que là comme ça, 15 requetes/seconde ça n'a rien d'énorme (j'ai un kimsufi 2008 qui monte à 3'000 req/s par exemple).

Pour tes 3Go de données, c'est de l'archivage, ou l'intégralité des données sert en permanence ? Car si ces 3Go de données servent en permanence, il peut être intéressant d'avoir un peu plus de mémoire...

[Jukien]

Chaque requête manipule une dizaine de ko.

Le problème est essentiellement lié au nombre important d'insertions dans la base : En testant sur mon pc portable (donc avec un DD assez lent...), ça ramait assez rapidement. Le problème est surtout lié aux pics : c'est 15 requêtes en moyenne, mais il peut y avoir des pics de 300 à 500 en une seconde, puis un calme plat pendant une 20ene de secondes.

Cela dit, je suis assez impressionné par tes 3'000 requetes / secondes. C'est du continu, 24h/24 ? De l'insertion aussi ?

Concernant le raid 1, le serveur étant entièrement redondé, je ne pense pas que cela soit utile : les données sont déjà dupliquées en permanence sur deux serveurs.

Les 3 Go de données sont susceptibles d'etre manipulées en permanence, mais les requetes de lecture concernent en général moins de 100 enregistrements (donc maximum 1Mo).

[Kioob]

Non, 3'000 req/s c'est en pic. En moyenne sur 24h la machine fait du 1'300 req/s : 45% de select, 27% d'update et 13% d'insert. En moyenne ça doit représenter dans les 500Ko/s d'écriture disque.

Dans mon cas la machine est un core2duo avec 3Go de ram, le tout sur du raid 1 software. Si InnoDB est "bien" ajusté, ça passe sans problème.

Pour le test avec ton portable, faudrait déjà voir sous un Unix si ce n'est pas le cas, et en ajustant un poil la config InnoDB (la taille des logs, du buffer, le flush_method, ainsi que le "log_at_trx_commit"). Ca devrait donner un bien meilleur aperçu de ce que ça peut donner.

[Jukien]

Ok, c'est un Kimsufi 2008 XXL. Je pensais à un Kimsufi de base (celeron, 1 Go ram) au début.

Ceci dit, ça reste une belle performance.

Sur mon PC Portable tourne bien évidement sous Linux, mais il est vrai que la configuration MySQL n'est pas forcément ajustée avec finesse. Mais il faudrait que je teste sur un vrai PC, avec un vrai disque. Celui-là est vraiment vraiment trop lent.

Enfin, je constate quand même que le ["le", car un raid 1 n'a pas d'impact sur l'écriture, et c'est ce qui m'intéresse ici] disque de ton serveur encaisse bien. Donc du coup, je vais peut être privilégier la ram.

[Kioob]

Yep. Si ça peut t'aider il s'agit d'un Barracuda 7200.11, avec une distrib Debian Etch 64bits sous laquelle tourne un MySQL 5.0.51a (migré depuis peu en 5.1.30).