Tu as fait un vrai tests pour affirmer cela ?<div><div>Je peux t'affirmer qu'en terme d'IO/s c'est faux.</div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;line-height:16px">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.</span></div>

<div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;line-height:16px"><br></span></div><div>Personnellement j'ai utilisé des SSD dans l'industrie, des Intel <span style="line-height:16px;color:rgb(34,34,34);font-family:arial,sans-serif">X25-M, donc assez vieux maintenant.</span></div>

<div><font color="#222222" face="arial, sans-serif"><span style="line-height:16px">Dans la pratique (j'insiste), 1 disque montait à 10 000 IO/s.</span></font></div><div><font color="#222222" face="arial, sans-serif"><span style="line-height:16px">Un SAS même à 15k tours ne peux pas physiquement dépasser 300 IO/s (15 000 tours/min => 250 tours/seconde)</span></font></div>

<div><font color="#222222" face="arial, sans-serif"><span style="line-height:16px"><br></span></font></div><div><font color="#222222" face="arial, sans-serif"><span style="line-height:16px">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.</span></font></div>

<div><font color="#222222" face="arial, sans-serif"><span style="line-height:16px"><br></span></font></div><div><font color="#222222" face="arial, sans-serif"><span style="line-height:16px">Est-ce que tu peux argumenter tes propos avec de vrais chiffres s'il te plait ?</span></font></div>
<div><br><div class="gmail_quote">2012/7/4 Philippe Verdy <span dir="ltr"><<a href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Tu parles des perfs du RAID 5 : franchement j'ai de meilleure perfs<br>
sur mon RAID 5 à 6 disques en SATA 3 (trois contrôleurs) que sur un<br>
SSD unique. Sans doute une limitation de l'unique interface SATA<br>
(supposée SATA 3 mais qui visiblement sature bien avant d'atteindre le<br>
débit maximum supposé).<br>
<br>
Visiblement nos SSD actuels ont un dispositif qui limite leurs<br>
performance (sans doute dans la table d'index des secteurs), je ne<br>
sais pas trop où mais ça me laisse dubitatif sur même la cohérence des<br>
données qu'ils stockent. D'ailleurs à débit élevé on voit très<br>
nettement des pauses assez longues entre des séquences de "burst". Ces<br>
pauses ont des conséquences car l'OS met le thread en attente et ne le<br>
réactive aussi qu'après un certain délai quand il pense pouvoir faire<br>
quelquechose d'autre comme des processus de maintenance automatique.<br>
<br>
Je ne vois, lors de débits I/O massifs, pas de réel gain du SSD par<br>
rapport au RAID, pire je vois des pauses bien plus longues où les<br>
threads sont mis en sommeil bien plus longtemps, et les cores de CPU<br>
passent en mode basse énergie et basse fréquence et sont assez longs à<br>
réveiller : trop de cores en fait restent en sommeil et ne font rien<br>
du tout sur la config SSD, et le nombre et la fréquence de pages qui<br>
sont mises en "swap out" de façon anticipée explose (ces swaps sont<br>
d'ailleurs prioritaires sur toutes les autres I/O et peuvent être<br>
responsables de ces délais).<br>
<br>
L'OS y est aussi certainement pour quelquechose. Mais je n'ai pas<br>
envie de fouiller pour savoir pourquoi, la solution de contournement<br>
sera trop spécifique à une seule instance de l'OS et ne résistera pas<br>
à la mise à jour d'un pilote ou d'un service annexe (y compris une<br>
solution logicielle de sécurité mise à jour tous les jours).<br>
<br>
De toute façon, un SSD ne permet pas de stocker à pris raisonnable<br>
tout ce dont on a besoin pour l'OS, la base de données, les services,<br>
et les outils qu'on utilise autour. Je garde le SSD uniquement pour le<br>
logiciel, pas pour les données ni pour la partition de swap en stripe<br>
sur un petit volume RAID distinct, et ça suffit. Question coût aussi.<br>
Si on veut plus de performance, c'est plus rentable de meetre à jour<br>
son serveur SQL pour qu'il puisse utiliser de nouvelles méthodes<br>
d'indexation et formats de stockage, et de faire un peu de tuning SQL<br>
(surtout aussi pour optimiser les requêtes en fouillant les plans<br>
d'exécution pour trouver les goulots d'étranglement)<br>
<br>
Le 4 juillet 2012 22:45, Vincent de Chateau-Thierry <<a href="mailto:vdct@laposte.net" target="_blank">vdct@laposte.net</a>> a écrit :<br>
<div>> <a href="http://lists.openstreetmap.org/pipermail/dev-fr/2012-June/000974.html" target="_blank">http://lists.openstreetmap.org/pipermail/dev-fr/2012-June/000974.html</a><br>
><br>
> Philippe, si tu as des éléments probants, c'est le moment. Du concret, du<br>
> factuel, bref, du constructif...<br>
<br>
</div><div><div>_______________________________________________<br>
dev-fr mailing list<br>
<a href="mailto:dev-fr@openstreetmap.org" target="_blank">dev-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/dev-fr" target="_blank">http://lists.openstreetmap.org/listinfo/dev-fr</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Philippe</div><div>Allgoob SA</div><br>
</div></div>