Vous n'êtes pas identifié(e).
Bonjour à tous,
je ne poste pas souvent ici car je n'ai pas de problème avec l'utilisation de postgresql. En tout cas jusqu'à aujourd'hui...
J'ai fait des mises à jour successives sur une table de quelques 4 millions de lignes. La taille de ma table a atteint 19 Go (contre moins de 1Go avant les mises à jour) et j'ai voulu opérer un VACCUM FULL (je suis le seul à y accéder).
Depuis, mon serveur refuse toute connexion et retourne ce message d'erreur :
"FATAL: le système de bases de données est en cours de restauration "
Le service est en cours d'execution si j'en crois la commande "service postgresql-9.2 status"
J'avais configuré syslog pour alimenter une base sur le même serveur (ce qui n'est pas très malin après-coup...).
Je viens de le relancer rsyslog pour logger dans les fichiers et voici les dernières lignes de logs concernant postgresql :
Aug 19 16:38:28 postgresql kernel: postmaster invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0, oom_score_adj=0
Aug 19 16:38:28 postgresql kernel: postmaster cpuset=/ mems_allowed=0
Aug 19 16:38:28 postgresql kernel: Pid: 20949, comm: postmaster Not tainted 2.6.32-358.6.2.el6.x86_64 #1
Aug 19 16:38:28 postgresql kernel: [15065] 26 15065 551087 2014 3 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [15068] 26 15068 551944 26488 3 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [15069] 26 15069 551328 20115 2 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [15070] 26 15070 551328 78 0 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [15071] 26 15071 551587 230 3 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [15072] 26 15072 45205 148 1 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [15076] 26 15076 551783 270 0 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [15078] 26 15078 551804 494 1 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [15080] 26 15080 560544 1924 2 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [15081] 26 15081 551603 713 1 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [15300] 26 15300 551636 476 2 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [18255] 26 18255 554906 1751 1 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [18826] 26 18826 552082 1750 0 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [19035] 26 19035 557429 11139 0 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [19515] 26 19515 552384 925 2 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [19642] 26 19642 551798 750 1 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [20919] 26 20919 551636 395 0 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [20949] 26 20949 2807869 1809867 1 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: [20959] 26 20959 551800 775 1 0 0 postmaster
Aug 19 16:38:28 postgresql kernel: Out of memory: Kill process 20949 (postmaster) score 732 or sacrifice child
Aug 19 16:38:28 postgresql kernel: Killed process 20949, UID 26, (postmaster) total-vm:11231476kB, anon-rss:7225636kB, file-rss:13832kBMa question est la suivante : mon serveur va-t-il retrouver un état normal ? Dois-je attendre ou le redémarrer ?
En cas de problème plus grave, d'autres objets que la table concernées pourront-ils être impactés ?
Merci beaucoup pour votre attention,
Mathieu (qui a besoin d'être ressuré)
Dernière modification par Mathieu BOSSAERT (19/08/2014 16:58:23)
Mathieu BOSSAERT
Conservatoire des Espaces Naturels du Languedoc-Roussillon
Responsable du Système d'Information
Hors ligne
Bonjour,
Un OOM s'est déclenché et a killé l'instance. Avez-vous d'autres applications gourmandes en mémoire sur le même serveurs ? Y a-t-il d'autres erreurs du genre par la suite ?
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour Julien,
non, rien de gourmand. la machine est bien dimensionnée et seuls apache et tomcat tournent dessus pour l'intranet très calme en ce moment.
Pas d'autres erreur par la suite si ce n'est le refus de connexion...
Mathieu BOSSAERT
Conservatoire des Espaces Naturels du Languedoc-Roussillon
Responsable du Système d'Information
Hors ligne
Et dans les logs postgres ?
Julien.
https://rjuju.github.io/
Hors ligne
rien dans pg_log/ tout était redirigé depuis sur postgres.
Voici ce que je trouve dans pgstartup.log :
-> : LOG: automatic vacuum of table "sicen.pg_catalog.pg_type": could not (re)acquire exclusive lock for truncate scan
-> : LOG: automatic vacuum of table "sicen.pg_catalog.pg_class": could not (re)acquire exclusive lock for truncate scan
-> : LOG: automatic vacuum of table "sicen.pg_catalog.pg_attribute": could not (re)acquire exclusive lock for truncate scan
-> : LOG: automatic vacuum of table "sicen.pg_catalog.pg_type": could not (re)acquire exclusive lock for truncate scan
sicen -> dba : LOG: envoi de l'annulation pour bloquer le PID 18992 de l'autovacuum
sicen -> dba : DÃTAIL: Le processus 20949 attend AccessExclusiveLock sur relation 5501835 de la base de données 1389423.
sicen -> dba : INSTRUCTION : VACUUM FULL VERBOSE dg.parc2
-> : ERREUR: annulation de la tâche d'autovacuum
-> : CONTEXTE : VACUUM automatique de la table « sicen.dg.parc2 »
-> : LOG: processus serveur (PID 20949) a été arrêté par le signal 9 : Killed
-> : DÃTAIL: Le processus qui a échoué exécutait : VACUUM FULL VERBOSE dg.parc2
-> : LOG: arrêt des autres processus serveur actifs
-> : ATTENTION: arrêt de la connexion à cause de l'arrêt brutal d'un autre processus serveur
-> : DÃTAIL: Le postmaster a commandé à ce processus serveur d'annuler la transaction
courante et de quitter car un autre processus serveur a quitté anormalement
et qu'il existe probablement de la mémoire partagée corrompue.
-> : ASTUCE : Dans un moment, vous devriez être capable de vous reconnecter à la base de
données et de relancer votre commande.Dernière modification par Mathieu BOSSAERT (19/08/2014 17:26:06)
Mathieu BOSSAERT
Conservatoire des Espaces Naturels du Languedoc-Roussillon
Responsable du Système d'Information
Hors ligne
On dirait que l'instance n'arrive pas à s'arrêter, malgré la demande d'arrêt qui a bien été reçue. Le plus sûr serait de redémarrer entièrement le serveur.
Julien.
https://rjuju.github.io/
Hors ligne
ok je teste.
Mathieu BOSSAERT
Conservatoire des Espaces Naturels du Languedoc-Roussillon
Responsable du Système d'Information
Hors ligne
Il semble refuser au tout du moins être long à s'arrêter...
Mathieu BOSSAERT
Conservatoire des Espaces Naturels du Languedoc-Roussillon
Responsable du Système d'Information
Hors ligne
Il a échoué sur l'arrêt (/etc/init.d/postgresql-9.2 restart)
Le démarrage semble ok mais impossible de se connecter : il me répond ceci :
psql: FATAL: le système de base de données s'arrêteMathieu BOSSAERT
Conservatoire des Espaces Naturels du Languedoc-Roussillon
Responsable du Système d'Information
Hors ligne
Je parlais d'un shutdown du serveur, pas de l'instance postgres. En l'état, postgres sait qu'il doit s'arrêter mais n'y arrive pas. Le reboot est donc la solution la plus sûre.
Julien.
https://rjuju.github.io/
Hors ligne
Oui j'ai compris après coup... C'est en cours.
Mathieu BOSSAERT
Conservatoire des Espaces Naturels du Languedoc-Roussillon
Responsable du Système d'Information
Hors ligne
Le redémarrage du serveur a fonctionné. Je peux me connecter à mes bases de données.
Merci Julien.
Très bonne soirée.
Mathieu BOSSAERT
Conservatoire des Espaces Naturels du Languedoc-Roussillon
Responsable du Système d'Information
Hors ligne
Bonne nouvelle 
N'hésitez pas à vérifier qu'il n'y ait pas de problèmes matériels sur le serveur par sûreté (dmesg, smartctl ...).
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour Julien,
c'est une machine virtuelle. Tout est ok de ce coté.
Merci encore.
Mathieu BOSSAERT
Conservatoire des Espaces Naturels du Languedoc-Roussillon
Responsable du Système d'Information
Hors ligne