Vous n'êtes pas identifié(e).
Bonjour à tous,
Ne trouvant pas de posts à ce sujet, je me permets d'en écrire un :
J'aimerai savoir s'il est possible avec PostGreSQL d'optimiser le serveur pour une utilisation sur mémoire flash.
En effet, les cartes flash étant limitées en nombre d'écriture, j'aimerai pouvoir limiter le nombre d'écritures sur la flash en sorte de rallonger sa durée de vie.
En fait, est ce qu'il est possible d'avoir une base chargée uniquement en RAM, qui, périodiquement, se réplique sur une base en Flashdisk, après qu'une certaine quantité de données à ajouter soit présente en RAM?
Cordialement,
Mathieu
Hors ligne
Je suppose que c'est pour de l'embarqué et PostgreSQL n'est clairement pas le bon choix pour cela.
Guillaume.
Hors ligne
Je précise un peu plus. C'est possible à faire, mais c'est assez complexe. Il faut créer un ram disk, déplacer le contenu de PGDATA dans ce ramdisk et exécuter PostgreSQL à partir de là. À l'arrêt, il faut faire l'opération inverse. Bref, un tas de scripts à écrire et à tester intensivement.
Guillaume.
Hors ligne
Merci gleu pour cette réponse rapide.
En effet, j'étais en train de lire de la documentation sur une stratégie RAM Disk, avec comme tu le dis, des scripts de récupération du rep data sur extinction de la console, et opération inverse après démarrage.
Je risque aussi, lors d'une coupure de courant de perdre des données.
Tu me confirmes donc que PostGreSQL ne gère pas cela en natif et que seul le recours à une solution à base de RamDisk est envisageable?
Hors ligne
La perte de données possibles est dû au fait que tout PostgreSQL sera stocké en mémoire le temps de l'exécution. Dans ce cas, en cas de crash machine, tu perdras tout ce qui était en RAM (sauf si c'est du Flash par exemple, mais dans ce cas au redémarrage il ne faut surtout pas copier ce qui est sur disque en RAM flash car tu écraserais le précédent). Enfin bon, ça devient rapidement complexe. N'étant pas un expert de l'embarqué, j'aurais du mal à répondre plus précisément.
Ce qu'il faut bien voir, c'est que PostgreSQL met en cache une partie des données, la taille de la partie dépendant du paramètre shared_buffers. Mais chaque fois que des modifications sont faites, elles sont immédiatement inscrites dans les journaux de transactions (non désactivables), puis un peu plus tard dans les fichiers de données. Donc double écriture pour une même modification, donc peu intéressant dans le cas de l'embarqué.
Maintenant, si ce n'est pas de l'embarqué, je n'ai jamais vu un cas où mettre le stockage d'une base en mémoire ait une quelconque importance. PostgreSQL se débrouille très bien avec son cache disque.
Guillaume.
Hors ligne
Je fais bien de l'embarqué, ainsi comme tu le dis, cela a de l'importance de gérer la mémoire.
En continuant mes recherches, toujours sur le Ram disk, j'ai remarqué que je pouvais créer un tablespace sur mon ram disk.
Est ce que cette solution est intéressante? Je crois que PostGreSQL écrira uniquement dans le tablespace que je lui indique, n'est ce pas?
L'autre souci, est de synchroniser un tablespace en RAM, avec un tablespace miroir en flashdisk. Mis à part le pg_dump et pg_restore périodique, n'y a t'il pas une solution plus propre?
(juste pour l'info, ma RAM est volatile)
Hors ligne
Le tablespace est intéressant pour les fichiers de données, pas pour les journaux de transactions. Et de toute façon, ça n'enlève pas le problème de déplacement des données de la mémoire volatile vers la mémoire permanente. Le tablespace miroir peut se faire avec un jeu de trigger, mais le problème reste le même. Pour être sûr que ce tablespace soit sécurisé, il doit être sur disque. Donc en gros, tu vas galérer pour installer ton système sur RAM qui fait un miroir sur un tablespace sur disque... de toute façon, tu vas finir par écrire sur le disque en permanence. La solution pg_dump/pg_restore semble la plus intéressante, à condition d'avoir une fréquence peu importante et donc d'accepter le risque de perte de données sur cette durée. Et même comme ça, ça veut dire que tu vas écrire ta base entière tout les X minutes, au lieu de la laisser vivre normalement. Pas sûr que tu sois gagnant.
Question certainement conne, mais bon je risque rien à la poser 
As-tu déjà testé en utilisation normale ? est-ce vraiment gênant pour toi ?
Guillaume.
Hors ligne
Au niveau des journaux de transaction, si j'ai beau écrire mes données sur un tablespace pointant ma RAM, les journaux seront mis à jour sur le disque c'est çà? Peut on déplacer les journaux sur la RAM?
Pour ce qui est de l'utilisation normale, cela fonctionne, mais j'ai bien peur de détruire ma carte flash en très peu de temps, alors qu'il faut un minimum de maintenance.
En fait, pour être plus concret sur la structure de ma base, je dispose de plusieurs tables (moins de 10) qui seront statiques. Elles seront rarement mises à jour.
Une autre table servira d'historisation d'évènements. C'est cette table qui va être assez fréquemment mise à jour, et c'est celle là que je souhaite mettre sur la RAM.
Je souhaite effectuer un transfert des données écrites dans la RAM vers la FLASH, toutes les minutes à peu près, alors que la table d'historisation peut se voir ajouter plusieurs entrées à la minute. (cela reste normalement peu fréquent, mais je dois faire face à l'imprévu ;p)
Au pire, si le problème des journaux est tel que tu me l'a décrit, je peux toujours effectuer une copie de ma base entière en RAM au démarrage et la sauvegarder toutes les minutes?
Pour l'info, une coupure de courant ne peut normalement pas arriver, et si cela arrive, alors les données apparues dans la dernière minute seront perdues, et ce n'est "pas grave".
Hors ligne
Peut on déplacer les journaux sur la RAM?
Oui à condition de le faire avant d'exécuter PostgreSQL. Mais en cas d'arrêt brutal de la machine, c'est terminé, tu ne récupères plus rien. Tu es bon pour repartir de la sauvegarde... quoique dans un embarqué, pas sûr que tu aies une sauvegarde
Je souhaite effectuer un transfert des données écrites dans la RAM vers la FLASH, toutes les minutes à peu près, alors que la table d'historisation peut se voir ajouter plusieurs entrées à la minute. (cela reste normalement peu fréquent, mais je dois faire face à l'imprévu ;p)
Donc un pg_dump toutes les minutes ? tu ferais bien mieux de faire confiance à PostgreSQL... voire de changer complètement de SGBD. Tu auras certainement des écritures plus fréquentes, mais sur beaucoup moins d'octets.
Au pire, si le problème des journaux est tel que tu me l'a décrit, je peux toujours effectuer une copie de ma base entière en RAM au démarrage et la sauvegarder toutes les minutes?
Ça ne change pas le problème pour les journaux de transactions.
Ton vrai problème se trouve là. Les journaux de transactions sont une partie essentielle de PostgreSQL et ne peuvent être désactivés. Les placer sur une partie de RAM volatile me fait craindre le pire pour tes données. Les placer dans la flash va forcément diminuer leur durée de vie. Avec une 8.3, tu as le gros intérêt de ne pas enregistrer des infos lors de requêtes de sélection. Par contre, toute modification générera des données dans les journaux de transactions.
Si tu souhaites rester avec PostgreSQL, il me semble que le mieux est de l'installer comme en standard. Faire autrement me paraît soit très risqué, soit sans intérêt pour la durée de vie des Flash... soit les deux.
Guillaume.
Hors ligne
Ok merci pour ton avis gleu.
Je venais de téléphoner à un collègue qui a fait le même système et comme tu l'as prédit, il a laissé le serveur en standard sur la flash... Le système tourne depuis 1 an, et pas de problème.
Je suis donc de ton avis, et je vais suivre ta stratégie.
Merci pour ton soutien!
Hors ligne
De rien
On serait ravi de connaître la suite de ton projet. Même chose pour ton collègue. Ça peut se faire sous la forme d'un témoignage ou d'une interview ou d'un article. Soit en rédaction libre, soit avec une aide (de ma part par exemple). Le tout aurait pour but d'être posté sur le site de PostgreSQLfr. Tiens-moi au courant si cela t'intéresse.
Guillaume.
Hors ligne
Pourquoi pas!
Bien sur, je ne pourrai pas rentrer dans les détails pour des raisons évidentes de confidentialité (je fais çà dans une activité pro). J'espère avoir terminé cette partie du projet d'ici fin mars, et, pour avoir des retours satisfaisants sur le nombre d'écritures, il faudra attendre encore 1 mois.
Ainsi, si tu me rappelles d'ici fin mars, début avril, il n'y a aucun problème pour l'article!
(Si tu ne me le rappelles pas, j'aurai certainement oublié, car j'aurai certainement la tête dans d'autres activités!!)
Hors ligne
OK, c'est noté
Guillaume.
Hors ligne
