PC SOFT

FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile

|
|
|
FR
Accueil → Etats & Requêtes → Requete CC HFSQL grosse lenteur
Requete CC HFSQL grosse lenteur
Débuté par Stephane G, 06 fév. 2026 11:03 - 5 réponses
#1
Membre enregistré
2 messages
Posté le 06 février 2026 - 11:03
Bonjour,
Nous utilisons une base de donnée hfsql sur linux et nous constations des lenteurs dans nos services pour comprendre ce qu il se passe j ai voulu faire des tests de suppression de ligne sur une table et je trouve des temps de traitement x20 sur des requetes quasi identique en terme de ligne a traiter, cela marche bien un certain temps puis ca s engorge et il faut ne rien faire pendant quelques minutes et mes requetes redescendent toutes seule en temps de traitement, si vous avez des idees je suis preneur
ex :

195 10:42:06 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041421000000' 1017 élément(s) supprimé(s). 1 m 5 s 700 ms
194 10:37:41 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041420000000' 828 élément(s) supprimé(s). 52 s 732 ms
193 10:36:15 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041419000000' 742 élément(s) supprimé(s). 37 s 370 ms
192 10:34:02 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041418000000' 742 élément(s) supprimé(s). 36 s 535 ms
191 10:32:42 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041417000000' 1044 élément(s) supprimé(s). 53 s 914 ms
190 10:31:52 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041416000000' 764 élément(s) supprimé(s). 38 s 396 ms
189 10:30:57 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041415000000' 747 élément(s) supprimé(s). 39 s 362 ms
188 10:29:53 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041414000000' 749 élément(s) supprimé(s). 37 s 480 ms
187 10:29:49 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041413000000' 707 élément(s) supprimé(s). 1 s 055 ms
186 10:29:46 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041412000000' 707 élément(s) supprimé(s). 1 s 154 ms
185 10:29:41 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041411000000' 1430 élément(s) supprimé(s). 2 s 703 ms
184 10:29:37 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041410000000' 1055 élément(s) supprimé(s). 1 s 799 ms
183 10:29:33 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041409000000' 778 élément(s) supprimé(s). 1 s 360 ms
182 10:29:29 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041408000000' 832 élément(s) supprimé(s). 1 s 504 ms
#2
Membre enregistré
3 messages
Posté le 23 février 2026 - 04:22
Ton comportement ressemble surtout à un problème d’I/O ou de maintenance interne de HFSQL https://space-waves.co
#3
Membre enregistré
1 message
Posté le 03 mars 2026 - 06:58
C'est un phénomène classique de saturation du cache d'écriture (I/O Wait) sous Linux.

Pourquoi ça s'engorge ?
Le "Mur" du Cache : Les premières requêtes (182-187) sont instantanées car Linux les écrit en RAM (Dirty Pages). Dès que le cache est plein, le système bloque tout pour forcer l'écriture physique sur le disque (188-195).

Fragmentation des Index : Chaque DELETE fragmente le fichier .ndx. HFSQL doit recalculer l'arbre d'index à chaque ligne supprimée, ce qui devient exponentiellement lourd.

Marquage Logique : HFSQL ne supprime pas physiquement les lignes, il les "marque". Le fichier reste gros et parsemé de trous, ralentissant les recherches suivantes https://www.servicefinance-company.com

Solutions rapides
Indexer la rubrique : Vérifiez absolument que DateHeureServ est une Clé dans l'analyse. Sans index, c'est un "Full Scan" disque à chaque requête.

Réindexer & Compacter : Lancez une maintenance (HRéindexe avec option de compactage) pour nettoyer les lignes supprimées et reconstruire les index proprement.

Augmenter les blocs : Au lieu de faire 20 requêtes de 800 lignes, faites-en une seule plus large, ou laissez 10 secondes de pause entre chaque pour laisser le disque "respirer".

Vérifier l'I/O : Tapez iostat -xz 1 sur Linux. Si %util est à 100%, votre disque est le goulot d'étranglement.
#4
Posté le 06 mars 2026 - 03:15
Stephane G escribío:
Bonjour,
Nous utilisons une base de donnée hfsql sur linux et nous constations des lenteurs dans nos services pour comprendre ce qu il se passe j ai voulu faire des tests de suppression de ligne sur une table et je trouve des temps de traitement x20 sur des requetes quasi identique en terme de ligne a traiter, cela marche bien un certain temps puis ca s engorge et il faut ne rien faire pendant quelques minutes et mes requetes redescendent toutes seule en temps de traitement, si vous avez des idees je suis preneur
ex :

195 10:42:06 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041421000000' 1017 élément(s) supprimé(s). 1 m 5 s 700 ms
194 10:37:41 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041420000000' 828 élément(s) supprimé(s). 52 s 732 ms
193 10:36:15 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041419000000' 742 élément(s) supprimé(s). 37 s 370 ms
192 10:34:02 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041418000000' 742 élément(s) supprimé(s). 36 s 535 ms
191 10:32:42 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041417000000' 1044 élément(s) supprimé(s). 53 s 914 ms
190 10:31:52 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041416000000' 764 élément(s) supprimé(s). 38 s 396 ms
189 10:30:57 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041415000000' 747 élément(s) supprimé(s). 39 s 362 ms
188 10:29:53 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041414000000' 749 élément(s) supprimé(s). 37 s 480 ms
187 10:29:49 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041413000000' 707 élément(s) supprimé(s). 1 s 055 ms
186 10:29:46 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041412000000' 707 élément(s) supprimé(s). 1 s 154 ms
185 10:29:41 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041411000000' 1430 élément(s) supprimé(s). 2 s 703 ms
184 10:29:37 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041410000000' 1055 élément(s) supprimé(s). 1 s 799 ms
183 10:29:33 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041409000000' 778 élément(s) supprimé(s). 1 s 360 ms
182 10:29:29 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041408000000' 832 élément(s) supprimé(s). 1 s 504 ms


Each time you place a block in https://blockblastonline.com , it affects subsequent turns.
#5
Posté le 27 avril 2026 - 05:20
Stephane G a écrit :
Bonjour,
Nous utilisons une base de donnée hfsql sur linux et nous constations des lenteurs dans nos services pour comprendre ce qu il se passe j ai voulu faire des tests de suppression de ligne sur une table et je trouve des temps de traitement x20 sur des requetes quasi identique en terme de ligne a traiter, cela marche bien un certain temps puis ca s engorge et il faut ne rien faire pendant quelques minutes et mes requetes redescendent toutes seule en temps de traitement, https://basketballstars-2.io si vous avez des idees je suis preneur
ex :

195 10:42:06 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041421000000' 1017 élément(s) supprimé(s). 1 m 5 s 700 ms
194 10:37:41 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041420000000' 828 élément(s) supprimé(s). 52 s 732 ms
193 10:36:15 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041419000000' 742 élément(s) supprimé(s). 37 s 370 ms
192 10:34:02 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041418000000' 742 élément(s) supprimé(s). 36 s 535 ms
191 10:32:42 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041417000000' 1044 élément(s) supprimé(s). 53 s 914 ms
190 10:31:52 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041416000000' 764 élément(s) supprimé(s). 38 s 396 ms
189 10:30:57 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041415000000' 747 élément(s) supprimé(s). 39 s 362 ms
188 10:29:53 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041414000000' 749 élément(s) supprimé(s). 37 s 480 ms
187 10:29:49 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041413000000' 707 élément(s) supprimé(s). 1 s 055 ms
186 10:29:46 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041412000000' 707 élément(s) supprimé(s). 1 s 154 ms
185 10:29:41 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041411000000' 1430 élément(s) supprimé(s). 2 s 703 ms
184 10:29:37 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041410000000' 1055 élément(s) supprimé(s). 1 s 799 ms
183 10:29:33 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041409000000' 778 élément(s) supprimé(s). 1 s 360 ms
182 10:29:29 delete FROM "01481\tevenements" WHERE "01481\tevenements".DateHeureServ < '2025041408000000' 832 élément(s) supprimé(s). 1 s 504 ms


Nous exploitons une base de données HFSQL sur Linux et avons remarqué des ralentissements dans nos services. Pour tenter d'expliquer la situation, j'ai effectué des tests de suppression de lignes sur une table, et j'ai constaté des temps de traitement multipliés par 20 sur certaines requêtes.
#6
Posté le 28 avril 2026 - 11:20
jim65richards escribío:
C'est un phénomène classique de saturation du cache d'écriture (I/O Wait) sous Linux.

Pourquoi ça s'engorge ?
Le "Mur" du Cache : Les premières requêtes (182-187) sont instantanées car Linux les écrit en RAM (Dirty Pages). Dès que le cache est plein, le système bloque tout pour forcer l'écriture physique sur le disque (188-195).

Fragmentation des Index : Chaque DELETE fragmente le fichier .ndx. HFSQL doit recalculer l'arbre d'index à chaque ligne supprimée, ce qui devient exponentiellement lourd.

Marquage Logique : HFSQL ne supprime pas physiquement les lignes, il les "marque". Le fichier reste gros et parsemé de trous, ralentissant les recherches suivantes https://www.servicefinance-company.com https://geometry-dashmeltdown.github.io

Solutions rapides
Indexer la rubrique : Vérifiez absolument que DateHeureServ est une Clé dans l'analyse. Sans index, c'est un "Full Scan" disque à chaque requête.

Réindexer & Compacter : Lancez une maintenance (HRéindexe avec option de compactage) pour nettoyer les lignes supprimées et reconstruire les index proprement.

Augmenter les blocs : Au lieu de faire 20 requêtes de 800 lignes, faites-en une seule plus large, ou laissez 10 secondes de pause entre chaque pour laisser le disque "respirer".

Vérifier l'I/O : Tapez iostat -xz 1 sur Linux. Si %util est à 100%, votre disque est le goulot d'étranglement.


Eso tiene bastante sentido, especialmente lo del límite del caché de escritura que termina bloqueando todo. No había pensado en cuánto pueden fragmentar los índices las operaciones repetidas de DELETE ni en cómo eso afecta el rendimiento con el tiempo. Voy a probar lo de reindexar y compactar, y también espaciar las consultas parece una solución práctica. Además, revisaré si ese campo está bien indexado, porque podría ser una parte importante del problema.
→ Revenir à Etats & Requêtes