[OSM-dev-fr] Travailler sur des imports partiels

[Philippe DAVID]

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 <verdy_p at wanadoo.fr>

> 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 <vdct at laposte.net> 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
> dev-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev-fr
>



-- 
Philippe
Allgoob SA
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20120704/12952863/attachment.html>