Re: Dump qui plante (pg 8.3.4)

Oups, autant pour moi, erreur d'aiguillage, je reposte désormais sur la
liste.

Je résume :

il s'agit d'une db de plus de 7000 tables, et le dump plante en
fournissant le message suivant :

"mémoire partagée épuisée
vous pourriez avoir besoin d'augmenter max_locks_per_transaction"

Dont acte, je monte ce paramètre, mais :

au delà de 90, le server refuse de démarrer, et ce SANS fournir le
moindre message, ni en console, ni dans les logs ...
en deçà de 90, le dump plante

Petite constatation, sans doute sans pertinence, mais entre une valeur
de 64 et une valeur de 90, le dump plante toujours au même endroit,
voici le log :

2008-10-30 17:01:21 CET ATTENTION: mémoire partagée épuisée
2008-10-30 17:01:21 CET ERREUR: mémoire partagée épuisée
2008-10-30 17:01:21 CET ASTUCE : Vous pourriez avoir besoin d'augmenter
max_locks_per_transaction.
2008-10-30 17:01:21 CET INSTRUCTION : SELECT sequence_name, last_value,
increment_by, CASE WHEN increment_by > 0 AND max_value =
9223372036854775807 THEN NULL WHEN increment_by < 0 AND max_value =
-1 THEN NULL ELSE max_value END AS max_value, CASE WHEN
increment_by > 0 AND min_value = 1 THEN NULL WHEN increment_by < 0
AND min_value = -9223372036854775807 THEN NULL ELSE min_value END
AS min_value, cache_value, is_cycled, is_called from "EPHC_titre_id_seq"

En console, la dernière ligne avant le message est :
"Sauvegarde de la definition de la base de données."

Parfois la nuit porte conseille, mais aujourd'hui, je sèche tout autant
qu'hier :-(

Le jeudi 30 octobre 2008 à 23:36 +0100, Guillaume Lelarge a écrit :
> philippe dhondt a écrit :
> > En suivant ceci :
> >
> > http://docs.postgresqlfr.org/8.0/kernel-resources.html
> >
> > $ echo 134217728 >/proc/sys/kernel/shmall
> > $ echo 134217728 >/proc/sys/kernel/shmmax
> >
> > le serveur refuse maintenant de démarrer, même avec une valeur de 90 pour max_locks_per_transaction !!!
> >
>
> Pour pouvoir vous aider, il faut absolument avoir le message d'erreur.
>
> > Ceci dit, il se fait tard, et je suis là dessus depuis ce matin,
> > je reprends demain.
> >
> > Bonne soirée et merci à tous.
> >
>
> Tous ? je suis tout seul là. Vous n'envoyez pas vos mails à la liste
> actuellement, seulement à moi.
>
> Bonne soirée.
>
>

philippe dhondt a écrit :
> Oups, autant pour moi, erreur d'aiguillage, je reposte désormais sur la
> liste.
>
> Je résume :
>
> il s'agit d'une db de plus de 7000 tables, et le dump plante en
> fournissant le message suivant :
>
> "mémoire partagée épuisée
> vous pourriez avoir besoin d'augmenter max_locks_per_transaction"
>
> Dont acte, je monte ce paramètre, mais :
>
> au delà de 90, le server refuse de démarrer, et ce SANS fournir le
> moindre message, ni en console, ni dans les logs ...
> en deçà de 90, le dump plante
>
> Petite constatation, sans doute sans pertinence, mais entre une valeur
> de 64 et une valeur de 90, le dump plante toujours au même endroit,

Ça ne m'étonne pas trop. Les verrous sont posés avant de commencer le
dump des tables. J'ai fait un test hier soir en créant une base à 8000
tables. Je n'ai pas le message d'erreur que vous indiquez. Je viens
aussi de monter à 90 pour max_lock_per_transactions, aucun soucis.

Quelle version de PostgreSQL utilisez-vous ?
Pouvez-vous nous envoyer votre fichier de configuration complet ?
Quelle est la taille de la base ?
D'autres clients sont-ils connectés en même temps que vous ?

> voici le log :
>
> 2008-10-30 17:01:21 CET ATTENTION: mémoire partagée épuisée
> 2008-10-30 17:01:21 CET ERREUR: mémoire partagée épuisée
> 2008-10-30 17:01:21 CET ASTUCE : Vous pourriez avoir besoin d'augmenter
> max_locks_per_transaction.
> 2008-10-30 17:01:21 CET INSTRUCTION : SELECT sequence_name, last_value,
> increment_by, CASE WHEN increment_by > 0 AND max_value =
> 9223372036854775807 THEN NULL WHEN increment_by < 0 AND max_value =
> -1 THEN NULL ELSE max_value END AS max_value, CASE WHEN
> increment_by > 0 AND min_value = 1 THEN NULL WHEN increment_by < 0
> AND min_value = -9223372036854775807 THEN NULL ELSE min_value END
> AS min_value, cache_value, is_cycled, is_called from "EPHC_titre_id_seq"
>

Il pourrait être intéressant d'ajouter le PID du processus dans les
logs, pour savoir si le SELECT est en rapport avec pg_dump.

> En console, la dernière ligne avant le message est :
> "Sauvegarde de la definition de la base de données."
>

Vous devriez aussi activer la trace de toutes les instructions SQL,
pg_dump en balance un certain nombre. Il serait intéressant de voir où
il s'arrête.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

> au delà de 90, le server refuse de démarrer, et ce SANS fournir le
> moindre message, ni en console, ni dans les logs ...
> en deçà de 90, le dump plante

Si le serveur refuse de démarrer, c'est probablement qu'il n'est pas capable
de créer un segment de mémoire partagé suffisamment gros (c'est bien un
unix ?). La table de locks prend de la mémoire partagée...

Il faut augmenter le paramètre noyau shmmax, dans ce cas.

Il y a plus d'informations dans la log de démarrage de postgresql
habituellement.

sinon, si c'est linux, c'est kernel.shmmax qu'il faut augmenter ...

Par exemple (il faut être root):

# sysctl -q kernel.shmmax
kernel.shmmax = 33554432

Pour la doubler par exemple:
# sysctl kernel.shmmax=67108864

Attention, le paramètre est perdu au reboot.

Il faut donc le sauvegarder dans /etc/sysctl.conf.

En espérant que ça soit bien la cause ...

Guillaume Lelarge a écrit :
> [...]
> Ça ne m'étonne pas trop. Les verrous sont posés avant de commencer le
> dump des tables. J'ai fait un test hier soir en créant une base à 8000
> tables. Je n'ai pas le message d'erreur que vous indiquez. Je viens
> aussi de monter à 90 pour max_lock_per_transactions, aucun soucis.
>
> Quelle version de PostgreSQL utilisez-vous ?
> Pouvez-vous nous envoyer votre fichier de configuration complet ?
> Quelle est la taille de la base ?
> D'autres clients sont-ils connectés en même temps que vous ?
>

Comme la plupart de la conversation qui a suivi s'est faire en dehors de
la liste, juste un petit mail pour indiquer que la solution revient bien
à augmenter max_lock_per_transactions.

pg_dump réalise toute la sauvegarde dans une seule transaction. Il pose
un verrou AccessShare sur toutes les tables au lancement de la commande,
ce qui peut prendre du temps et beaucoup de verrous si vous avez un très
grand nombre de tables. Il se peut même que le serveur n'ait pas assez
de mémoire pour enregistrer tous les verrous. D'où la nécessiter
d'augmenter max_lock_per_transactions.

Philippe l'a déjà augmenté jusqu'à 150 et ce n'est toujours pas
suffisant. J'espère qu'il nous dira jusqu'où il a dû aller pour faire
son dump :)

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Suite et fin !

Avec la commande suivante
pg_dump -C -D -d -v gourou -f /full_path/gourou.sql
j'ai monté le max_lock_per_transactions jusque 170,
et après plus de 24 H, le dump a de nouveau planté.

Par contre, avec celle-ci
pg_dump -F c gourou -f /full_path/gourou.dump
le max_lock_per_transactions minimal est de 100,
et le dump dure une petite heure.

Je crois que je vais en rester là :-)

Amicalement

Philippe Dhondt.

Le lundi 03 novembre 2008 à 14:35 +0100, Guillaume Lelarge a écrit :
> Guillaume Lelarge a écrit :
> > [...]
> > Ça ne m'étonne pas trop. Les verrous sont posés avant de commencer le
> > dump des tables. J'ai fait un test hier soir en créant une base à 8000
> > tables. Je n'ai pas le message d'erreur que vous indiquez. Je viens
> > aussi de monter à 90 pour max_lock_per_transactions, aucun soucis.
> >
> > Quelle version de PostgreSQL utilisez-vous ?
> > Pouvez-vous nous envoyer votre fichier de configuration complet ?
> > Quelle est la taille de la base ?
> > D'autres clients sont-ils connectés en même temps que vous ?
> >
>
> Comme la plupart de la conversation qui a suivi s'est faire en dehors de
> la liste, juste un petit mail pour indiquer que la solution revient bien
> à augmenter max_lock_per_transactions.
>
> pg_dump réalise toute la sauvegarde dans une seule transaction. Il pose
> un verrou AccessShare sur toutes les tables au lancement de la commande,
> ce qui peut prendre du temps et beaucoup de verrous si vous avez un très
> grand nombre de tables. Il se peut même que le serveur n'ait pas assez
> de mémoire pour enregistrer tous les verrous. D'où la nécessiter
> d'augmenter max_lock_per_transactions.
>
> Philippe l'a déjà augmenté jusqu'à 150 et ce n'est toujours pas
> suffisant. J'espère qu'il nous dira jusqu'où il a dû aller pour faire
> son dump :)
>
>