Multitude d'erreurs dans l'observateur d'événements windows

sbouchard · 17/06/2009 16:16:45

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

gleu · 17/06/2009 17:15:53

Que vaut le paramètre log_destination ? car apparemment, il n'arrive pas à écrire les traces (journaux applicatifs).

sbouchard · 17/06/2009 20:11:46

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

gleu · 18/06/2009 09:02:20

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.

Marc Cousin · 18/06/2009 09:20:19

Dans une install fraiche 8.3 avec pginstaller sous windows, il est effectivement à on.

sbouchard · 18/06/2009 10:14:46

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
					# setting

gleu · 18/06/2009 10:41:23

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.

sbouchard · 19/06/2009 08:08:12

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

gleu · 19/06/2009 10:15:27

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'.

sbouchard · 19/06/2009 15:52:14

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.dll

et 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

gleu · 19/06/2009 16:33:43

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.

#1 17/06/2009 16:16:45

Multitude d'erreurs dans l'observateur d'événements windows

#2 17/06/2009 17:15:53

Re : Multitude d'erreurs dans l'observateur d'événements windows

#3 17/06/2009 20:11:46

Re : Multitude d'erreurs dans l'observateur d'événements windows

#4 18/06/2009 09:02:20

Re : Multitude d'erreurs dans l'observateur d'événements windows

#5 18/06/2009 09:20:19

Re : Multitude d'erreurs dans l'observateur d'événements windows

#6 18/06/2009 10:14:46

Re : Multitude d'erreurs dans l'observateur d'événements windows

#7 18/06/2009 10:41:23

Re : Multitude d'erreurs dans l'observateur d'événements windows

#8 19/06/2009 08:08:12

Re : Multitude d'erreurs dans l'observateur d'événements windows

#9 19/06/2009 10:15:27

Re : Multitude d'erreurs dans l'observateur d'événements windows

#10 19/06/2009 15:52:14

Re : Multitude d'erreurs dans l'observateur d'événements windows

#11 19/06/2009 16:33:43

Re : Multitude d'erreurs dans l'observateur d'événements windows

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux