Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 4 sur 4
  1. #1
    Membre émérite Avatar de jmnicolas
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2007
    Messages
    408
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Transports

    Informations forums :
    Inscription : juin 2007
    Messages : 408
    Points : 839
    Points
    839

    Par défaut Configuration matérielle inadaptée, remèdes ?

    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.
    The greatest shortcoming of the human race is our inability to understand the exponential function. Albert A. Bartlett

    La plus grande lacune de la race humaine c'est notre incapacité à comprendre la fonction exponentielle.

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 362
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 362
    Points : 27 472
    Points
    27 472

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  3. #3
    Membre émérite Avatar de jmnicolas
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2007
    Messages
    408
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Transports

    Informations forums :
    Inscription : juin 2007
    Messages : 408
    Points : 839
    Points
    839

    Par défaut

    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.
    The greatest shortcoming of the human race is our inability to understand the exponential function. Albert A. Bartlett

    La plus grande lacune de la race humaine c'est notre incapacité à comprendre la fonction exponentielle.

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 362
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 362
    Points : 27 472
    Points
    27 472

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •