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

Mer 4 Juil 23:15:05 BST 2012

Ok je viens de comprendre : pour votre usage c'est moins de débit que
la fréquence des requêtes qui vous limite. Je n'ai pas encore atteint
en pratique la limite de mon système RAID 6 (d'autant plus que tous
les disques RAID ont un frontal SSD qui absorbe bon nombre d'I/Os). La
réelle limite que j'ai c'est plutôt le débit par interface de
contrôleur, ce que j'ai résolu en multipliant les interfaces, ce qui
reste de toute façon moins cher que les gros SSD qui sont absolument
hors de prix (à plus de 5 euros le Go, c'est la mort, alors que les
SSD classiques de 128Gb sont facturés autour de 1,50 euros / Go).

Pour une base de données de 1 To cela donne un prix de 5000 euros par
SSD (sans compter que pour la maintenance, il va falloir le doubler au
minimum en mirroir RAID 1, plus prévoir de toute façon une sauvegarde
externe sur des volumes à disque dur, et qu'en plus il faudra héberger
le logiciel sur un autre SSD encore, car il y a de grande chance pour
que, lorsqu'un des deux gros SSD plante pour des raisons matérielle,
le second soit aussi planté en même temps par corruption des données
même s'il n'a pas lui-même de panne physique, problème classique des
"solutions" en RAID 1 et RAID 0 qui suffisent pourtant pour le
logiciel, dont on a une sauvegarde stable facilement restaurable en
cas d'accident ou de corruption).

L'autre problème des SSD c'est qu'en pleine charge, leur montée de
température est plus élevée et plus brutale que celle des disques
durs. Leur refroidissement est moins bien conçu et moins facile à
faire. Mal refroidi, leur taux d'erreur est plus élevé que pour les
disques durs qui ont intégré divers systèmes de sécurité et de
stabilisation, qui manquent encore aux SSD qui ne réagissent pas aussi
bien.

Maintenant je n'ais jamais fait d'essai avec une config pour OSM ou
les bases pgSQL/OpenGIS. Mes applications ne sont pas bridées par les
I/O mais davantage par les TPM logiciels au niveau du moteur (lequel
dépend surtout des performances de la mémoire et des coeurs CPU).
Peut-être que vos configs ont trop investi sur les SSD et pas assez
sur la RAM tout simplement, alors que c'est pourtant bien moins
cher/plus rentable, ou sur le choix de l'OS et sa configuration. Enfin
le logiciel bien écrit doit savoir faire une usage intelligent de ses
caches en mémoire pour réduire considérablement les I/O sur les
volumes disques (RAID ou SSD), ou encore le choix des architectures de
bus, ou encore sur le tuning de la base de données basé sur un
monitoring en situation réelle. Cela peut montrer des choix logiciels
pas efficaces (les algorithmes d'indexation notamment, ou les modèles
de données).

J'admet qu'OSM a un modèle beaucoup trop simple (trop plat dans trop
peu de tables avec un stockage quasiment en vrac) qui laisse peu de
place aux optimisations possibles.

Le 4 juillet 2012 23:28, Philippe DAVID <philippe.david at allgoob.com> a écrit :
> 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
>