|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Requete CC HFSQL grosse lenteur |
| Débuté par Stephane G, 06 fév. 2026 11:03 - 2 réponses |
| |
| | | |
|
| |
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 |
| |
| |
| | | |
|
| | |
| |
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 |
| |
| |
| | | |
|
| | |
| |
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. |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|