Vous n'êtes pas identifié(e).
Bonjour,
J'ai une installation de PostgreSQL 8.3.5 sur un serveur dédié avec Windows Server 2003.
J'ai 3 clusters sur cette installation.
L'un de ces clusters est dédié à des bases de données utilisées par opencms. Un seul utilisateur fait les accès aux différentes bases de ce cluster.
Le nombre d'erreurs journalières signalé par l'observateur d'événements de windows est important, environ 150 depuis ce matin, et ce même lorsqu'il y peu de connexions sur les bases de données. Toutes les quelques minutes une nouvelle erreur est signalée.
Les informations sont pauvres :
Type de l'événement : Erreur
Source de l'événement : PostgreSQL
Catégorie de l'événement : Aucun
ID de l'événement : 0
Date : 17.06.2009
Heure : 14:42:47
Utilisateur : N/A
Ordinateur : HESTIA
Description :
La description pour l'ID d'événement ( 0 ) dans la source (PostgreSQL) est introuvable. L'ordinateur local n'a peut-être pas les informations de Registre ou les librairies requises pour afficher les messages émanant d'un ordinateur distant. Vous pourrez peut-être utiliser l'option /AUXSOURCE= pour récupérer cette description. Reportez-vous aux rubriques Aide et support pour plus de détails. Les informations suivantes font partie de l'événement : n'a pas pu écrire dans le journal applicatif : Bad file descriptor
Quelqu'un aurait-il une idée pour orienter mes recherches?
Par avance merci
Sylvie
Hors ligne
Que vaut le paramètre log_destination ? car apparemment, il n'arrive pas à écrire les traces (journaux applicatifs).
Guillaume.
Hors ligne
Bonsoir,
Globalement, j'ai mis en place quelques tracages de commandes sql exécutées. J'ai donc un fichier par jour dans le répertoire pg_log mais tel qu'il est actuellement, il ne contient pas d'informations utiles pour ce problème.
Voici quelques paramétrages de cette section. Pour la majorité des lignes j'ai laissé les valeurs par défaut.
#log_destination = 'stderr'
#logging_collector = off
#log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d.log'
#client_min_messages = notice
#log_min_messages = notice
#log_error_verbosity = default
#log_min_error_statement = error
log_min_error_statement = notice
log_duration = on
log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u,statement=%i '
log_statement = 'mod'
Une proposition?
Merci d'avoir répondu aussi rapidement!
Sylvie
Hors ligne
Je suis très étonné que le logging_collector soit à off sous Windows. Je n'ai pas de machines Windows sous la main, donc je ne peux pas tester. Essayez en décommentant logging_collector et en l'initialisant à la valeur on.
Après redémarrage de PostgreSQL, les logs devraient apparaître dans le sous-répertoire pg_log du répertoire des données de PostgreSQL.
Guillaume.
Hors ligne
Dans une install fraiche 8.3 avec pginstaller sous windows, il est effectivement à on.
Marc.
Hors ligne
En fait, ce paramètre est à ON. J'ai voulu limiter le volume du code à vous présenter mais ce n'était pas une bonne idée. Je m'en excuse.
Voici le contenu intégral de 2 sections du fichier postgreql.conf
Dans le répertoire pg_log je génère un fichier par jour mais avec le paramétrage que j'ai fait, j'ai principalement des informations sur les commandes SQL. Donc peu d'aide pour le problème actuel à savoir les erreurs de l'observateur d'événements.
Merci
Sylvie
#------------------------------------------------------------------------------
# ERROR REPORTING AND LOGGING
#------------------------------------------------------------------------------
# - Where to Log -
#log_destination = 'stderr' # Valid values are combinations of
# stderr, csvlog, syslog and eventlog,
# depending on platform. csvlog
# requires logging_collector to be on.
# This is used when logging to stderr:
#logging_collector = off # Enable capturing of stderr and csvlog
# into log files. Required to be on for
# csvlogs.
# (change requires restart)
logging_collector = on
# These are only used if logging_collector is on:
#log_directory = 'pg_log' # directory where log files are written,
# can be absolute or relative to PGDATA
#log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name pattern,
# can include strftime() escapes
log_filename = 'postgresql-%Y-%m-%d.log'
#log_truncate_on_rotation = off # If on, an existing log file of the
# same name as the new log file will be
# truncated rather than appended to.
# But such truncation only occurs on
# time-driven rotation, not on restarts
# or size-driven rotation. Default is
# off, meaning append to existing files
# in all cases.
#log_rotation_age = 1d # Automatic rotation of logfiles will
# happen after that time. 0 to disable.
#log_rotation_size = 10MB # Automatic rotation of logfiles will
# happen after that much log output.
# 0 to disable.
# These are relevant when logging to syslog:
#syslog_facility = 'LOCAL0'
#syslog_ident = 'postgres'
# - When to Log -
#client_min_messages = notice # values in order of decreasing detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# log
# notice
# warning
# error
#log_min_messages = notice # values in order of decreasing detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# info
# notice
# warning
# error
# log
# fatal
# panic
#log_error_verbosity = default # terse, default, or verbose messages
#log_min_error_statement = error # values in order of decreasing detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# info
# notice
# warning
# error
# log
# fatal
# panic (effectively off)
log_min_error_statement = notice
#log_min_duration_statement = -1 # -1 is disabled, 0 logs all statements
# and their durations, > 0 logs only
# statements running at least this time.
#silent_mode = off # DO NOT USE without syslog or
# logging_collector
# (change requires restart)
# - What to Log -
#debug_print_parse = off
#debug_print_rewritten = off
#debug_print_plan = off
#debug_pretty_print = off
#log_checkpoints = off
#log_connections = off
#log_disconnections = off
#log_duration = off
log_duration = on
#log_hostname = off
#log_line_prefix = '' # special values:
# %u = user name
# %d = database name
# %r = remote host and port
# %h = remote host
# %p = process ID
# %t = timestamp without milliseconds
# %m = timestamp with milliseconds
# %i = command tag
# %c = session ID
# %l = session line number
# %s = session start timestamp
# %v = virtual transaction ID
# %x = transaction ID (0 if none)
# %q = stop here in non-session
# processes
# %% = '%'
# e.g. '<%u%%%d> '
log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u,statement=%i '
#log_lock_waits = off # log lock waits >= deadlock_timeout
#log_statement = 'none' # none, ddl, mod, all
log_statement = 'mod'
#log_temp_files = -1 # log temporary files equal or larger
# than specified size;
# -1 disables, 0 logs all temp files
#log_timezone = unknown # actually, defaults to TZ environment
# settingHors ligne
J'aurais tendance à vérifier qu'il est bien possible d'écrire dans ce répertoire et qu'aucun antivirus ne tente d'opération dessus.
Guillaume.
Hors ligne
L'utilisateur des services Postgres a les droits d'écriture sur les répertoires pg_log de chaque cluster puisqu'un nouveau fichier y est créé chaque jour.
Malheureusement, son contenu ne me permet pas de détecter la source des erreurs signalées dans l'observateur d'événements qui contient si peu d'information sur ces erreurs.
Pour ce qui est de l'anti-virus, j'ai demandé au responsable système d'exclure la surveillance de ce répertoire par l'anti-virus du serveur. Dès que j'aurai plus d'infos je vous les transmettrai.
Je me pose une question : Etant donné que ces erreurs apparaissent toutes les n minutes pensez-vous que cela puisse être en lien avec l'auto-vaccum? Mais, comme il n'y pas d'erreurs signalées la nuit je ne pense pas que ce soit le cas.
Une autre question : Pensez-vous que cela puisse provenir de l'encodage des caractères? Lorsque j'ai migré de la version 8.2.3 vers la version 8.3.4 la locale du serveur a été prise par défaut et tous les messages sont en français. Dans les logs, il y a des problèmes d'encodage avec les caractères accentués.
Bref, je ne sais pas trop dans quelle direction orienter mes recherches. Mon premier objectif était d'essayer d'obtenir des messages plus explicites dans les erreurs de l'observateur d'événements.
Merci
Sylvie
Hors ligne
Etant donné que ces erreurs apparaissent toutes les n minutes pensez-vous que cela puisse être en lien avec l'auto-vaccum?
Non. (Le moyen simple de le tester est de désactiver l'autovacuum sur une journée, ce qui ne devrait pas poser de soucis pour la prod)
Pensez-vous que cela puisse provenir de l'encodage des caractères?
Pas à ma connaissance. Si vous parlez de l'encodage des traces, vous pouvez les mettre en anglais en positionnant lc_messages à 'C'.
Guillaume.
Hors ligne
Quelques éléments nouveaux :
- Pas de changement après paramétrage de l'autovacuum à off, j'ai toujours une multitude d'erreurs dans l'observateur d'événements,
- J'ai trouvé le moyen d'obtenir des messages plus clairs dans l'observateur d'événements de Windows :
En fait, il faut enregistrer la bibliothèque eventlog sur Windows. Cela permet de créer les entrées de registre utilisées par l'observateur d'événements.
Voici la commande à exécuter depuis une console DOS :
regsvr32 chemin_librairies_psql/pgevent.dllet le lien où j'ai trouvé cette info http://docs.postgresqlfr.org/8.3/INSTALL.html
Le message du début de cette discussion devient ainsi :
n'a pas pu écrire dans le journal applicatif : Bad file descriptor
Je continue mes recherches du côté de l'anti-virus.
Par contre je n'arrive pas à obtenir les messages en anglais dans les logs. J'ai bien mis lc_messages = 'C' puis j'ai redémarré le serveur mais ils sont toujours en français. Je ne trouve pas la liste des valeurs possibles pour ce paramètre dans la doc. Avez-vous une autre proposition?
Merci
Sylvie
Hors ligne
J'ai entendu dire que le changement d'encodage des messages pouvait poser problème sur Windows. C'est peut-être ce cas. Je ne peux pas tester sur mon poste Windows actuellement, n'étant pas chez moi. Néanmoins, je suis pratiquement certain qu'un de mes clients a les traces en anglais. Je vais vérifier cela.
Guillaume.
Hors ligne