IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration PostgreSQL Discussion :

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


Sujet :

Administration PostgreSQL

  1. #1
    Membre éprouvé Avatar de jmnicolas
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2007
    Messages
    427
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France

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

    Informations forums :
    Inscription : Juin 2007
    Messages : 427
    Points : 976
    Points
    976
    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
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    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
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre éprouvé Avatar de jmnicolas
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2007
    Messages
    427
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France

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

    Informations forums :
    Inscription : Juin 2007
    Messages : 427
    Points : 976
    Points
    976
    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
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    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
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Quelle configuration matériel réseau ?
    Par flysurfer dans le forum Administration
    Réponses: 1
    Dernier message: 13/11/2008, 16h36
  2. Configuration matérielle requise pour Solaris 10
    Par mithrendil dans le forum Solaris
    Réponses: 4
    Dernier message: 14/08/2008, 23h14
  3. Récupérer la configuration matériel
    Par d.w.d dans le forum Windows
    Réponses: 3
    Dernier message: 19/12/2006, 13h24
  4. Besoin de conseils pour changer de configuration matériel
    Par lnplnp dans le forum Ordinateurs
    Réponses: 9
    Dernier message: 18/04/2006, 00h27
  5. Réponses: 1
    Dernier message: 22/03/2005, 15h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo