Alfresco Community : diagnostiquer les transactions bloquées et verrous PostgreSQL avant l’incident

Une lenteur Alfresco liée à PostgreSQL se diagnostique d’abord en identifiant les transactions longues, les sessions en attente et les verrous qui les relient. Avant tout redémarrage ou réindexation, cette lecture permet de distinguer la cause applicative du simple symptôme d’infrastructure.

Le problème est d’autant plus trompeur qu’une GED peut continuer a repondre tout en se degradant en arrière-plan. Quelques creations documentaires restent rapides, puis un import se bloque, un workflow met plus de temps a terminer, les recherches deviennent incoherentes et les utilisateurs parlent d’un système « aleatoire ». En pratique, ce comportement est souvent lie a une attente SQL, a un lot qui s’empile, ou a une personnalisation repository qui garde une transaction ouverte trop longtemps.

Si vous surveillez déjà VACUUM, ANALYZE et le bloat PostgreSQL sur Alfresco Community, si vous avez cadré vos jobs planifies et cron Alfresco, ou si vous sortez d’une reprise d’instance avec audit des extensions et de l’indexation, il manque encore une lecture decisive : comprendre quelles transactions se disputent la base et pourquoi.

1. Pourquoi les verrous PostgreSQL comptent autant dans Alfresco

Alfresco Community repose sur une mecanique transactionnelle forte. Création de document, mise a jour de métadonnées, lancement de règles, exécution de behaviours, progression de workflow, indexation asynchrone ou scripts métier: tout cela finit par produire des ecritures ou des lectures qui doivent cohabiter proprement dans la base. Quand cette cohabitation se deraille, l’effet visible n’est pas toujours un crash. C’est souvent une lenteur progressive, des files d’attente et des opérations qui se mettent a attendre silencieusement.

Un verrou n’est pas un bug en soi. PostgreSQL verrouille pour garantir la cohérence. Le vrai sujet est la durée, la frequence et l’empilement. Une transaction courte qui pose un verrou puis le libere est normale. Une transaction qui reste ouverte pendant un import massif, un script repository mal cadré ou un traitement métier en boucle finit en revanche par bloquer d’autres opérations, puis par transformer un sujet local en incident d’exploitation.

2. Les symptomes qui doivent orienter vers un diagnostic transactionnel

Plusieurs signaux doivent faire penser a des transactions bloquées plutot qu’a un simple manque de ressources:

• les creations ou mises a jour de documents deviennent lentes sans saturation CPU evidente;
• certaines actions passent, d’autres restent pendantes sans message clair cote utilisateur;
• des imports ou des traitements planifies prennent soudain beaucoup plus de temps;
• les logs montrent des timeouts, des deadlocks ou des attentes repetitives sur le repository;
• la plateforme revient a la normale après redemarrage, puis se degrade a nouveau quelques heures plus tard.

Ce dernier point est très important. Quand un redemarrage « règle » temporairement le problème, il ne faut pas conclure trop vite a un incident memoire ou JVM. Le redemarrage coupe surtout les transactions ouvertes et vide des files temporaires. Si la cause reste active, le même schema revient.

3. Ce qu’il faut regarder d’abord cote PostgreSQL

Le premier réflexe utile consiste a objectiver la situation sur la base avant toute correction hasardeuse. L’objectif n’est pas seulement de lister les sessions actives, mais de distinguer:

• les transactions longues encore ouvertes;
• les sessions en attente d’un verrou;
• les sessions qui bloquent d’autres sessions;
• les requetes récurrentes associees a un traitement applicatif connu;
• les heures et frequences de recurrence.

Cette lecture est plus utile qu’un simple « la base répond ». Une base peut être accessible et pourtant laisser plusieurs sessions en attente mutuelle. Il faut donc corriger la lecture d’exploitation: la sante d’Alfresco n’est pas seulement la disponibilite de PostgreSQL, mais la capacite de la plateforme a faire progresser ses transactions sans congestion durable.

4. Les causes fréquentes cote Alfresco Community

Dans les environnements Alfresco Community, les blocages transactionnels reviennent souvent autour de quelques familles bien connues. D’abord, les personnalisations repository: behaviours trop bavards, web scripts métier qui enchainent trop d’ecritures, ou scripts d’administration qui balayent trop largement le depot. Ensuite, les jobs planifies qui travaillent sur de gros volumes sans fenetrage ni priorisation. Enfin, les opérations correctives lancees dans l’urgence, comme une reprise de masse, un recalcul métadonnées ou une relance de traitement sans analyse prealable.

Il faut aussi surveiller les cas mixtes: une extension tient une transaction ouverte pendant qu’un job planifie passe sur les mêmes objets, puis l’indexation ou un workflow attend a son tour. Pris separement, chaque composant semble defensable. Ensemble, ils fabriquent une attente en chaine que personne ne voit tant que la base n’est pas lue avec precision.

5. Pourquoi la simple suppression d’une session est rarement une solution

Quand la pression monte, la tentation est forte de tuer la session qui bloque. Parfois c’est nécessaire pour restaurer le service. Mais si cette action devient le seul réflexe, on déplace le problème sans le traiter. La vraie question reste: quel flux fonctionnel ouvre cette transaction, sur quel volume, avec quelle logique métier, et pourquoi tient-elle si longtemps?

Une session tueur peut soulager l’instant. Elle ne dit rien sur le script, le behaviour, le lot ou l’integration qui recreera le même conflit a la prochaine exécution. C’est pour cela qu’un diagnostic solide doit toujours raccorder les sessions PostgreSQL a une action applicative Alfresco compréhensible par l’exploitation.

6. Une méthode simple pour remonter de la base vers la cause

La méthode la plus fiable consiste a suivre cinq étapes courtes:

1. identifier les sessions qui attendent et celles qui bloquent;
2. relever l’anciennete des transactions ouvertes et les requetes impliquees;
3. croiser l’heure du blocage avec les logs Alfresco et les jobs planifies;
4. associer la requete SQL a un traitement fonctionnel reel: import, workflow, behaviour, script, integration;
5. decider ensuite si l’action immédiate est une suspension de lot, une correction applicative, un decoupage de traitement ou une reprise contrôlée.

Cette approche evite deux erreurs symetriques: tuer des sessions au hasard, ou partir tout de suite sur une optimisation PostgreSQL generale alors que le problème est applicatif. Sur Alfresco Community, la base raconte rarement toute l’histoire seule. Mais elle donne très vite le point d’entree fiable pour lire la chaine de cause.

7. Ce qu’il faut corriger avant que l’incident ne revienne

Une fois la cause remontee, la correction depend du contexte. Il peut s’agir de réduire le périmètre d’un traitement massif, de fenetrer un job, de revoir l’ordre des ecritures dans une personnalisation, d’ajouter des pauses de reprise, ou simplement de ne plus lancer plusieurs flux concurrents sur le même corpus documentaire. Dans d’autres cas, il faut revoir la gouvernance d’exploitation: qui lance quoi, a quelle heure, avec quel volume maximum et quel filet de sécurité.

Le point cle est d’éviter la correction purement reactiva. Si une transaction longue a déjà provoque une congestion visible, l’environnement a besoin d’une règle d’exploitation nouvelle, pas seulement d’un degagement ponctuel. Autrement, la prochaine reprise d’import, la prochaine synchronisation ou le prochain script d’administration reproduira le blocage.

8. Comment Rainbow Integration cadré ce type d’audit

Sur ce type de sujet, notre travail ne consiste pas a produire un relevé SQL de plus. Nous cherchons surtout a rattacher les verrous a des usages Alfresco concrets: quelles extensions manipulent le repository, quels lots passent sur quels objets, quels workflows entretiennent l’attente et quel ordre de reprise permet de remettre le service sans rechute immédiate. C’est ce lien entre lecture PostgreSQL et lecture métier qui rend un diagnostic exploitable.

9. Ce qu’il faut retenir

Les transactions bloquées et verrous PostgreSQL ne sont pas un detail bas niveau réservé aux DBA. Dans Alfresco Community, ils sont souvent le point de passage concret entre une plateforme qui tient et une plateforme qui s’enlise. Plus vous les lisez tot, plus vous avez de chances de corriger la vraie cause avant l’incident visible.

Autrement dit, ne vous contentez pas de regarder si la base répond. Regardez combien de temps les transactions vivent, qui attend qui, quel traitement applicatif alimente l’attente et quelle règle d’exploitation doit changer. C’est ce cadrage qui transforme une lenteur récurrente en diagnostic utile, puis en remise sous contrôle durable.

Votre instance Alfresco présente ces symptômes ?

Décrivez les lenteurs, verrous ou traitements concernés pour cibler les contrôles prioritaires.

Demander un audit Alfresco