Vous n'êtes pas identifié(e).
Pages : 1
Bonjour tout le monde,
Je travaille actuellement avec un moteur PostgreSQL 9.3.2, sous Cent-OS 6.4.
Machine : Xeon-X5650-2.67GHz, 32 Go de RAM, moteur et fichiers traces sur disque 300 Go 10000 tours EXT4, données sur disque 146 Go 15000 tours EXT4, xlog sur disque 146 Go 15000 tours EXT4.
Paramètres : Shared_buffers=8192MB, Max_connections=300, Work_mem=10MB, Maintenance_work_mem=4096MB, Checkpoint_segments=64, Checkpoint_timeout=10min, Effective_cache_size=21840MB, Stats_temp_directory=/ramcache, Log_autovacuum_min_duration=300, Autovacuum_naptime=10min
Taille de la BD = 30Go,
Moyenne journalière Insert=300000, Update=600000, Delete=120000
Moyenne connexions journalière=200
Trois plus grosses tables :
- 50 millions d'enr, 9Go table, 5.6Go index
- 14 millions d'enr, 3.3Go table, 3.6Go index
- 7 millions d'enr, 1.7Go table, 2Go index
Cache Hit/Miss en moyenne à 99%
Dans mon entreprise, j'entends parler de passage au SSD. Qu'en est-il des interrogations sur ce support ? Sont-ils maintenant "fiables" ? les gains de performance sont-ils réels ?
J'ai lu un "vieux" post : "quel SSD pour booster une base de données ?" de 2012, qui parlait de SSD.
Avez-vous des retours d'expérience, des conseils, des infos sur ce support ?
Nous envisageons la mise en place d'un PCA/PRA.
Quelles solutions sont envisageables ?
Faut-il passer à la version 9.5 dans le cas d'une solution de haute disponibilité PostgreSQL ? ou peut-on rester en 9.3.2 ?
Merci pour vos réponses.
Hors ligne
Bonjour,
Les gains de performance avec du SSD sont réels, aucune inquiétude à ce niveau là. Bien entendu, si votre environnement fait que les disques ne sont presque pas sollicités, le gain sera moindre (mais toujours appréciable sur les écritures ou les fichiers temporaires par exemple). Une configuration adéquate du moteur pourra également aporter des gains avec plus d'utilisations d'index.
Comme pour tout matériel, certains modèles sont fiables et d'autres non. Evitez les modèles bas de gamme, et assurez vous qu'ils disposent de mécanisme pour garantir les données en cas d'arrêt électrique (cache non volatile ou protégé par batterie). Certains modèle intel reviennent régulièrement sur les mailing list comme étant performants et sûrs. Si vous utilisez une carte RAID, il faut aussi s'assurer que celle-ci est capable d'envoyer les instructions TRIM aux disques.
Pour la HA, difficile de répondre sans connaître vos besoins. De nombreuses solutions existent (corosync/pacemaker, repmgr...), à vous de choisir la solution qui répond à votre besoin. Passer en 9.5 vous permettrait de bénéficier de l'outil pg_rewind qui permet d'éviter d'avoir à reconstruire un serveur en cas de failback.
Julien.
https://rjuju.github.io/
Hors ligne
J'ai lu http://www.zdnet.com/article/what-we-le … s-in-2015/ aujourd'hui et j'ai trouvé ça plutôt pas mal.
Concernant la question sur la version, la solution est déjà installée ? si oui, la question peut se poser et la réponse de rjuju me convient. Si elle n'est pas encore installée, la question n'a aucun lieu d'être : vous partez en 9.5. Quel intérêt y aurait-il à partir d'une version viellle de plus de deux ans et qui sera donc plus maintenu alors que la 9.5 le sera deux années de plus ? tout ça pour avoir moins de fonctionnalités, moins de performances et moins de corrections ?
Guillaume.
Hors ligne
Bonjour Messieurs,
Merci pour les infos et le lien.
Pour aller plus loin : Comment évaluer la sollicitation des disques ?
- Nous avons des checkpoints toutes les 10min.
- 70% des blocs écrits le sont par les checkpoints,
- Le volume moyen écrit par les checkpoints est de 13MB,
- Le volume global écrit à la seconde est de 30KB,
- Le volume global lu à la seconde est de 2MB.
- La sonde système sur les IO disks nous donne :
- Moyenne Lecture sur disque du moteur à 50k/s,
- Moyenne Ecriture sur disque du moteur à 100k/s,
- Moyenne Lecture sur disque des données à 300k/s,
- Moyenne Ecriture sur disque des données à 53k/s,
Quelles pistes faut-il explorer côté configuration du moteur pour avoir plus d'utilisation d'index ?
Pour la HA : nous avons comme impératif de pouvoir redémarrer en 2 heures, avec une perte de données acceptable de 5 minutes. Rien n'est encore décidé au niveau solution.
Pour la version 9.5 : nous sommes actuellement en 9.3.2, nous pourrons faire un upgrade lors de la mise en place de la HA.
Hors ligne
Bonjour,
Personne pour apporter une réponse à mes questions ?
Merci.
Hors ligne
Pour aller plus loin : Comment évaluer la sollicitation des disques ?
vmstat, iostat, iotop ?
Quelles pistes faut-il explorer côté configuration du moteur pour avoir plus d'utilisation d'index ?
Avant de pouvoir donner une solution, il faut s'intéresser au problème. Je peux très bien dire que diminuer random_page_cost permet de favoriser l'utilisation des index, mais ça ne les force pas pour autant, et ça n'améliorera pas forcément quelques chose pour vous.
Pour la HA : nous avons comme impératif de pouvoir redémarrer en 2 heures, avec une perte de données acceptable de 5 minutes. Rien n'est encore décidé au niveau solution.
Dans ce cas, streaming pour la réplication et failover manuel. Le plus simple, le plus rassurant, et le plus pratique.
Guillaume.
Hors ligne
Bonjour Guillaume,
C'est juste que d'une part : je trouve que notre base est plutôt réactive. Que nous allons mettre en place prochainement quelques purges automatiques de certaines tables (pour ne pas garder un historique trop important inutilement), ce qui devrait apporter encore un peu de gain.
D'autre part, j'avais l'impression, en voyant certaines infos sur le net, que les avis sur les SSD étaient un peu mitigé, d'où ma réticence.
Merci pour les infos.
Hors ligne
Bonjour,
Si tu veux connaître un peu plus sur ce domaine, je te recommande de faire une formation sur le sujet.
Dernière modification par hedvige39 (04/08/2016 14:22:02)
Hors ligne
Les avis sont mitigés. Soit tu as l'avis "c'est génial, ça résout tous les problèmes, etc, etc", ce qui est évidemment faux. Ça en résout certains mais pas tous. Soit tu as l'avis "oula, c'est pas fiable, ça ne tient pas longtemps, etc, etc". La vérité est certainement entre les deux. La fiabilité s'est améliorée, principalement sur les modèles haut de gamme. Il est certainement possible de faire mieux que des disques SSD pour moins cher mais ça demande plus de travail.
Et puis, on manque de benchmarks (publiés et expliqués) sur ce genre de produits avec PostgreSQL.
Bref, mon seul message est "intéressant, mais à tester.. avoir un esprit critique".
Guillaume.
Hors ligne
Surtout, vérifier les spec des disques concernant la fiabilité en cas de panne de courant, et ne pas prendre de modèle d'entrée de gamme.
Julien.
https://rjuju.github.io/
Hors ligne
Pages : 1
