Noalyss

Bonjour,
La migration de la version phpcompta 5.6 à la version noalyss 6916 s'est passé sans aucun problème. Je suis sous Debian 8 et postgresql 9.3.

toute fois, et contrairement à la 5.6, j'ai constaté qu'il y'a des problèmes de lenteur surtout lorsque je vais dans
Comptabilité----->Avancé----->Vérification qui prend plus de 10 minutes pour renvoyer un résultat et durant ces 10 minutes le serveur est à 99% d'utilisation CPU.

Ma table jrnx contient environ 70000 liges. La lenteur (les 10 mn pour renvoyer le resultat du select de ac=COMPTA/ADV/VERIFBIL) a été constaté au niveau de la requête qui suit:

select distinct source.f_id,source.j_qcode

from jrnx as source ,jrnx as target
where
source.j_id < target.j_id
and source.j_poste<>target.j_poste
and source.j_qcode = target.j_qcode
and source.j_tech_per in (select p_id from parm_periode where p_exercice='2016')
and target.j_tech_per in (select p_id from parm_periode where p_exercice='2016')
------------------------------------------------------------------------------------------------------------------------------------
Un "Explain Analyse" donne :
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
HashAggregate (cost=279549.86..279622.37 rows=7251 width=16) (actual time=655978.342..655978.342 rows=0 loops=1)
-> Nested Loop (cost=1.74..95227.39 rows=36864493 width=16) (actual time=655978.323..655978.323 rows=0 loops=1)
Join Filter: (parm_periode.p_id = source.j_tech_per)
-> Nested Loop (cost=1.33..20194.81 rows=72505 width=21) (actual time=0.064..2907.283 rows=942565 loops=1)
-> Seq Scan on parm_periode (cost=0.00..1.16 rows=13 width=4) (actual time=0.008..0.047 rows=13 loops=1)
Filter: (p_exercice = '2016'::text)
-> Materialize (cost=1.33..3492.84 rows=72505 width=17) (actual time=0.012..102.041 rows=72505 loops=13)
-> Hash Semi Join (cost=1.33..2705.32 rows=72505 width=17) (actual time=0.048..229.484 rows=72505 loops=1)
Hash Cond: (target.j_tech_per = parm_periode_1.p_id)
-> Seq Scan on jrnx target (cost=0.00..1707.05 rows=72505 width=21) (actual time=0.004..65.854 rows=72505 loops=1)
-> Hash (cost=1.16..1.16 rows=13 width=4) (actual time=0.030..0.030 rows=13 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 1kB
-> Seq Scan on parm_periode parm_periode_1 (cost=0.00..1.16 rows=13 width=4) (actual time=0.004..0.017 rows=13 loops=1)
Filter: (p_exercice = '2016'::text)
-> Index Scan using x_qcode on jrnx source (cost=0.42..0.96 rows=6 width=29) (actual time=0.691..0.691 rows=0 loops=942565)
Index Cond: (j_qcode = target.j_qcode)
Filter: ((j_id < target.j_id) AND ((j_poste)::text <> (target.j_poste)::text))
Rows Removed by Filter: 1790
Total runtime: 655978.892 ms
(19 rows)


--------------------------------------------------------------------------------------------------------------------------------------

Merci de votre aide

Bonjour,

VERIFBIL vérifie plus de choses , la requête SQL peut être améliorée , il faudrait tester en changeant

and source.j_tech_per in (select p_id from parm_periode where p_exercice='2016')
and target.j_tech_per in (select p_id from parm_periode where p_exercice='2016')

par

and exists (select p_id from parm_periode as p1 where p_exercice='2016' and p1.p_id=source.j_tech_per )
and exists(select p_id from parm_periode as p2 where p_exercice='2016' and p2.p_id=target.j_tech_per)

Normalement cela ira plus vite , j'aimerais en avoir le résultat svp

essayer aussi un vacuumdb -a pour rafraîchir les stats , 655 secondes pour cette requête me semble beaucoup , les shared_buffers ont été augmentés ?

autre idée , ajoutez un index sur target.j_qcode et ajoutez la clause coalesce (target.j_qcode,'') <> ''

changer
par
Améliore nettement la performance

merci Dany de votre aide,
au fait seul le scénario de l'ajout de l'index sur target.j_qcode que je n'ai pas testé puisque je ne sais pas encore comment faire.
Pour les autres solutions que vous m'avez proposé, je les ai testé toutes mais je n'ai constaté aucune amélioration, la situation est toujours la même.

Ce que j'ai encore remarqué c'est que lorsque je fais un "select * from jrnx" ou un "select * from jrn" la réponse de postgresql est impeccable (moins de 16 secondes) même si la table jrnx fait un peu plus de 72 000 lignes. mais au niveau de noalyss, je constate de très fortes lenteurs non pas seulement dans "Comptabilité--->Avancé---->Vérification" mais également dans "Historique", "Historique Vente", "Historique Financier" et peut être bien d'autre endroits (environ 10 minutes pour obtenir une réponse et pendant lesquelles la charge CPU est à 99% ) .

Pour éliminer certains doutes sur ma plateforme, je vais restaurer mon dossier dans un noalyss sur machine windows et je vous tiendrais au courant.
Sinon toute aide concernant l'ajout de l'index serais la bienvenue.

Cordialement.

Pour les historiques , il faut aller dans préférences et limiter la taille d'écran à moins de 50 lignes. Pour l'autre soucis , j'ai remarqué avec 122000 opérations qu'on passe de 10 secondes à 2 sec. en fait le changement de SQL (utilisation de f_id au lieu de j_qcode).

L'index dont je parlais existe.

Avec un tel volume de données , il faut tuner postgresql ainsi que le server .

Bonsoir,

J'ai regardé les performances , avec 122.000 lignes j'arrivais à 1min , j'ai réussi à descendre jusque 2sec , càd 30 fois plus vite.

Cela dit , quel processeur avez-vous ? Parce que 10 minutes , c'est vraiment beaucoup.
Pourriez-vous indiquer d'autres endroits où c'est lent ?

Merci

.D