Vous n'êtes pas identifié(e).
Pages : 1
bonjour,
quelqu'un a-t-il un conseil pro pour un SSD 64Go destiné à booster une base de données (postgresql81) sur un serveur ?
bien entendu, la sécurité et la qualité du disque doit primer sur le reste (vitesse et capacité).
Est-ce vrai que dans tous les cas, un SSD apportera un gain de x10 par rapport à un disque dur ?
Si quelqu'un a déjà fait l'expérience des gains en base de données avec un SSD, qu'il partage...
bien à vous
Hors ligne
Ce n'est pas vrai dans tous les cas, loin de là.
Un SSD va faire X10, voire largement plus, par rapport à un disque dur mécanique, sur les accès aléatoires. Sur le séquentiel c'est largement comparable.
Par ailleurs, vous avez bien d'autres priorités à mon avis que le SSD pour accélérer votre base:
- Passer à une version supportée de PostgreSQL
- Optimiser l'application (64Go de données, c'est vraiment peu, il est surprenant qu'une application de cette taille rame)
Ensuite, pour que le passage au SSD soit rentable, il faut vraiment être sûr que c'est le disque votre source de contention actuelle.
Et pour finir, n'oubliez pas que le SSD est rapide (~ 0.1ms de temps d'accès, ~ 200Mo/s de débit), mais qu'il est déjà beaucoup moins bon en écriture (même si les derniers disques durs compensent en bonne partie les problèmes de write amplification), donc que si votre problème c'est les performances en écriture, il n'est pas sûr que votre gain soit vraiment énorme. Les écritures (sauf pour le journal, mais c'est de l'écriture séquentielle) sont par nature asynchrones, donc peuvent être regroupées, ce qui efface une bonne partie du gain du SSD par rapport au disque dur.
Un dernier point: si vous voulez vraiment rajouter du matériel, posez vous la question de rajouter de la RAM dans votre serveur: c'est encore bien plus rapide que le SSD (1ns de temps d'accès, plusieurs Go/s de débit). Rien de tel qu'une base en cache pour avoir des requêtes rapides en lecture…
Pour l'instant on rencontre encore assez peu de SSD en production. Il faut dire que depuis leur arrivée, il y a pas mal d'histoires de données qui disparaissent totalement des disques sans laisser de nouvelles. Par exemple, il y a eu de mémoire le cas sur une des dernières séries de SSD Intel (un bug du firmware).
Sinon, si vous cherchez des modèles précis de SSD, allez regarder dans la mailing list postgresql-performance, la question y revient régulièrement.
Marc.
Hors ligne
+ 1 pour la ram
mais alors la question que tout le monde se pose peu t'on dire à postgresql de chager la totalité de le base de donnee si elle n'est pas trop grosse biensur en memoire
(< a la ram quoi)
et de faire des sauvegarde reguliere sur le disque dur avant la femerture ou doit t'on passer par un ram disque et un script ?
ce qui reviendrai a
je demare le serveur
un script cree un ram disque et charge la bdd entiere dans la ram
//eventuelement des sauvegarde de la bdd sur le disque dure a interval regulier si pas d'ondulateur mais la c'est du suicide
je veux eteindre le serveur pour remplacer un ventilo par exemple
je doit avoir un script qui sauvegarde la bdd sur le disque dur avant de seteindre
sans compte sil ya une panne electrique avec un onduleur
pour sauvegarder proprement la bdd avant le drame
Hors ligne
merci de votre conseil.
en fait une fois la base de données vacummée manuellement à 100% et réindexées totalement elle ne prend que 120Mo.
par contre en fin de journée elle atteind le 1.2Go de données (beaucoup de choses sont supprimées, puis remis à jour).
Hors ligne
@aznur: Postgresql se chargera tout seul de garder en mémoire autant de données qu'il peut, selon ce qui est accédé par les utilisateurs et la quantité de mémoire partagée configurée. Ensuite, tant que l'instance est en marche, les données modifiées sont sauvegardées au fur et à mesure à la fois dans les wal (synchrone) et dans les fichiers de données (asynchrone). Il ne faut pas oublier que postgresql s'appuie fortement sur le système, et donc sur le cache disque de celui-ci. Il est généralement déconseillé de mettre plus d'1/4 de la ram en shared_buffers, car de toutes façons une partie des données se trouvera également en cache système.
@Michael: 1.2 Go reste une petite volumétrie. Par contre, le facteur 10 de croissance dans la journée est étrange. L'autovacuum est-il activé ? Si oui peut-être n'est-il pas assez aggressif.
Julien.
https://rjuju.github.io/
Hors ligne
non l'autovacum a été désactivé car en journée, il nuit fortement à la base et ralenti le travail des collègues. c'est pour ça que je le programme la nuit, (où le fait moi-même à la mi journée)
Hors ligne
c'est pour ça qu'il vous dit de passer en 9.1, l'auto-vacuum marche très bien et ne pénalise plus le serveur
Hors ligne
Pages : 1
