Configuration matérielle inadaptée, remèdes ?

[jmnicolas]

Bonjour,

Nous avons une flotte d'une quarantaine de véhicules (autobus) équipés d'un dispositif qui enregistre les infos du CAN FMS (c'est un bus électronique sur lesquelles toutes les infos du véhicule circulent : vitesse, kilométrage, tours moteurs etc).

Les données sont récupérées par Wifi lorsque les véhicules sont chez nous et sont intégrées dans une base Postgresql 8.4.8 hébergée sur une machine virtuelle Debian 6.0.

L'hôte est un hyperviseur Xen (2 Xeons 4 core récents cadencés à 2.4ghz, 16 GO RAM), qui alloue 2 coeurs et 4 GO de RAM à la machine virtuelle. Le stockage se fait sur un SAN partagé par plusieurs machines virtuelles (une dizaine).

Sachant que nos enregistreurs remontent une donnée par seconde, qu'il y a 40 véhicules et qu'on les exploite environ 15h par jour on atteint déjà plus de 100 millions de lignes dans trois des tables de la base, et la moindre requête pour obtenir le kilométrage quotidien d'un véhicule s'exécute en pas moins de 3 minutes.

La base va continuer à grossir (elle fait un peu moins de 100GO là), et on va sans doute rajouter une dizaine de véhicules d'ici un an. Les performances sont mauvaises, mais vu la configuration c'est normal.

Le stockage est clairement le goulot d'étranglement. On a imaginé 2 solutions pour y palier, sachant qu'on a un budget très faible : c'est pour faire des stats, c'est pas un projet vital. Un down serveur n'est pas impensable, tant qu'on ne perd pas de données.

- monter un serveur dédié à partir de composants grand public : processeur de monsieur tout le monde, ram non ecc/registered, disques SATA en raid logiciel etc.

- installer un contrôleur RAID supplémentaire avec des disques SAS dans un des hyperviseurs et y placer la base dessus. A voir si on peut y rajouter de la RAM aussi.

Dans tous les cas des disques SSD se justifieraient ils, ou le simple passage à un "vrai" stockage (par rapport au SAN) va améliorer spectaculairement les perfs de la base ?

Vous en pensez quoi ? Vous voyez d'autres solutions ?

edit : je viens de me rendre compte que notre base n'utilise pas ou très peu d'index (juste sur les clés primaires). N'étant pas DBA de formation, ce détail m'avait échappé, surtout que je connais assez peu l'utilisation des index.C'est sans doute une piste à creuser.

[SQLpro]

Déjà un point merdique, la virtualisation des SGBDR. Aucun éditeur de SGBDR, d'oracle à SQL server ne vous recommandera de faire de la virtualisation si vous voulez des performances. En général, la virtualisation tue les perfs des SGBDR.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p8...irtualisation/
En sus vous partagez un san et même cala sans virtualisation est une bêtise si c'est mal fait. A lire : http://blog.developpez.com/sqlpro/p8...t-le-stocakge/

ensuite votretable de 100 millions de lignes ne devrait pas être un problème si elle est bien modélisée et correctement indexée. Puis-je avoir un exemple du modèle autour de cette table (CREATE TABLE...) ? Ainsi qu'un court, mais représentatif, jeu d'essais ??? (INSERT INTO ...)

Dans tous les cas des disques SSD se justifieraient ils, ou le simple passage à un "vrai" stockage (par rapport au SAN) va améliorer spectaculairement les perfs de la base ?

Le problème des disques SSD est qu'ils se détruisent au bout de 700 000 cycles d'écritures. Or dans certaines bases, ceci arrive en quelques mois...
mais effectivement et comme mentionné dans l'article que j'ai écrit, l'organisation des disques et le choix du serveur sont des choses importantes.

Ne certainement pas opter pour un PC bricolé, mais un vrai serveur fait pour les SGBDR comme Oracle ou SQL Server, les bus étant spécifiques (gros débit)... fabriquer cela avec du bricolé sous le manteau vous reviendra notablement plus cher...
Exemple, gamme HP DL 380 (minimum) avec pas mal de RAM (dépend du volume de votre base à terme... mettons 3 à 5 ans)
Mettez des disques en RAID 10 (2 grappes)
En occasion, vous trouverez cal pas cher... Exemple : http://www.priceminister.com/offer/b...de-bureau.html
http://www.priceminister.com/offer/b...de-bureau.html
Reste à prendre 8 bons disques 15 000 tours minutes...

Enfin un certains nombre de réglages sont à prévoir dans PG.

A +

[jmnicolas]

Bonjour,

J'ai ajouté des indexes mais ça n'a rien changé au temps de requête.
Nous arrivons aussi à saturation d'espace disque.

On va finalement avoir un budget à consacrer à ce serveur et on va partir sur l'achat d'une machine neuve.

Je note que vous recommandez un HP DL 380 (leur site est vraiment fouillis je trouve).
Pour le processeur, j'ai lu qu'il valait mieux privilégier la fréquence au nombre de cœurs si on avait quelques grosses requêtes plutôt que plein de petites.

Par contre pour la RAM je ne vois pas trop ce qu'il nous faut si on estime notre stockage à 500GO dans 3 ans.
J'imagine bien que plus il y en a mieux c'est, mais je n'arrive pas à quantifier plus précisément.

En tout cas merci pour vos conseils.

[SQLpro]

Pour un serveur de SGBDR il faut :
1) beaucoup de RAM. Vu votre base, à vu de nez je dirais 64 Go
2) des disques à haute vitesse de rotation (15 000 tpm) organisé en RAID 0+1 ou 10
3) les processeurs ne bossant pas beaucoup et PG étant incapable de faire du parallélisme sur une même requête il est parfaitement inutile d'utiliser le CPU dernier cri. Un modèle n-1 voire n-2 est largement suffisant.

Enfin, il ne faut JAMAIS saturer les disques. Prévenir à 70% de taux de remplissage, réorganiser à 80, ajouter des disques supplémentaire à 90%...

A +