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

Décisions SGBD Discussion :

Hardware serveur SGBD


Sujet :

Décisions SGBD

  1. #1
    Membre du Club
    Homme Profil pro
    Inscrit en
    juin 2008
    Messages
    56
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : juin 2008
    Messages : 56
    Points : 50
    Points
    50
    Par défaut Hardware serveur SGBD
    Bonjour.

    Je dois changer notre serveur SGDB car il a maintenant 8 ans !

    Le serveur actuel est le suivant:
    - Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz
    - 64Go de RAM
    - Deux SSD de 160Go en Raid 1
    - Fonctionne Actuellement avec PostGreSQL 9

    On nous propose le serveur suivant:
    - 2* Epyc 7351 16-Core Processor @ 2.9Ghz
    - 64Go de RAM
    - Deux SSD de 480Go en Raid 1
    - PostGreSQL 13

    On nous a installé le nouveau serveur en test avant qu'un se décide.
    Et évidement on a une copie de nos base afin de contrôler le bon fonctionnement de PostgreSQL13 !

    C'est assez difficile de comparer un serveur en production avec un serveur tout neuf qui ne fait rien,
    mais la performance est la suivante:
    - 2 fois plus rapide sur les requêtes complexes nécessitant un nombre important de jointure.
    - jusqu'à 10 fois plus rapide avec les requêtes utilisant moins de jointure.

    Globalement on obtient un *3

    Pour bien faire faudrait que je refasse tous ces test la nuit lorsque le serveur actuel est vraiment peu chargé !

    Bon...
    Notre base n'est pas sollicitée par des tas de requête simultanées.
    Certaines requêtes par contre peuvent prendre plusieurs dizaine de seconde.

    Est-ce que quelqu'un aurait une proposition de config que je pourrais étudier et qui pourrait offrir de meilleures performances ?

    J'aime bien le Xeon W-2275, plus rapide en Single Thread...

    En vous remerciant,

  2. #2
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Consultant Teradata
    Inscrit en
    septembre 2008
    Messages
    8 278
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant Teradata
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2008
    Messages : 8 278
    Points : 17 275
    Points
    17 275
    Par défaut
    Il faut aussi que vous sachiez répondre à ces questions :
    - quel est l'amortissement de votre nouveau serveur (si c'est 3, 5 ou 8 ans, ce n'est pas pareil).
    - quelle est la taille de votre base de données aujourd'hui, et quelle sera sa taille à la fin de l'amortissement ?
    - vos traitements sont-ils bien parallélisés quand c'est possible ?

    Et enfin une remarque, deux disques en Raid1 c'est le minimum, et ça me paraît faible en comparaison du CPU.
    Essayez de faire du profiling sur l'utilisation actuelle de vos disques durs en fonction des fichiers de données, des journaux etc.

    Idem la RAM me paraît juste aussi (autant aujourd'hui qu'il y a huit ans ?) - enfin si votre base fait 40 Go c'est bien suffisant.

  3. #3
    Membre du Club
    Homme Profil pro
    Inscrit en
    juin 2008
    Messages
    56
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : juin 2008
    Messages : 56
    Points : 50
    Points
    50
    Par défaut
    Bonjour.
    Alors l'amortissement, on oublie, ça n'entre pas en ligne de compte dans mon cas. Moi on m'a juste demandé de changer le serveur !
    Evidemment, vous voyez la config que j'a donnée qui doit tourner dans les 4000€. Le budget n'est pas illimité.

    La base de donnée fait 192Go
    c'est ce que retourne la commande : SELECT pg_size_pretty(pg_database_size('ext_v2'));.

    Enfin sur la parallélisation et bien on a fait de notre mieux !
    La plupart des requêtes sont exécutées depuis une application et donc s’exécute en // par défaut.

    Si vous me parlez des gros requêtes qui prennent du temps, elles sont composés de jointures entre plusieurs grosses tables.
    Parfois le EXPLAIN montre que l'optimiseur n'a pas su utiliser le meilleur index, mais je ne vais pas me substituer à l'optimiseur.
    Je ne sais pas s'il y a quelques chose à faire pour paralléliser ces traitements !

    En fait, j'avoue ne pas comprendre votre question? que veux dire "vos traitements sont-ils bien parallélisés quand c'est possible ?"

    Cordialement,
    Etienne

  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 181
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : mai 2002
    Messages : 21 181
    Points : 50 419
    Points
    50 419
    Billets dans le blog
    1
    Par défaut
    Si vous n'avez qu'un seul stockage, alors optez pour des disques SSD "write intensive". Des SSD ordinaire n'ont pas un grand intérêt pour un SGBD relationnel dont 99% des lectures devraient s'effectuer depuis le cache (RAM).

    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. suite au crashage de serveur SGBD
    Par joujousagem2006 dans le forum Administration
    Réponses: 4
    Dernier message: 22/06/2014, 16h04
  2. Audit Connexion sur mon Serveur SGBD
    Par joujousagem2006 dans le forum Administration
    Réponses: 1
    Dernier message: 06/11/2013, 15h46
  3. url d'un serveur SGBD distant
    Par barchoui dans le forum JDBC
    Réponses: 1
    Dernier message: 23/01/2009, 05h02

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