Produits Entr'ouvert » w.c.s.

J'ai observé ce comportement sur plusieurs tenants, avec plusieurs workflows.

Ça reste utile de les pointer, qu'au-delà du code dans w.c.s. on puisse les identifier et regarder ce qu'il y a moyen de construire différemment.

Frédéric Péters (de retour le 30/1) a écrit :

J'ai observé ce comportement sur plusieurs tenants, avec plusieurs workflows.

Ça reste utile de les pointer, qu'au-delà du code dans w.c.s. on puisse les identifier et regarder ce qu'il y a moyen de construire différemment.

Ce que j'ai toujours fait, le dernier a été pointé à Stéphane dans le passé, cf. https://dev.entrouvert.org/issues/100674

Frédéric Péters (de retour le 30/1) a écrit :

rien que sur l'isere, en production, on a plus de 100GB de requêtes SQL de plus de 100ms

Quel outil pour mesurer ça ?

pducroquet@db2.prod:~ (PROD) $ sudo zstdcat /var/log/postgresql/postgresql-13-publik.log-20250127.zst | ~/log-stats.py

Et dans la sortie (un dictionnaire que je colle dans un shell python), le top 1 est l'isère avec donc 110GB de logs hier

>>> bad_boys['wcs_demarches_isereconnect_fr']
{'lines': 74250, 'bytes': 103403068844}

Et j'ai le script log-extract.py pour pouvoir lire les requêtes en question

Ce que j'ai toujours fait, le dernier a été pointé à Stéphane dans le passé,

Je l'ai lié au ticket; si tu as les références à d'autres, c'est cool de les lier aussi, ça permet ensuite de valider les changements sur des vraies situations.

Aussi, sur la forme technique en elle-même, pourquoi pas la suggstion de tables ..._evolution_parts à côté, (id, evolution_id, part_type, part_content) ? Et en y appliquant le stockage "TOAST donc compressée" cité dans #101025 mais que je n'ai pas compris ?

Je pense que ce champ parts est responsable de la quasi saturation de la bande passante par les crons wcs en production.

Pour traduire en bon français le but de Pierre ici est d'arrivé à écrêter les pics sur ce graphe: https://grafana.entrouvert.org/d/qtBfPyamk/node-exporter-full?orgId=1&from=now-7d&to=now&timezone=browser&var-job=nodexporter&var-node=db2.prod.saas.entrouvert.org&var-port=9100&viewPanel=panel-74

Coté écriture¶

Je ne vois vraiment de souci de bande-passante et les pics sont moins marqués, on a un traffic de fond à 15Mib/s et des pics max à 64Mib/s, disons un rapport de 1 à 4 mais bon ça reste bas.

$ git grep _store_all_evolution\ =\ True wcs
wcs/admin/workflows.py:                        item._store_all_evolution = True
wcs/clamd.py:        formdata._store_all_evolution = True
wcs/formdata.py:                                    self._store_all_evolution = True
wcs/formdata.py:                                    self._store_all_evolution = True
wcs/formdata.py:                            self._store_all_evolution = True
wcs/formdata.py:                            self._store_all_evolution = True
wcs/formdata.py:        self._store_all_evolution = True
wcs/sql.py:                # to store them all using formdata._store_all_evolution = True
wcs/sql.py:                    formdata._store_all_evolution = True
wcs/wf/wscall.py:                    formdata._store_all_evolution = True

• les actions d'appel de web-service (à mon avis 99% du souci)
• le scan clamd (peut-être...)
• l'anonymisation (pas fréquent, bas)
• le remapping de workflow (c'est pas si fréquent, priorité très très basse)

On pourrait tenter d'un booléen _dirty = False au chargement des evolutions et des parts (avec _dirty = True au niveau classe) et introduire une nouvelle colonne new_parts bytea[] pour éviter une migration (on lit parts + new_parts, à l'écriture on vide parts et on écrit plus que dans new_parts) et remplacer _store_all_evolutions par cette gestion plus fine.

Coté lecture¶

Là traffic de fond autour de 60Mib/s et pics jusqu'à 384Mib/s on est plus sur un rapport 1 à 6.

On pourrait charger les "parts" de manière paresseuse en fonction de leur type comme on charge les évolutions de manière paresseuse et/ou par batch dans certains chemins du code.

Mais j'ai quand même un doute personnellement parce que c'est pas juste une question de connaître la classe de chaque part, notamment pour le cron de saut cité ici parce qu'un saut ça implique des actions, avec des conditions et des gabarits en pagaille et le calcul de ces gabarits nécessitent des variables de substitution qui sont difficiles à calculer sans lire toutes les "parts" (sauf à exécuter/analyser l'expression en avance, et en déduire les parts nécessaires, compliqué).

Pour moi il y a à réfléchir d'avantage sur la représentation qui permettrait d'en lire le moins possible; c'est pas du tout évident que les pics rouges dans le graphe plus haut ce soit juste "la lecture de parts inutiles pour le processus en cours" par exemple pour ne charger que les WorkflowWsCallEvolutionPart nécessaire via les variables lazy, il faut déterminer son varname, il faudrait donc stocker varname en dehors du part de la même manière que la classe (ou stocker le lien part -> item du workflow, problématique si l'item change). Pour chaque part il faudrait séparer un ensemble de donnée à garder dans une/des colonnes de petite taille et une autre pour le vrac.

Et attention aussi parce que charger de manière paresseuse ça réduit la bande passante en lecture mais ça va augmenter la latence.

Sachant qu'une autre méthode immédiate ce serait d'aplatir lez pics pour répartir la charge, la nuit c'est bijoe qui charge un max (déprécier bijoe) le jour c'est toutes les heures à x:15, je ne sais pas pourquoi mais déterminer le coupable me semble utile.

Benjamin Dauvergne a écrit :

Sachant qu'une autre méthode immédiate ce serait d'aplatir lez pics pour répartir la charge, la nuit c'est bijoe qui charge un max (déprécier bijoe) le jour c'est toutes les heures à x:15, je ne sais pas pourquoi mais déterminer le coupable me semble utile.

C'est vrai que j'affirme toujours sans vérifier histoire de faire perdre du temps aux autres.
Au hasard des stats de pgbouncer, utilisé par wcs seul:

2025-01-28 15:17:16.719 CET [3735724] LOG stats: 4598 xacts/s, 6705 queries/s, in 21774324 B/s, out 313883698 B/s, xact 2595 us, query 1554 us, wait 34965 us

Pierre Ducroquet a écrit :

C'est vrai que j'affirme toujours sans vérifier histoire de faire perdre du temps aux autres.
Au hasard des stats de pgbouncer, utilisé par wcs seul:
[...]
Voilà, la bande passante est consommée par wcs.

Je ne sais pas à qui tu parles puisque je vais dans ton sens...

Aussi à regarder le trafic sur 6 mois on voit¹ bien une légère inflexion au niveau du 9 janvier de disons 25Mib/s en plus en moyenne du au chargement des objets de configuration depuis la base plutôt que le NFS. C'était à prévoir, c'est pas forcément un souci. On voit une baisse de 10Mib/s coté filer au même moment² c'est pas équivalent parce qu'au niveau NFS on avait un poil de cache via les délégations.

Ça ne remet pas en cause qu'il y ait beaucoup de trafic mais ça explique l'augmentation récente.

¹ https://grafana.entrouvert.org/explore?schemaVersion=1&panes=%7B%22xcq%22%3A%7B%22datasource%22%3A%22000000003%22%2C%22queries%22%3A%5B%7B%22expr%22%3A%22rate%28node_network_receive_bytes_total%7Binstance%3D%7E%5C%22db2.prod.saas.entrouvert.org%3A9100%5C%22%2Cjob%3D%7E%5C%22nodexporter%5C%22%7D%5B480m%5D%29%22%2C%22format%22%3A%22time_series%22%2C%22intervalFactor%22%3A2%2C%22legendFormat%22%3A%22recv+%7B%7Bdevice%7D%7D%22%2C%22refId%22%3A%22A%22%2C%22step%22%3A240%2C%22datasource%22%3A%7B%22type%22%3A%22prometheus%22%2C%22uid%22%3A%22000000003%22%7D%2C%22editorMode%22%3A%22code%22%2C%22range%22%3Atrue%2C%22adhocFilters%22%3A%5B%5D%2C%22interval%22%3A%22%22%7D%2C%7B%22expr%22%3A%22rate%28node_network_transmit_bytes_total%7Binstance%3D%7E%5C%22db2.prod.saas.entrouvert.org%3A9100%5C%22%2Cjob%3D%7E%5C%22nodexporter%5C%22%7D%5B480m%5D%29%22%2C%22format%22%3A%22time_series%22%2C%22intervalFactor%22%3A2%2C%22legendFormat%22%3A%22trans+%7B%7Bdevice%7D%7D+%22%2C%22refId%22%3A%22B%22%2C%22step%22%3A240%2C%22datasource%22%3A%7B%22type%22%3A%22prometheus%22%2C%22uid%22%3A%22000000003%22%7D%2C%22editorMode%22%3A%22code%22%2C%22range%22%3Atrue%2C%22adhocFilters%22%3A%5B%5D%2C%22interval%22%3A%22%22%7D%5D%2C%22range%22%3A%7B%22from%22%3A%22now-6M%22%2C%22to%22%3A%22now%22%7D%7D%7D&orgId=1

² https://grafana.entrouvert.org/explore?schemaVersion=1&panes=%7B%22b1f%22:%7B%22datasource%22:%22000000003%22,%22queries%22:%5B%7B%22expr%22:%22rate%28node_network_receive_bytes_total%7Binstance%3D~%5C%22filer1.prod.saas.entrouvert.org:9100%5C%22,job%3D~%5C%22nodexporter%5C%22%7D%5B120m%5D%29%22,%22format%22:%22time_series%22,%22intervalFactor%22:2,%22legendFormat%22:%22recv%20%7B%7Bdevice%7D%7D%22,%22refId%22:%22A%22,%22step%22:240,%22datasource%22:%7B%22type%22:%22prometheus%22,%22uid%22:%22000000003%22%7D,%22adhocFilters%22:%5B%5D,%22interval%22:%22%22,%22editorMode%22:%22code%22,%22range%22:true,%22instant%22:true%7D,%7B%22expr%22:%22rate%28node_network_transmit_bytes_total%7Binstance%3D~%5C%22filer1.prod.saas.entrouvert.org:9100%5C%22,job%3D~%5C%22nodexporter%5C%22%7D%5B120m%5D%29%22,%22format%22:%22time_series%22,%22intervalFactor%22:2,%22legendFormat%22:%22trans%20%7B%7Bdevice%7D%7D%20%22,%22refId%22:%22B%22,%22step%22:240,%22datasource%22:%7B%22type%22:%22prometheus%22,%22uid%22:%22000000003%22%7D,%22adhocFilters%22:%5B%5D,%22interval%22:%22%22,%22editorMode%22:%22code%22,%22range%22:true,%22instant%22:true%7D%5D,%22range%22:%7B%22from%22:%221736177175740%22,%22to%22:%221736719973668%22%7D%7D%7D&orgId=1

Pas d'opinion sur ça, j'avais en tête de faire évoluer les tables existantes pour ne pas trop impacter le code de wcs, mais cela peut être une table à côté. Je pensais que l'ordre du tableau python sérialisé dans parts était important, ce n'est pas le cas ?

Si mais (id, evolution_id, part_type, part_content), les id étant croissant on a un ordre, ou je rate un truc ?

On a un ordre qu'on ne peut pas changer facilement a posteriori, alors que dans l'existant c'est possible (mais j'ignore si c'est utilisé dans le python)

Non l'ordre est fixe.