Tu as fait un vrai tests pour affirmer cela ? Je peux t'affirmer qu'en terme d'IO/s c'est faux. Je parle bien d'IO/s, car c'est cela qui importe pour des bases des données, et pas des débits séquentiels.
Personnellement j'ai utilisé des SSD dans l'industrie, des Intel X25-M, donc assez vieux maintenant. Dans la pratique (j'insiste), 1 disque montait à 10 000 IO/s. Un SAS même à 15k tours ne peux pas physiquement dépasser 300 IO/s (15 000 tours/min => 250 tours/seconde) En théorie donc, 10 SAS15k ne peuvent pas dépasser 3000 IO/s, et on l'a vérifié concrètement avec ce setup. Est-ce que tu peux argumenter tes propos avec de vrais chiffres s'il te plait ? 2012/7/4 Philippe Verdy <[email protected]> > Tu parles des perfs du RAID 5 : franchement j'ai de meilleure perfs > sur mon RAID 5 à 6 disques en SATA 3 (trois contrôleurs) que sur un > SSD unique. Sans doute une limitation de l'unique interface SATA > (supposée SATA 3 mais qui visiblement sature bien avant d'atteindre le > débit maximum supposé). > > Visiblement nos SSD actuels ont un dispositif qui limite leurs > performance (sans doute dans la table d'index des secteurs), je ne > sais pas trop où mais ça me laisse dubitatif sur même la cohérence des > données qu'ils stockent. D'ailleurs à débit élevé on voit très > nettement des pauses assez longues entre des séquences de "burst". Ces > pauses ont des conséquences car l'OS met le thread en attente et ne le > réactive aussi qu'après un certain délai quand il pense pouvoir faire > quelquechose d'autre comme des processus de maintenance automatique. > > Je ne vois, lors de débits I/O massifs, pas de réel gain du SSD par > rapport au RAID, pire je vois des pauses bien plus longues où les > threads sont mis en sommeil bien plus longtemps, et les cores de CPU > passent en mode basse énergie et basse fréquence et sont assez longs à > réveiller : trop de cores en fait restent en sommeil et ne font rien > du tout sur la config SSD, et le nombre et la fréquence de pages qui > sont mises en "swap out" de façon anticipée explose (ces swaps sont > d'ailleurs prioritaires sur toutes les autres I/O et peuvent être > responsables de ces délais). > > L'OS y est aussi certainement pour quelquechose. Mais je n'ai pas > envie de fouiller pour savoir pourquoi, la solution de contournement > sera trop spécifique à une seule instance de l'OS et ne résistera pas > à la mise à jour d'un pilote ou d'un service annexe (y compris une > solution logicielle de sécurité mise à jour tous les jours). > > De toute façon, un SSD ne permet pas de stocker à pris raisonnable > tout ce dont on a besoin pour l'OS, la base de données, les services, > et les outils qu'on utilise autour. Je garde le SSD uniquement pour le > logiciel, pas pour les données ni pour la partition de swap en stripe > sur un petit volume RAID distinct, et ça suffit. Question coût aussi. > Si on veut plus de performance, c'est plus rentable de meetre à jour > son serveur SQL pour qu'il puisse utiliser de nouvelles méthodes > d'indexation et formats de stockage, et de faire un peu de tuning SQL > (surtout aussi pour optimiser les requêtes en fouillant les plans > d'exécution pour trouver les goulots d'étranglement) > > Le 4 juillet 2012 22:45, Vincent de Chateau-Thierry <[email protected]> a > écrit : > > http://lists.openstreetmap.org/pipermail/dev-fr/2012-June/000974.html > > > > Philippe, si tu as des éléments probants, c'est le moment. Du concret, du > > factuel, bref, du constructif... > > _______________________________________________ > dev-fr mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/dev-fr > -- Philippe Allgoob SA
_______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
