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

[Philippe Verdy]

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...