Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
Je souhaite charger un export réalisé avec pg_dump sur une base vierge.
Après avoir lancé la commande pg_restore, j'ai ce message d'erreur suivant dans le fichier de log :
LOG: server process (PID 20226) was terminated by signal 9: Killed
DETAIL: Failed process was running: CREATE INDEX idx_name ON table_name USING btree (c1, c2, c3)
Le chargement s'est arrêté au bout de 3 heures. Et les tables ne sont pas présente (sûrement dû à un rollback de l'opération).
Le log de ma commande indique :
Pg_restore: [archiver (db) ] could not execute query: server closed the connexion unexpectedly
Est-ce que quelqu'un aurait une idée de la provenance de l'erreur ?
Il s'agit d'un environnement utilisé par beaucoup d'utilisateurs métier avec un caractère critique...
Infos :
Shared_buffers = 12gb
Maintenance_work_mem = 10gb
Wal_keep_segments = 20
Max_wal_size = 1gb
Fsync = off
Volume de la base ~ 215 gb
Version de PostgreSQL : 9.5
Merci à tous.
Hors ligne
Signal 9... Il a été tué soit par un admin, soit parce que le serveur était à court de mémoire... Ça semble être un Linux, essayez déjà la commande dmesg pour confirmer que vous avez un message d'erreur out of memory ... Si oui, combien de RAM a le serveur, et est ce que vous n'auriez pas restauré avec une option -j à pgrestore?
Marc.
Hors ligne
Merci beaucoup pour ce retour.
Processus tué par une autre personne, effectivement ça pourrait être cela sachant que je ne suis pas le seul à accéder au serveur. De plus, sur la précédente tentative de chargement , il me semble (de mémoire) avoir eu un signal 6 «aborted».
Lorsque vous dites que le serveur pourrait être à cour de mémoire, vous parlez d'espace disque ou de RAM ?
Le serveur Red Hat 7 a 16gb de RAM.
Je n'ai pas utilisé plusieurs job (pas de -j X).
J'analyserai la commande dmesg à mon arrivée.
Merci encore Marc.
Hors ligne
bonjour
autre piste : OOM Killer.
Vu les paramètres mémoire de votre postgresql.conf on peut considérer que vous n'avez "que" 16gb de RAM sur votre serveur.
Il est possible alors que votre process ai été tué par le serveur redhat via oom killer. A vérifier dans vos traces redhat.
Cordialement,
Sébastien.
Hors ligne
Je dirais même que c'est très probable. Avec 12 Go de shared_buffers, il ne reste plus que 4 Go pour les processus. Quand on voit que le maintenance_work_mem est à 10 Go qui se trouve justement être la mémoire utilisée lors d'un CREATE INDEX, il ne faudrait pas s'étonner que l'OOM killer ait balancé un kill -9 au serveur.
Et je prie très très fort pour que le fsync à off ne soit là uniquement que pour intégrer le dump, et soit rebasculé à on tout de suite après.
Guillaume.
Hors ligne
C'est clairement un problème de RAM. Avec 16Go de RAM, redescendez shared_buffers à 4GB, maintenance_work_mem à 1GB ça devrait passer tout seul. Et oui, c'est l'OOM qui a tué votre processus de restauration
Marc.
Hors ligne
Bravo Messieurs.
C'est effectivement cela.
Un collègue m'a préconisé de modifier le shared_buffers à 5 Gb et la maintenance_work_mem à 6Gb.
Avec ces modifications, le chargement a été réalisé avec succès.
En espérant que cette discussion aide d'autres.
Merci à tous.
Hors ligne
Le maintenance_work_mem à 6 Go est bien trop haut. Si vous avez trois autovacuum workers qui se mettent à l'utiliser, vous arriverez potentiellement à 3x6+5, soit 23 Go. Kaboom! Comme l'indique Marc, placez le à 1 Go.
Guillaume.
Hors ligne
J'ai oublié de le préciser dans mon premier message, j'avais désactivé l'autovacuum tout comme le fsync pendant le chargement.
Et oui effectivement, il fallait bien prendre en compte les potentiels processus d'autovacuum.
Morale de l'histoire, prendre le temps de bien paramétrer la mémoire.
Dernière modification par Mika313 (07/04/2018 09:36:35)
Hors ligne
Pages : 1
