Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
Ce post fait suivre à notre problème rencontré le 30/07/2008 : http://www.postgresqlfr.org/?q=node/1707
Nous n’arrivons pas à dumper notre base de données, la commande pg_dump se plante sur une grosse table ayant deux champs : un entier (id) et un bytea (blob qui stocke des fichiers)
Message d'erreur :
pg_dump: Dumping the contents of table "wct_binary" failed: PQgetCopyData() failed.
pg_dump: Error message from server: lost synchronization with server: got message type "d", length 658306580
pg_dump: The command was: COPY public.wct_binary (binary_id, data) TO stdout;
pg_dump: *** aborted because of error
Nous avons essayé plusieurs façons de faire mais la commande se plante toujours au même endroit. Testé avec plusieurs versions de pg_dump (8.0.14, 8.1.3, 8.3.3).
Infos techniques :
version base = 8.0.14
version OS = linux ES 4 up4
Après plusieurs tentatives d’essai de pg_dump avec différents paramètres, nous avons essayé le dump en mode ASCII pour voir ou pg_dump bloque. Nous avons supprimé l’enregistrement en question et le suivant mais rien n’y fait.
Le problème ne vient pas de la taille du fichier dump. Avant le fichier dump était de plus de 6 Go et ça fonctionnait.
De plus, lorsque nous avons généré le dump en mode ASCII, le fichier était de plus de 10 Go.
A priori pg_dump n'arrive pas à faire un fetch des 100 enregistrements suivants après un enregistrement en particulier.
Y'a t il un moyen de lui faire faire un fecth plus petit ?
Merci par avance.
Cordialement
Ugo BRUNEL
Hors ligne
Bonjour,
Je viens de regarder un peu le code de pgdump.c et j'ai quelques questions.. Bien sûr, vous utilisez une vieille version de PostgreSQL, mais ça n'explique pas ce comportement, du moins je le pense.
Je me demande s'il n'y a pas une corruption de données. Est-ce qu'un "SELECT * FROM wct_binary" aboutit sans erreur(s)? Si oui, quelles sont-elles?
Enfin, pourriez-vous augmenter le niveau de messages renvoyés par PostgreSQL? Sauvegardez votre postgresql.conf et changez les paramètres log_... pour mettre des valeurs à DEBUG1 par exemple...
En espérant que vous puissiez nous poster plus de détails,
Cordialement,
Jean-Paul Argudo
https://www.postgresql.fr
https://www.crunchydata.com
Hors ligne
Bonjour Jean-Paul et merci de votre aide,
J'ai testé SELECT * FROM wct_binary mais j'ai l'erreur : "out of memory for query result".
Par contre, je ne pense pas que l'on est uno corruption de bloc car en attendant de corriger notre problème nous sauvegardons les tables par des commandes : "COPY table TO file" sur chaque table et nous n'avons pas d'erreur sur la table wct_binary. Cette commande doit faire l'équivalent d'un SELECT * from wct_binary et elle fonctionne correctement.
J'ai mis dans $PGDATA/postgresql.conf :
#---------------------------------------------------------------------------
# ERROR REPORTING AND LOGGING
#---------------------------------------------------------------------------
log_destination = 'syslog' # Valid values are combinations of stderr,
redirect_stderr = true # Enable capturing of stderr into log files.
log_directory = '/vc10q08/prd/exp/log' # Directory where log files are written.
log_filename = 'postgresql-%a.log' # Log file name pattern.
log_truncate_on_rotation = true # If true, any existing log file of the
log_rotation_age = 1440 # Automatic rotation of logfiles will happen after
log_rotation_size = 0 # Automatic rotation of logfiles will happen after
syslog_facility = 'LOCAL0'
syslog_ident = 'postgres'
log_min_messages = debug1 # Values, in order of decreasing detail:
log_min_messages = debug1 # Values, in order of decreasing detail:
log_min_error_statement = debug1 # Values in order of increasing severity:
log_connections = true
log_line_prefix = '%t' # e.g. '<%u%%%d> 'J'ai relancé le pg_dump avec :
pg_dump -Fc -Z9 -b webct95 > test_dump_webct95.dmpLe process prends 99,2 % de CPU et tourne depuis 1h30 et à générer pour le moment un fichier de 759 Mo.
Pour le moment, je n'ai aucune traces de généré.
Je vous enverrais les traces que je pourrais récupérer une fois le traitement terminé.
Merci par avance
Cordialement
Ugo BRUNEL
Hors ligne
Ok.
Merci pour ce retour... Attention à l'option -Z 9 ... Cela signifie que vous demandez une compression maximale. Je pense que cela peut expliquer une bonne partie du temps et de la charge CPU. Pourquoi compresser autant? Pourriez vous essayer avec une compression minimale? (-Z 1 ?) voire sans compression (-Z 0) (mais attention à l'espace disque!)...
Cordialement,
Jean-Paul Argudo
https://www.postgresql.fr
https://www.crunchydata.com
Hors ligne
Re,
J'ai soumis votre cas à la communauté, voici les bonnes idées qui en ressortent:
- cela semble être un problème avec la partie CLIENTE de votre installation et pas le serveur, puisque le COPY marche et que COPY (de la façon dont vous le faites: COPY table TO file) est une commande serveur.
- essayez de faire un \copy dans le client psql:
\copy table [ ( liste_colonne ) ] { from | to } { nomfichier | stdin | stdout | pstdin | pstdout } [ with ] [ oids ] [ delimiter [ as ] 'caractère' ] [ null [ as ] 'chaîne' ] [ csv [ quote [ as ] 'caractère' ] [ escape [ as ] 'caractère' ] [ force quote liste_colonne ] [ force not null liste_colonne ] ]
à mon avis, ce \copy echouera comme le backup.
Une solution consisterait alors à utiliser un pg_dump dans une version plus récente, pourquoi pas 8.2... Il vous faudra alors installer (ou compiler si ça n'est pas disponible en paquet pour votre Red Hat) un paquet "postgresql-client" plus récent.
À mon humble avis, et pour éviter tout problème sur ce serveur (de production si j'ai bien compris), je vous engage à installer ce client PostgreSQL sur un autre serveur et à dumper depuis ce dernier.
Tenez-nous au courant de ces quelques tests.
Merci !
Jean-Paul Argudo
https://www.postgresql.fr
https://www.crunchydata.com
Hors ligne
Bonjour Jean-Paul,
pg_dump s'est planté sur une erreur mémoire insuffisante (autre erreur qu'initialement) :
Fri Sep 26 15:05:59 CEST 2008
pg_dump: ERREUR: mémoire insuffisante
DETAIL: Echec d'une requête de taille 1073741823.
pg_dump: SQL command to dump the contents of table "wct_binary" failed: PQendcopy() failed.
pg_dump: Error message from server: ERREUR: mémoire insuffisante
DETAIL: Echec d'une requête de taille 1073741823.
pg_dump: The command was: COPY public.wct_binary (binary_id, data) TO stdout;
Fri Sep 26 21:55:06 CEST 2008
Le fichier est arrivé avec une taille de 3,38 Go (3636299114 o)
Je vais fournir une copie de la table à un autre service qui a des serveurs de tests et des versions différentes de PostgreSQL. Je leur ai demandé également de mettre à jour cette discussion avec le résultat de leurs tests.
Bon week-end et encore merci de votre aide
Cordialement
Ugo BRUNEL
Hors ligne
Bonjour;
Je dois récupérer la table pour pouvoir faire des essais sur une base de tests. Cela semble trainer un peu. Je ferai une maj de ce post dès que possible.
Vous remerciant.
Hors ligne
Bonjour,
Je suis désolé pour le temps qui est passé, mais nous avons monté un serveur spécialement pour reproduire le problème !
Les nouveaux essais sont réalisés sur une SLES10 et Postgres 8.3.3.
Le problème se reproduit avec une version plus récente de Postgres, la 8.3.3 !
La table wct_binary a été chargée avec la commande COPY FROM sans erreurs !
------------------------------------------------------------------------------------------------------------
1 ESSAI
------------------------------------------------------------------------------------------------------------
1 J'ai utilisé le fichier de configuration postgresql.conf crée par défaut dans la version 8.3.3 !
2 J'ai lancé la commande : pg_dump -Fc -b pbpgdump >exp-wct-binary1.dmp
Et au bout de 1h15mn l'erreur suivante apparaît :
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: out of memory
DETAIL: Failed on request of size 539138274.
pg_dump: The command was: COPY public.wct_binary (binary_id, data) TO stdout;
Le fichier fait 3,8GIGA !
-rw-r--r-- 1 postgres postgres 3822203378 2008-10-15 15:20 exp-wct_binary1.dmp
------------------------------------------------------------------------------------------------------
2 ESSAI
------------------------------------------------------------------------------------------------------
1 J'ai utilisé le fichier de configuration postgresql.conf du client, celui de la version 8.0.3 !
2 J'ai lancé la commande : pg_dump -Fc -b base1 >exp-wct-binary2.dmp
Et au bout de 20mn l'erreur suivante apparait :
pg_dump -Fc -b pbpgdump > exp-wct_binary2.dmp
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: out of memory
DETAIL: Failed on request of size 268435456.
pg_dump: The command was: COPY public.wct_binary (binary_id, data) TO stdout;
Le fichier fait 0,9GIGA
-rw-r--r-- 1 postgres postgres 937695311 2008-10-15 16:42 exp-wct_binary2.dmp
-----------------------------------------------------------------------------------------------------------------------------
Donc, à priori il semble que la table n'ait pas de corruptions, puisque cela se plante à des endroits différents !
Ensuite cela ressemble à un problème de mauvaise gestion de ressources puisque, en fonction de fichier postgresql.conf utilisé
le delais pour que le plantage arrive différe (et aussi la taille du fichier dump) !
J'ai fait deux fois les mêmes éssais et, a chaque fois les tailles des fichiers sont identiques !
-rw-r--r-- 1 postgres postgres 3822203378 2008-10-15 15:20 exp-wct_binary1.dmp
-rw-r--r-- 1 postgres postgres 937695311 2008-10-15 16:42 exp-wct_binary2.dmp
-rw-r--r-- 1 postgres postgres 937695311 2008-10-15 17:08 exp-wct_binary3.dmp
-rw-r--r-- 1 postgres postgres 3822203378 2008-10-15 18:54 exp-wct_binary4.dmp
J'ai regardé la différence entre les deux fichiers de configuration postgresql.conf au niveau du paragraphe
RESOURCE USAGE
------------------------------------------------------------------------------------------------------------------------------
1 ESSAI : Cas plantage au bout de 1h15mn et le fichier dump de 3,8GB avec fichier postgresl.conf crée par défaut:
#-------------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#------------------------------------------------------------------------------
# - Memory -
shared_buffers = 32MB # min 128kB or max_connections*16kB
#temp_buffers = 8MB # min 800kB
#max_prepared_transactions = 5 # can be 0 or more
#work_mem = 1MB # min 64kB
#maintenance_work_mem = 16MB # min 1MB
#max_stack_depth = 2MB # min 100kB
max_fsm_pages = 204800 # min max_fsm_relations*16, 6 bytes each
#max_fsm_relations = 1000 # min 100, ~70 bytes each
#max_files_per_process = 1000 # min 25
#shared_preload_libraries = '' # (change requires restart)
#vacuum_cost_delay = 0 # 0-1000 milliseconds
#vacuum_cost_page_hit = 1 # 0-10000 credits
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 1-10000 credits
#bgwriter_delay = 200ms # 10-10000ms between rounds
#bgwriter_lru_maxpages = 100 # 0-1000 max buffers written/round
#bgwriter_lru_multiplier = 2.0 # 0-10.0 multipler on buffers scanned/round
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2 ESSAI : Cas plantage au bout de 20mn et le fichier dump de 0,9GB, avec fichier postgresql.conf du client de la version 8.0.3:
#---------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#---------------------------------------------------------------------------
shared_buffers = 42000 # min 16, at least max_connections*2, 8KB each
work_mem = 250000 # min 64, size in KB
maintenance_work_mem = 500000 # min 1024, size in KB
#max_stack_depth = 2048 # min 100, size in KB
max_fsm_pages = 250000 # min max_fsm_relations*16, 6 bytes each
max_fsm_relations = 12000 # min 100, ~50 bytes each
#max_files_per_process = 1000 # min 25
#preload_libraries = ''
#vacuum_cost_delay = 0 # 0-1000 milliseconds
#vacuum_cost_page_hit = 1 # 0-10000 credits
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 0-10000 credits
#bgwriter_delay = 200 # 10-10000 milliseconds between rounds
#bgwriter_percent = 1 # 0-100% of dirty buffers in each round
#bgwriter_maxpages = 100 # 0-1000 buffers max per round
------------------------------------------------------------------------------------------------------------------------------------------
Diverses informations :
------------------------------------------------------------------------------------------------------------------------------------------
La table à deux champs :
Create table wct_binary(
binary_id integer NOT NULL,
data bytea);
------------------------------------------------------------------------------------------------------------------------------------------
La commande: > select binary_id from wct_binary ne pose pas de problème !
------------------------------------------------------------------------------------------------------------------------------------------
# select count(*) from wct_binary;
count
-------
53467
(1 row)
------------------------------------------------------------------------------------------------------------------------------------------
> free
total used free shared buffers cached
Mem: 365020 360396 4624 0 2912 17056
-/+ buffers/cache: 340428 24592
Swap: 554200 370592 183608
------------------------------------------------------------------------------------------------------------------------------------------
> ulimit -a (en étant le user postgres)
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
pending signals (-i) 2912
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 2912
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
-------------------------------------------------------------------------------------------------------------------------------------------
Si vous avez d'autres idées pour faire avancer le problème.....(modifications de paramètres etc...)
Merci encore pour votre aide !
Hors ligne
Le problème ne vient pas forcément de la conf. Ce message (http://archives.postgresql.org/pgsql-ad … g00223.php) de Tom Lane donne une information qui me paraît plus intéressant. Il donne comme hypothèse que PostgreSQL n'arrive pas à mettre en mémoire une ligne. Dans votre cas, cela voudrait dire que le serveur n'arrive pas à mettre en mémoire une ligne de 540 Mo dans le premier cas et dans le second cas de 270 Mo. Pourquoi la différence ? Elle est certainement dû à la place que PostgreSQL prend déjà en mémoire pour sa mémoire cache. Il se trouve justement que dans le premier cas, le shared_buffers est de 32 Mo et dans le second, de 328 Mo... soit une différence à peu près équivalente.
Serait-il possible que vous ayez une ligne de plus de 250Mo dans votre table ? De combien de RAM disposez-vous ?
Guillaume.
Hors ligne
Jean-Paul m'a soufflé dans l'oreillette que fournir la requête idoine serait un plus. Donc, je fais :
SELECT identifiant, octet_length(la_colonne_bytea) as taille FROM la_table WHERE octet_length(la_colonne_bytea)>250000000 ORDER BY 2 DESC;
Attention, ça risque de prendre du temps.
Guillaume.
Hors ligne
Bonjour,
Merci pour ces informations
Voici le résultat de la commande :
Il n'y a pas d'enregistrement qui dépasse 250MB, par contre, il y en a un qui fait 184MB !
pbpgdump=# \d wct_binary
Table "public.wct_binary"
Column | Type | Modifiers
-----------+---------+-----------
binary_id | integer | not null
data | bytea |
pbpgdump=# SELECT binary_id, octet_length(data) as taille FROM wct_binary WHERE octet_length(data)>250000000 ORDER BY 2 DESC;
binary_id | taille
-----------+--------
(0 rows)
pbpgdump=# SELECT binary_id, octet_length(data) as taille FROM wct_binary WHERE octet_length(data)>25000000 ORDER BY 2 DESC;
binary_id | taille
-----------+-----------
5001955 | 184678586
5002608 | 59518226
4481757 | 55249267
4386235 | 42001376
4260858 | 26941440
4104903 | 26091548
(6 rows)
Gérald
Hors ligne
De mon coté je vais faire un "delete" sur la rangée qui fait 184MB (binary_id à 5001955) sur la base de test, et ensuite de nouveau un pg_dump !
Encore merci pour les infos !
Gérald.
Hors ligne
A priori, avec la suppression de la rangée de 184MB, le pg_dump à l'air de fonctionner correctement, le dump
fait déjà 8GB...ce n'est pas encore terminé, mais c'est bien parti !
C'était donc bien lié a un problème de taille de ligne.
On regarde en prod si cela ne pose pas de problèmes !
Encore merci.
Gérald.
Hors ligne
Ok..
La conclusion de l'histoire est double:
1. Tom Lane est vraiment trop fort
2. On fait un bug report sur pgsql-hackers, en se servant de votre exemple détaillée et précis. On verra bien ce que les hackers en pensent...
Merci pour la masse d'informations envoyées, je pense qu'on devrait pouvoir transformer tout cela en bug report.
Tenez nous au courant ça marche/ça marche pas.
Jean-Paul Argudo
https://www.postgresql.fr
https://www.crunchydata.com
Hors ligne
Bonjour, je suis en attente de réponse de la production, mais à priori cela semble OK !
De note coté on garde encore la machine de test, donc il est encore possible de récupérer des éléments !
Et encore merci pour votre aide !
Gérald LAURENT.
Hors ligne
Bonjour,
l'enregistrement de 184 MB a été supprimé en production (cela avait déjà été fait en, pre-prod), et depuis cela la commande "pg_dump" fonctionne correctement.
Merci beaucoup pour votre investissement.
Gérald LAURENT.
Hors ligne
De rien!
Bien content que vous ayez pu résoudre votre problème...
Bonne journée,
Jean-Paul Argudo
https://www.postgresql.fr
https://www.crunchydata.com
Hors ligne
Pareil 
Guillaume.
Hors ligne
Pages : 1