base de données en mémoire

[jose.ignacio.agata]

bonjour à tous

nous avons un soucis très temporaire sur un serveur qui 'conserve' en mémoire (RAM) une base de données... Lors de l'arrêt du serveur, nous retrouvons la base qui date de quelques jours. Les backups sont faits sur la base se trouvant sur le disque dur.... mais qui date de plusieurs jours.

Nous avons fait l'essai suivant : lorsque ca arrive, nous détruisons physiquement la base de données. Mais nous avons toujours accès à son image depuis un client firebird. Toutes les opérations sont possibles.... jusqu'au firebird stop.

Nous n'avons pas encore fait d'essais avec un force writes à ON mais apparemment, cela n'a rien à voir.

Environnent : FB sous linux, version 2.0.3 mais idem sous 1.5

Avez vous des expériences identiques ? des idées ?

[makowski]

quel Linux ? quel noyau ?
quel système de fichier ?
quelle valeur du database cache ?
quelle taille de page ?
combien de pages à la base ?
Firebird Classic ou Superserver ?

[jose.ignacio.agata]

superserveur, configuration par défaut, OpenSuse

la base est relativement grosse, vers les 2gb. Elle a actuellement aux alentours de 100 000 transactions/jour. Le moteur (di)gère une centaine de bases mais moins utilisées. On tourne sur du biprocesseur intel avec 4gb de mémoire. Disque sata en raid 5.

[makowski]

dans un cas comme ça, impossible de répondre sans avoir une idée exacte de la situation
mais franchement, je penche plus pour un problème au niveau du RAID
Firebird écrit immédiatement ses données dans le fichier de base
un commit est un commit, pas une écriture phantomatique

en tout cas, difficile d'en dire plus à travers un forum, surtout au vu des réponses évasives à mes questions précises

[jose.ignacio.agata]

merci pour la réponse et désolé pour les réponses évasives.
page size : 4096
pages : 845
database cache : valeur par défaut = 2048
linux: opensuse 10.2
noyau: 2.6
système de fichier: samba


nous allons vérifier le RAID qui est en fait en raid 1. Mais cela nous l'a fait sur des machines de test sans raid.

Ce que nous avons du mal à comprendre, c'est comment la base peut rester fantôme tant de temps. Et nous avons pu faire des insert, updates, select, etc... pendant tout ce temps, que ce soit depuis l'application ou le backoffice. Nous travaillons sous .Net et Delphi7. Les applications sont des dll tournant sous IIS6 et les bases sont sous linux.

Autre point sans doute important : cela semble lié à une opération de backup restore. Bien que nous ayons eu des cas hors ces opérations de maintenance.

Le seul point sensible me semble être le force write mais comment va gérer le Disque avec des centaines de milliers de transactions par jour ?

[makowski]

Code :

système de fichier: samba

ce n'est pas le système de fichier ça
l'accès à la base ne se fait pas par Samba et j'espère bien que votre base n'est pas sur un répertoire partagé Samba !

Seul le serveur Firebird doit avoir accès au fichier de la base, personne d'autre et surtout pas des utilisateurs réseaux windows !

page size : 4096
pages : 845

cette base ne fait pas 2gb 845 x 4096 n'ont jamais fait 2Go ou alors ce n'est pas le vrai nombre de pages

[jose.ignacio.agata]

je te rassure, on ne passe pas par samba. Ca tourne sous NFS.

[makowski]

sous NFS ?
c'est quoi exactement votre architecture ?

ps les données sur les nombres de pages sont certainement faux, une base de 2go ne peut avoir que 845 pages de 4096 !

[jose.ignacio.agata]

la base dont on parle fait 500mo après backup/restore. Mais on a eu le pb avec une base beaucoup plus grosse.

On a un cluster avec firewall/loadbalancing/6 IIS suivis de 10 linux. Les IIS ont les dll et les linux ont les FB2.0.3 ou FB1.5.3

Sur cette architecture, on gère un millier de bases qui tournent très bien... sauf nos fantômes.

[makowski]

j'attend une confirmation ou deux, mais bon de toute façon, le Forced Write ne fonctionne pas sous Linux cf http://tracker.firebirdsql.org/browse/CORE-1476

mais vraiment j'aimerais savoir quel systeme de fichier vous utilisez ext2, ext3, xfs ?

le Serveur Firebird accède aux bases via NFS ?
il faut vraiment un maximum de détail dans ce cas pour comprendre ce qui entre en jeu

[jose.ignacio.agata]

le serveur est bien entendu local ; le système de fichier est ext3 (cat /etc/fstab)

[makowski]

ok alors vérifier que le système de fichier est bien monté dans le mode synchronous updates c'est à dire avec l'option sync

sinon, oui, il est possible que tout reste une bon moment dans le cache du système de fichier

Une version future de Firebird devrait permettre d'activer un vrai Forced Write sous Linux

[makowski]

Envoyé par jose.ignacio.agata

Nous avons fait l'essai suivant : lorsque ca arrive, nous détruisons physiquement la base de données. Mais nous avons toujours accès à son image depuis un client firebird. Toutes les opérations sont possibles.... jusqu'au firebird stop.
Environnent : FB sous linux, version 2.0.3 mais idem sous 1.5

tant qu'une connexion est active sur la base, c'est normal, c'est le fonctionnement des fichiers sous *nix
cf http://pmakowski.ibphoenix.fr/post/2...rd-files-posix

quand au problème de "base ancienne sur le disque", seul un système de fichier monté avec l'option sync peut éviter cela, voir dans le cas de ext3, utiliser plutot l'option data=journal
Il y a pas mal de litterature la dessus par exemple :
http://www.arschkrebs.de/postfix/postfix_ext3.shtml
http://www.ibm.com/developerworks/library/l-fs8.html
http://www.linux-france.org/article/...t3fs/ext3.html