Vous n'êtes pas identifié(e).
Bonjour à tous,
On utilise PG 14 sur debian.
Dans la base existe une table de 34GB avec 4 653 064 nb de lignes.
Avant lorsqu'on lançait un ANALYZE sur cette table, l'opération aboutie; mais maintenant lorsqu'on lance l'ANALYZE çà renvoie après un certain temps d'execution :
ERROR: out of memory
DETAIL: Failed on request of size 27336 in memory context "BuildRelationExtStatistics".
Je tiens à remarquer que le nombre de lignes de cette table depuis le dernier ANALYZE successful n'a pas beaucoup grandit. Et un repack est planifié chaque week-end pour éviter la fragmentation de la table et de l'index.
L'erreur se produit aussi meme si il y a presque seul ANALYZE, la requête qui se lance dans le sgbd.
=> Pouvez vous indiquer svp, ce qui peut donc être la cause de cette erreur et si existe une autre solution que d'augmenter la RAM ?
Merci d'avance
Hors ligne
Quand ce type d'erreur arrive, il y a normalement du détail dans les logs qui indique combien de mémoire est allouée et comment elle est répartie. Il faudrait voir ce détail et savoir de combien de mémoire libre le serveur dispose quand l'ANALYZE est lancé.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Merci,
Le log PG montre :
LOG: could not fork new process for connection: Cannot allocate memory (défois il n' y a pas cette trace)
ERROR: out of memory
DETAIL: Failed on request of size 118275 in memory context "BuildRelationExtStatistics".
STATEMENT: VACUUM ANALYZE
le journalctl ne montre rien
Ce qui m'étonne aussi c'est que lorsqu'il fait un ANALYZE d'une autre table plus grande , qui elle fait 48GB avec 50 694 444 nb de lignes, çà passe.
Hors ligne
bonjour,
Vous faites un vacuum analyze ou un analyze simple ?
Les traces montrent que vous passer par vacuum.
Avec une commande SQL ou via le binaire vacuumdb ?
Dans les 2 cas vous pouvez bénéficier de l'option FREEZE.
Vous pouvez aussi regarder "free -m" au niveau du serveur pour voir ce qu'il en est quand ça passe et quand ça ne passe pas.
Cordialement,
Sébastien.
Hors ligne
BuildRelationExtStatistics me fait penser aux statistiques étendues. Auriez-vous créer des objets statistiques pour cette table (avec CREATE STATISTICS) ? Vous pouvez le voir en faisant un "\dX" dans psql ou avec la requête suivante :
SELECT
es.stxnamespace::pg_catalog.regnamespace::pg_catalog.text AS "Schema",
es.stxname AS "Name",
pg_catalog.format('%s FROM %s',
pg_catalog.pg_get_statisticsobjdef_columns(es.oid),
es.stxrelid::pg_catalog.regclass) AS "Definition",
CASE WHEN 'd' = any(es.stxkind) THEN 'defined'
END AS "Ndistinct",
CASE WHEN 'f' = any(es.stxkind) THEN 'defined'
END AS "Dependencies",
CASE WHEN 'm' = any(es.stxkind) THEN 'defined'
END AS "MCV"
FROM pg_catalog.pg_statistic_ext es
WHERE pg_catalog.pg_statistics_obj_is_visible(es.oid)
ORDER BY 1, 2;Guillaume.
Hors ligne
Merci de vos réponses,
Sébastien, oui que se soit un simple ANALYZE ou un VACUUM ANALYZE çà a renvoyé le out of memory.
Guillaume, effectivement il y en a de stats MCV de créés, vous pensiez que çà serait dù à cela ? En tout cas j'en ai supprimé une récente et maintenant l'ANALYZE passe, seulement je ne comprends toujours pas pourquoi çà consommerait tant de mémoire et pourquoi sur cette table en particulière ?
Merci de l'attention que vous portiez à ce sujet.
Dernière modification par duple (29/04/2022 14:40:27)
Hors ligne
Si en supprimant cette statistique étendue, l'ANALYZE passe, c'est que ça devait être ça. Aucune idée de pourquoi cela prend tant de mémoire, surtout sans avoir aucune information sur la définition de la table et de la statistique étendue.
Guillaume.
Hors ligne
Ok, en tout cas l'erreur semble disparaitre avec cette action.
Merci de votre aide
Cordialement,
Hors ligne