Plantage fréquent

Bonjour,

Sur un de nos serveurs nous avons un postgreSQL qui plante
régulièrement, et nous n'arrivons pas à en trouver le cause.

Parfois il reste des processus postgres.exe qui tournent alors que le
service a planté. Dans ce cas il faut les tuer manuellement pour
relancer le service...

Quelques données :
- machine virtuelle
- OS : Windows 2008 SP2 64b
- postgreSQL : 9.3.5
- postgis : 2.1.4

Les ressources CPU et RAM semble largement disponibles. Pour les accès
disque, je ne sais pas, mais l'hébergeur me dis que tout va bien.

Avez-vous des idées svp ?

Merci

Thomas

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

On Friday 09 January 2015 15.22:44 Thomas RAFFIN wrote:
> Bonjour,
>
> Sur un de nos serveurs nous avons un postgreSQL qui plante
> régulièrement, et nous n'arrivons pas à en trouver le cause.
>
> Parfois il reste des processus postgres.exe qui tournent alors que le
> service a planté. Dans ce cas il faut les tuer manuellement pour
> relancer le service...
>
> Quelques données :
> - machine virtuelle
> - OS : Windows 2008 SP2 64b
> - postgreSQL : 9.3.5
> - postgis : 2.1.4
>
> Les ressources CPU et RAM semble largement disponibles. Pour les accès
> disque, je ne sais pas, mais l'hébergeur me dis que tout va bien.
>
> Avez-vous des idées svp ?
>
> Merci
>
> Thomas

Une database contenant une extension non alignée avec la version du serveur
qui provoquerait un segfault ?

re-vérifier les modules, et aussi les valeurs d'insertion automatique dans le fichier postgresql.conf

--

Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch

openSUSE Member & Board, fsfe fellowship
GPG KEY : D5C9B751C4653227
irc: tigerfoot

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Le 09/01/2015 15:32, Bruno Friedmann a écrit :
> On Friday 09 January 2015 15.22:44 Thomas RAFFIN wrote:
>> Bonjour,
>>
>> Sur un de nos serveurs nous avons un postgreSQL qui plante
>> régulièrement, et nous n'arrivons pas à en trouver le cause.
>>
>> Parfois il reste des processus postgres.exe qui tournent alors que le
>> service a planté. Dans ce cas il faut les tuer manuellement pour
>> relancer le service...
>>
>> Quelques données :
>> - machine virtuelle
>> - OS : Windows 2008 SP2 64b
>> - postgreSQL : 9.3.5
>> - postgis : 2.1.4
>>
>> Les ressources CPU et RAM semble largement disponibles. Pour les accès
>> disque, je ne sais pas, mais l'hébergeur me dis que tout va bien.
>>
>> Avez-vous des idées svp ?
>>
>> Merci
>>
>> Thomas
> Une database contenant une extension non alignée avec la version du serveur
> qui provoquerait un segfault ?
J'ai ces extensions :
- plpgsql en 1.0
- postgis en 2.1.4
- postgis_topology 2.1.4 aussi

Les postgis* sont bien indiquées comme compatibles.

> re-vérifier les modules,

C'est les extensions ou autres chose ?

> et aussi les valeurs d'insertion automatique dans le fichier postgresql.conf

Je ne sais pas de quoi il s'agit et ne trouve pas de doc...

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

> Le 09/01/2015 15:32, Bruno Friedmann a écrit :
>> On Friday 09 January 2015 15.22:44 Thomas RAFFIN wrote:
>>> Bonjour,
>>>
>>> Sur un de nos serveurs nous avons un postgreSQL qui plante
>>> régulièrement, et nous n'arrivons pas à en trouver le cause.
>>>
>>> Parfois il reste des processus postgres.exe qui tournent alors que le
>>> service a planté. Dans ce cas il faut les tuer manuellement pour
>>> relancer le service...
>>>
>>> Quelques données :
>>> - machine virtuelle
>>> - OS : Windows 2008 SP2 64b
>>> - postgreSQL : 9.3.5
>>> - postgis : 2.1.4
>>>
>>> Les ressources CPU et RAM semble largement disponibles. Pour les accès
>>> disque, je ne sais pas, mais l'hébergeur me dis que tout va bien.
>>>
>>> Avez-vous des idées svp ?
>>>
>>> Merci
>>>
>>> Thomas
>> Une database contenant une extension non alignée avec la version du
>> serveur
>> qui provoquerait un segfault ?
> J'ai ces extensions :
> - plpgsql en 1.0
> - postgis en 2.1.4
> - postgis_topology 2.1.4 aussi
>
> Les postgis* sont bien indiquées comme compatibles.
>
>> re-vérifier les modules,
>
> C'est les extensions ou autres chose ?
>
>> et aussi les valeurs d'insertion automatique dans le fichier
>> postgresql.conf
>
> Je ne sais pas de quoi il s'agit et ne trouve pas de doc...

Que disent les logs (ou l'Observateur d’Événements du système Windows)
par rapport aux services qui disparaissent ?

Flavio Gurgel

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Dans la partie système, je n'ai que ça :
"Le service postgresql-x64-9.3 - PostgreSQL Server 9.3 est entré dans
l'état : arrêté."
Rien ailleurs...

Y-a-t-il moyen de décoder les xlogs par exemple pour retrouver les
requêtes des "dernières minutes avant plantage" ?

Le 09/01/2015 16:13, Flavio Henrique Araque Gurgel a écrit :
>> Le 09/01/2015 15:32, Bruno Friedmann a écrit :
>>> On Friday 09 January 2015 15.22:44 Thomas RAFFIN wrote:
>>>> Bonjour,
>>>>
>>>> Sur un de nos serveurs nous avons un postgreSQL qui plante
>>>> régulièrement, et nous n'arrivons pas à en trouver le cause.
>>>>
>>>> Parfois il reste des processus postgres.exe qui tournent alors que le
>>>> service a planté. Dans ce cas il faut les tuer manuellement pour
>>>> relancer le service...
>>>>
>>>> Quelques données :
>>>> - machine virtuelle
>>>> - OS : Windows 2008 SP2 64b
>>>> - postgreSQL : 9.3.5
>>>> - postgis : 2.1.4
>>>>
>>>> Les ressources CPU et RAM semble largement disponibles. Pour les accès
>>>> disque, je ne sais pas, mais l'hébergeur me dis que tout va bien.
>>>>
>>>> Avez-vous des idées svp ?
>>>>
>>>> Merci
>>>>
>>>> Thomas
>>> Une database contenant une extension non alignée avec la version du
>>> serveur
>>> qui provoquerait un segfault ?
>> J'ai ces extensions :
>> - plpgsql en 1.0
>> - postgis en 2.1.4
>> - postgis_topology 2.1.4 aussi
>>
>> Les postgis* sont bien indiquées comme compatibles.
>>
>>> re-vérifier les modules,
>>
>> C'est les extensions ou autres chose ?
>>
>>> et aussi les valeurs d'insertion automatique dans le fichier
>>> postgresql.conf
>>
>> Je ne sais pas de quoi il s'agit et ne trouve pas de doc...
>
> Que disent les logs (ou l'Observateur d’Événements du système Windows)
> par rapport aux services qui disparaissent ?
>
> Flavio Gurgel
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>
>

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

2015-01-10 1:24 GMT+09:00 Thomas RAFFIN <traffin(at)sirap(dot)fr>:
> Y-a-t-il moyen de décoder les xlogs par exemple pour retrouver les requêtes
> des "dernières minutes avant plantage" ?
Utiliser pg_xlogdump ou xlogdump donne une idée des blocks et des
tables modifiées mais ne fournit pas d'information sur les requêtes
exactes, le meilleur moyen restant d'avoir des logs suffisants dans
pg_log...
--
Michael

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Le 10/01/2015 13:41, Michael Paquier a écrit :
> 2015-01-10 1:24 GMT+09:00 Thomas RAFFIN <traffin(at)sirap(dot)fr>:
>> Y-a-t-il moyen de décoder les xlogs par exemple pour retrouver les requêtes
>> des "dernières minutes avant plantage" ?
> Utiliser pg_xlogdump ou xlogdump donne une idée des blocks et des
> tables modifiées mais ne fournit pas d'information sur les requêtes
> exactes,

En fait la doc n'est pas très fournie... Et mon moteur de recherche
favori ne m'aide pas beaucoup...

> le meilleur moyen restant d'avoir des logs suffisants dans
> pg_log...

Vous me conseillez de loguer quoi (et comment) ?

Je ne peux pas mettre toutes les requêtes, ni même les connexions. Si je
mets les requêtes selon le temps d'éxécution, ça ne logue qu'une fois
qu'elles sont terminées...

> --
> Michael
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>
>

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Bonjour

> Sur un de nos serveurs nous avons un postgreSQL qui plante
> régulièrement, et nous n'arrivons pas à en trouver le cause.

Mon collègue Craig Ringer a ajouté du code dans PostgreSQL pour
faciliter l'audit de ce genre d'incident.

Sur windows il faut:

1. créer un dossier "crashdumps" dans le dossier des données de
PostgreSQL («SHOW data_directory;»)
2. Donner tous les droits à l'utilisateur postgres (ou l'utilisateur
système utilisé pour gérer PostgreSQL) dans les propriétés du dossier
3. Consulter ce dossier pour y trouver des mini dumps windows en cas de
plantage.
4. analyse avec Visual Studio ou windbg. (l'analyse peut se faire sur
une autre machine, le dump peut être exporté)

Voir le fichier src / backend / port / win32 / crashdump.c pour des
détails.

> Parfois il reste des processus postgres.exe qui tournent alors que le
> service a planté. Dans ce cas il faut les tuer manuellement pour
> relancer le service...

Il est intéressant de savoir quels processus restent en activité, et
comment ils sont 'tués'.

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation