Discussion :

[g_d_u_m]

Bonjour à tous,

je rencontre des problèmes de performances avec Firebird quant à l'utilisation du disque et je n'arrive pas à trouver d'où cela vient.

Le contexte:
PC Serveur HP Z440, 8Go de RAM, 1 HDD de 500Go, Windows 10 Pro 64bits.
Firebird 2.5.4.26856 64bits installation par défaut.

2 petites bases de données (8Mo max) dans C:\DB

2 services accédant aux BD:
- SymmetricDS 3.7.29 (avec le moteur java jre-7u80) pour synchroniser les 2 bases entre elles (donc 1 engine sur la première base, 1 autre engine sur la seconde), les jobs sont réglés pour se lancer toutes les secondes.
- un service maison faisant des requêtes SELECT, INSERT, DELETE simples (pas de jointures, les clefs sont toutes des Integer, pas de Blobs) et utilisant des Triggers pour réagir aux modifications de SymmetricDS.
D'autres PC avec +/- la même configuration pourront à terme interagir avec le Serveur via SymmetricDS, mais ils n'interviennent pas pour l'instant.


Symptômes:
Dès que je lance SymmetricDS, l'utilisation du disque monte à 100%, avec Firebird pointé comme le plus consommateur d'après le Moniteur de ressources.
Après quelques secondes (fin d'init), l'usage du disque redescend légèrement (80% en moyenne).
Quand je lance le service maison, le disque atteint 100% sans jamais redescendre, tout le système est ralenti (y compris les applications n'utilisant pas Firebird). La diode du disque dur est illuminée fixe.


Hypothèses/tests:
Les flushs de Firebird plombent les accès disques et ralentissent tout le système?
- En utilisant gfix pour passer les deux BD en écritures asynchrones, les performances sont bien meilleures (25% d'utilisation disque en moyenne), mais cette situation n'est pas réellement envisageable à cause des risques de pertes de données (ou pire, de corruption irréversible de la base).
- En déplaçant les bases sur une autre partition du disque système, usage disque à 100%, Windows à genoux.
- En déplaçant les bases de données sur un disque dur externe, les performances sont excellentes!
- Mise à jour des pilotes chipset, stockage, etc, même résultats.

Firebird fait-il une écriture synchrone sur le disque même en cas de lecture de la BD (pour mettre à jour des statistiques par exemple)? Est-il possible de désactiver toute écriture lors d'une simple requête Select?

J'ai du mal à concevoir qu'on ne puisse pas mettre une BD sur le disque système.
Quelles autres tests/pistes d'investigation me suggérez-vous? Augmenter la RAM aiderait-il?
Dois-je forcément passer par un disque dur supplémentaire juste pour deux petites BD de 8Mo?

Toute aide sera la bienvenue!
Gautier.

[g_d_u_m]

J'ai fait un test supplémentaire:

J'ai monté un disque dur interne supplémentaire (je n'avais qu'un SATA II sous la main) de 250Go pour stocker les deux BD.
Après avoir configuré les chemins d'accès aux bases et lancé SymmetricDS, j'obtiens un usage du nouveau disque à 100% avec de temps en temps des baisses à 80%.
Le disque système reste lui globalement à 0%.
Le lancement du service maison (qui ne fait qu'une seule lecture de la totalité d'une des deux bases, via des Select) met des années à se lancer.

Je ne comprends pas pourquoi sur un disque USB il n'y a aucun problème.

J'ai tenté de désactiver Windows Indexer, Windows Search, le défragmenteur, je n'ai pas d'antivirus, j'ai passé Ccleaner, fixé les limites du pagefile (mini 1xRAM, maxi 2xRAM), changé les options d'alimentation, etc. rien ne change.

Personne ne constate des performances dégradées sur un disque interne (même dédié)?
Une idée sur ce qui pose problème svp?

[SergioMaster]

Bonjour,

Personne ne constate des performances dégradées sur un disque interne (même dédié)?
Une idée sur ce qui pose problème svp?

Ce n'est pas que l'on ne voudrait pas aidé mais encore faudrait-il avoir la même configuration. De ce fait on ne se bouscule pas au portillon des réponses
Le problème est certainement SymmetricDS ainsi que sa couche Java plus que Firebird. A mon avis (non éclairé) il doit y avoir une gestion de cache disque quelque part :
- Windows << ce qui expliquerait pourquoi avec le disque USB cela fonctionne
- SymmetricDS << si j'ai bien compris on passe par Java donc il faudrait Jaybird en plus ?
- Firebird << si hors SymmetricDS cela fonctionne je doute

Côté Firebird, il y a plusieurs paramètres (dans firebird.conf) concernant les caches Système de Fichier

# ----------------------------
# File system cache threshold
#
# The threshold value that determines whether Firebird will use file system
# cache or not. File system caching is used if database cache size in pages
# (configured explicitly in database header or via DefaultDbCachePages setting)
# is less than FileSystemCacheThreshold value.
#
# To use file system cache always set FileSystemCacheThreshold to a large value.
# To bypass file system cache for all databases set FileSystemCacheThreshold to
# zero.
#
# Type: integer, measured in database pages
#
#FileSystemCacheThreshold = 65536

# ----------------------------
# File system cache size
#
# This setting controls the maximum amount of RAM used by Windows file system
# cache on 64-bit Windows XP, Windows Server 2003 SP1 or later host. It has no
# effect for Unix hosts in this release yet.
#
# Note that the lowest number presently supported is 10%, and the highest number
# is 95%; numbers outside these limits will be set to the default of 30%.
#
# If the cache size has already been selected when the engine starts the host
# setting will not be changed. Thus you may need to reboot the host for the
# change of this setting to have effect.
#
# To leave host caching settings unchanged set this parameter to 0. This is
# the default parameter value.
#
# Security note
# To adjust the setting engine needs SeIncreaseQuotaPrivilege right. Built-in
# service accounts and administrators have it by default. Installer grants this
# right to Firebird service account. If the engine fails to adjust the cache
# size setting it will log warning message to the firebird.log and continue.
#
# Type: integer, measured in % of total physical RAM
#
#FileSystemCacheSize = 0

et quelques autres.

Pour ma part je n'ai jamais "joué" avec ces valeurs

En fait ma première réaction a surtout été : "mais pourquoi SymmetricDS ?" et "Aie, Java !"

[g_d_u_m]

Bonjour et merci d'avoir pris le temps de répondre à mon problème.

Par curiosité, j'ai totalement arrêté les services (SymmetricDS et le service maison sont arrêtés) et observé les accès disques avec le Moniteur de Ressources lors d'accès BD en lecture avec FlameRobin.
Comme la machine est Windows, il a d'abord fallu attendre que tout le monde se calme, y compris le service Firebird lui-même.

Une fois le régime de croisière atteint, j'ai ouvert une des deux bases de données avec FlameRobin, attendu un peu, puis j'ai fait un "Select * FROM Issues;" qui m'a retourné un seul enregistrement.

Curieusement, si le compteur de lectures sur le fichier BD augmente, celui des écritures aussi.
Encore plus curieusement, ces deux compteurs ne cessent d'évoluer (en décroissant) pendant une bonne minute.

Après un retour à la normale, je retente le Select.
Aucun accès en lecture (je m'y attendais; puisque j'accède à la même table, la lecture se fait dans un cache mémoire de Firebird), par contre, les accès en écriture recommencent (4096 octets par seconde, puis 2048, 1365, 1024, puis ça décroit jusque 0 en une minute).



J'ai l'impression que le Moniteur de Ressources affiche des résultats moyennés sur une minute glissante.

J'ai tenté un autre essai, cette fois-ci avec une application maison qui se contente de lire quelques tables de la base et d'en afficher les contenus.
Pas de SymmetricDS, pas de FlameRobin, juste l'application maison et le service Firebird.
Elle met 14 secondes à lire ses données (accès en lecture et en écriture en pagaille).
Si je mets les bases sur un disque USB, elle met 1.5 secondes à lire les même données.

Je vois deux explications possibles (y en a-t-il d'autres?):
- Firebird flushe des mises à jour des tables MON$ ou quelque chose comme ça. Si c'est le cas, est-il possible de désactiver ces écritures (je n'ai pas besoin des stats)?
- SymmetricDS a ajouté des triggers pour surveiller les modifications des tables et ces triggers font des Inserts dans ses tables SYM_*, mais il me semble que les triggers ne sont activés que sur des Inserts, Update ou Delete (ce qui semble logique pour un service de synchronisation de bases).

Je vais tenter de recréer des bases sans aucune trace de SymmetricDS et je reviens publier les résultats.

Merci.

[g_d_u_m]

Nouvelle BD avec quelques données, même symptômes: chaque accès en lecture se traduit par un accès disque en écriture.
On peut donc mettre SymmetricDS hors de cause, cela semble bien être une action interne à Firebird (tables MON$ ?)



Est-il possible de désactiver ces écritures?

[g_d_u_m]

Personne ne sait comment empêcher Firebird de faire Ecriture + Flush à la moindre requête Select (à part passer en écritures asynchrones pour éviter le Flush)?

[Artemus24]

Salut g_d_u_m..

Comme le dit SergioMaster, il faudrait reproduire la même configuration pour identifier le problème.
En ce qui me concerne, je travaille directement avec FireBird, sans passer par une couche intermédiaire (même pas FlameRobin).
Et je n'ai pas rencontré ce genre de problème de performance.
De plus, comme SergioMaster, je n'ai jamais bidouiller dans les fichiers paramétrages de FireBird.
Autrement dit, je travaille d'une manière native.

Si le disque est très sollicité (le disque dédié à vos bases de données, autre que système), c'est bien une couche de votre application qui est en cause.
Je ne voie qu'un mouchard, c'est-à-dire un mode trace ou quelque chose dans ce genre.

Je ne crois pas aux stats qui consommeraient les accès aux disques.
Peut-être les triggers ??? Avez-vous essayez de les désactiver ?
Avez-vous une réplication de votre base de données ?

@+

[g_d_u_m]

J'ai fait le test en repartant de zéro, en utilisant uniquement Firebird (fichiers .conf d'origine) et Flamerobin (mais n'importe quel client peut faire l'affaire) et le phénomène se reproduit.
Voici les étapes pour le constater:

1) Créer une base C:\TEST_DB.fdb:


2) Créer une table Users:


3) Insérer une entrée:


4) afficher le moniteur de ressources sur l'onglet Disque, faire une lecture de la table Users:


5) attendre 60s que le moniteur de ressources n'ait plus le dernier accès en mémoire, puis refaire une lecture de la table Users:


On peut répéter l'étape 5 autant de fois que l'on veut, on constate bien qu'un simple SELECT provoque l'écriture d'une page de 4096 octets sur le disque.

[Artemus24]

Salut g_d_u_m.

Afin de vous rendre service, je vais tenter de faire le même test que vous.

1) voici mon fichier batch qui me permet de lancer un script FireBird.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@echo off
 
chcp 1252 > nul
 
SET FIC=%~nx0
SET FIC=%FIC:bat=sql%
 
IF EXIST ..\Data\Base.FDB  del /F ..\Data\Base.FDB
 
isql  -charset win1252  -echo  -input %FIC%  -quiet  -password 'masterkey'  -role RDB$ADMIN  -user 'sysdba'
 
@echo.
pause
exit

J'utilise une astuce, le nom de mon script possède le même nom que mon batch.

2) voici le script FireBird avec création d'une base, création d'une table, son remplissage et un vidage afin de voir si tout c'est passé correctement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET WIN1252;
 
create table test (
id  int      not null primary key,
lib char(20) not null
);
 
insert into test (id,lib) values ( 1, 'un');
insert into test (id,lib) values ( 2, 'deux');
insert into test (id,lib) values ( 3, 'trois');
insert into test (id,lib) values ( 4, 'quatre');
insert into test (id,lib) values ( 5, 'cinq');
insert into test (id,lib) values ( 6, 'six');
insert into test (id,lib) values ( 7, 'sept');
insert into test (id,lib) values ( 8, 'huit');
insert into test (id,lib) values ( 9, 'neuf');
insert into test (id,lib) values (10, 'dix');
insert into test (id,lib) values (11, 'onze');
insert into test (id,lib) values (12, 'douze');
insert into test (id,lib) values (13, 'treize');
insert into test (id,lib) values (14, 'quatorze');
insert into test (id,lib) values (15, 'quinze');
insert into test (id,lib) values (16, 'seize');
 
select * from test;
 
exit;

3) voici son execution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET WIN1252;
 
create table test (
id  int      not null primary key,
lib char(20) not null
);
 
insert into test (id,lib) values ( 1, 'un');
insert into test (id,lib) values ( 2, 'deux');
insert into test (id,lib) values ( 3, 'trois');
insert into test (id,lib) values ( 4, 'quatre');
insert into test (id,lib) values ( 5, 'cinq');
insert into test (id,lib) values ( 6, 'six');
insert into test (id,lib) values ( 7, 'sept');
insert into test (id,lib) values ( 8, 'huit');
insert into test (id,lib) values ( 9, 'neuf');
insert into test (id,lib) values (10, 'dix');
insert into test (id,lib) values (11, 'onze');
insert into test (id,lib) values (12, 'douze');
insert into test (id,lib) values (13, 'treize');
insert into test (id,lib) values (14, 'quatorze');
insert into test (id,lib) values (15, 'quinze');
insert into test (id,lib) values (16, 'seize');
 
select * from test;
 
          ID LIB
============ ====================
           1 un
           2 deux
           3 trois
           4 quatre
           5 cinq
           6 six
           7 sept
           8 huit
           9 neuf
          10 dix
          11 onze
          12 douze
          13 treize
          14 quatorze
          15 quinze
          16 seize
 
 
exit;
 
Appuyez sur une touche pour continuer...

Jusque là, tout va bien !

4) pour le test, voici le fichier batch de nom test :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
@echo off
 
chcp 65001 > nul
 
SET FIC=%~nx0
SET FIC=%FIC:bat=sql%
 
isql  -charset win1252  -echo  -input %FIC%  -quiet  -password 'masterkey'  -role RDB$ADMIN  -user 'sysdba' '..\Data\Base.fdb'
 
@echo.
pause
exit

5) et voici le script de test :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
select * from test;
 
exit;

6) et son execution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
select * from test;
 
          ID LIB
============ ====================
           1 un
           2 deux
           3 trois
           4 quatre
           5 cinq
           6 six
           7 sept
           8 huit
           9 neuf
          10 dix
          11 onze
          12 douze
          13 treize
          14 quatorze
          15 quinze
          16 seize
 
 
exit;
 
Appuyez sur une touche pour continuer...

Rien de particulier.

7) comme vous, je me mets sous Windows 10 pro, dans le gestionnaire des tâches, puis dans le moniteur des ressources.
Et là, problème ! Je ne suis pas arrivé à calmer mon ordinateur. A l'inverse de vous, j'ai beaucoup d'utilitaires qui tournent en permanence.
J'ai fréquemment des pics d'activités, même sans toucher mon clavier, et je n'ai pas pu isoler une tranche de temps vide afin de faire le test.

J'ai un portable et j'ai un seul disque physique comme vous. Mon FireBird qui est stocké sur le disque F: est une partition logique.
Je ne peux pas scinder les ressources de mon disque logique système ( C: ) d'avec mon disque logique où se trouve FireBird ( F: ).
Faire un test dans ces conditions ne serait pas très significatif, car vous ne savez pas qui consomme les ressources sur ce disque.

Je constate que vous cliquez sur un utilitaire faisant office d’éditeur de texte.
C'est peut être cela votre écriture que vous recherchez tant.

Je n'ai pas pu voir le batch s'exécuter dans le moniteur des ressources, car comme je le suppose, le temps d’exécution est trop court.
Désolé de ne pouvoir en faire plus.

@+

[g_d_u_m]

Bonjour et merci de vous intéresser à mon problème.

Dans le moniteur de ressources, on peut voir quel processus fait des accès disques, je me suis concentré sur la ligne fbserver.exe


L'éditeur de texte que vous mentionnez fait partie de mon client BD Flamerobin. On pourrait le voir apparaître dans le moniteur de ressources sous une ligne flamerobin.exe mais apparemment il ne fait aucun accès disque.

Le moniteur de ressources ne laisse rien passer: le moindre accès, aussi fugitif soit-il, est conservé et affiché pendant 60s. Vous devriez donc pouvoir voir le processus fbserver.exe apparaître avec 4096 octets d'écriture, puis continuer à observer ce processus avec le nombre d'octets/secondes qui diminue progressivement jusque 0 après 60s (le chiffre affiché semble être lissé sur 60s).

[Artemus24]

Salut g_d_u_m.

Chez moi, il s'agit de "firebird.exe" & "fbguard.exec" pour les services et "isql.exe" pour le batch.
J'ai eu du mal à capturer le processus et j'ai compris pourquoi je ne le voyais pas à chaque lancement de mon batch (celui avec le select).
La première fois, il fait des accès aux disques et donc il apparaît dans les processus avec activité de disque.
Mais les fois suivants, il passe par les buffers (le cache) et donc aucun accès au disque.

Voici le résultat :



Il y a aussi des écritures, mais je ne sais pas comment les expliquer car le batch ne fait qu'un simple select.

Il y a des choses bizarres que je ne comprends pas trop.
1) Le nom de mon batch (le select) se nomme "E:\23.FireBird\99.Exercices\Ex_01\test.bat".
Or ce que je voie apparaître, c'est le nom de la base de données : "E:\23.FireBird\99.Exercices\Data\Base.FDB".

2) comme j'ai dû lancer la création de la base avant de lancer le select, il est fort probable que c'est la création que l'on voit et non le select seul.
Le batch de création de la base se nomme : "E:\23.FireBird\99.Exercices\Ex_01\base.bat".

3) comme je l'ai dit au début, quand il y a un accès au disque, le processus apparait.
J'avais beau lancer plusieurs fois de suite le batch "test", aucun processus n'apparaissait dans le moniteur des ressources (partie disque).

En conclusion, je ne sais pas interpréter correctement les résultats et je ne sais pas ce que signifie avec exactitude les écritures.
Je soupçonne que le résultat qui est affiché est celui de la création de la base et non celui du select seul.

@+

[g_d_u_m]

D'après ce que je comprends de vos tests, il me semble que isql.exe attaque directement le fichier de base de données BASE.FDB.
Effectivement, une lecture (SELECT) ne provoque aucune écriture sur le disque dans votre cas.

Dans mon cas, j'utilise la DLL fbclient.dll depuis mon Service Qt pour attaquer le Service Firebird fbserver.exe. C'est ce service qui est mandaté pour attaquer le fichier de base de données TEST_DB.FDB.
Apparemment c'est lui qui effectue une écriture dans la base de données lors d'un SELECT (et se traduit donc par un accès disque en écriture sur TEST_DB.FDB).

Je viens de faire le test avec un autre client de base de données: FSQL.exe
Voici l'exécution du SELECT et l'accès en écriture de 4096 octets induit:


C'est donc bien fbserver.exe le fautif. Comment lui expliquer qu'une lecture ne doit pas provoquer d'écriture?

[Artemus24]

Salut g_d_u_m.

J'ai complété mon dernier message avec un commentaire. Je ne sais pas si vous l'avez lu.

Je ne suis pas suffisamment expert en FireBird pour vous aider plus dans la démarche de votre problème.

je rencontre des problèmes de performances avec Firebird quant à l'utilisation du disque et je n'arrive pas à trouver d'où cela vient.

Hormis le détail que vous nous avez donné dans les messages précédents, en quoi vos problèmes de performances sont pénalisantes ?
Est-ce juste à cause du moniteur de ressources ou est-ce plus grave comme problème ?

@+

[g_d_u_m]

Les écritures synchrones constantes plombent les performances globales du système: le disque est utilisé à 100% alors que je ne fais pratiquement que des SELECTs.
Passer les bases en écritures asynchrones soulagent le système mais cette solution n'est pas envisageable pour moi (le système n'est pas sur onduleur).

J'ai fait quelques tests avec isql.exe (sans passer par un fichier batch, mais en lançant isql.exe dans une console et en tapant directement les commandes). Chez moi il mandate tout de même fbserver.exe pour accéder à la base, c'est assez curieux.

[SQLpro]

D'après ce que je comprends de vos tests, il me semble que isql.exe attaque directement le fichier de base de données BASE.FDB.

Non, jamais. Tout passe par le service FB.

C'est donc bien fbserver.exe le fautif. Comment lui expliquer qu'une lecture ne doit pas provoquer d'écriture?

Il est probable que chaque commande SQL soit enregistrées pour historisation, avec des métadonnées complémentaires.

A +

[g_d_u_m]

Il est probable que chaque commande SQL soit enregistrées pour historisation, avec des métadonnées complémentaires.

Cela veut dire qu'il n'y a pas de solution?
On ne peut donc pas installer une BD Firebird sur un disque dur système sans plomber les performances globales?

Comment faites-vous pour utiliser une BD Firebird hautement sollicitée, vous l'installez sur un stockage raid 0 ou 5 dédié pour réduire les temps d'accès? Sur un SSD?

[ddaime]

Bonjour.

J'ai fais quelques test hier soir sur deux postes différents (un vieux portable sous XP avec FB 2.5.1 (32b) et un portable récent avec Win 10 Pro 64bits et FB 3.0 en 64 bits. Je n'ai aucune saturation du système sur XP en revanche je constate effectivement des accès disque lors d'un simple SELECT sur une table. En cherchant vite fait sur le net j'ai trouvé cet article http://www.josh-hartmann.com/firebir...ance-tweaking/. L'avez-vous lu ?

Je ferais un test ce soir en désactivant les services Prefetch et Superfetch de Win 10, j'ai déjà eu des soucis de performances sur Vista.

[SergioMaster]

Bonjour,

l'article cité par ddaime m'a rappelé que cela fait des années que j'ai désactivé le sweep automatique sur mes bases (dernier "tweak" de l'article)
un backup via gbak étant fait régulièrement tout les soirs, le sweep se fait par ce dernier.

[Artemus24]

Salut à tous.

Le problème est-il résolu ? Et si oui, qu'avez-vous fait ?

@+

[Barbibulle]

Bonjour,

Je n 'ai pas tout entièrement lu, mais j'ai quelques propositions, suppositions à vous faire.

Le simple 'select' sous firebird se fait dans une transaction donc une transaction est créé avec un ID et ses caractéristiques, il se pourrait bien que ce soit ça qui provoque l'écriture dans le fichier.

Concernant vos tests si j'ai bien compris sur un disque "interne" vous avez le problème avec un disque USB ça fonctionne normalement.
Firebird je fais pas de différence entre un disque interne et USB (je veux dire que son code ne teste pas ce genre de chose) ma conclusion est que votre windows ou un programme tiers perturbe firebird peut être en essayant d'accéder à vos bases en même temps de firebird.

Il y a pas mal de temps je me souviens (plus ou moins) que windows avais un service (de sauvegarde automatique il me semble) qui malheureusement prenait les fichiers .GDB (ou .FDB je ne sais plus) comme étant les siens et les lisait à chaque modification pour en faire une sauvegarde. Du coup les performances et les accès disque saturaient facilement...

Votre problème y ressemble étrangement...

Essayez d'utiliser une base qui se termine par une autre extension ou voir s'il n'y a pas un autre process qui accède à votre base ou un service de sauvegarde en continue ou un antivirus trop entreprenant...

Bon courage