Paramètrage et démarrage de l'autovacuum

mortimer.pw · 08/12/2009 12:57:21

Bonjour,

Je travaille avec une base 8.1 sous Red-Hat 4.

Je ne vois pas l'autovacuum dans les fichiers de log.
Je ne vois pas les process "stats buffer process" et "stats collector process" non plus.

Les paramètres du fichier postgresql.conf sont :
stats_start_collector = true
stats_command_string = true
stats_block_level = true
stats_row_level = true

autovacuum = true
autovacuum_naptime = 600
autovacuum_vacuum_threshold = 1000
autovacuum_analyze_threshold = 500
autovacuum_vacuum_scale_factor = 0.4
autovacuum_analyze_scale_factor = 0.2
autovacuum_vacuum_cost_delay = -1
autovacuum_vacuum_cost_limit = -1

Quelqu'un peut-il m'aider ?

gleu · 08/12/2009 13:05:45

« stats buffer process » n'existe pas (et n'a jamais existé à ma connaissance). « stats collector process » est peut-être nommé autrement en 8.1 qui est une très vieille version.

mortimer.pw · 08/12/2009 13:16:18

Bonjour Guillaume,
Merci pour la réponse.
Je vois pourtant ces 2 process tourner sur une autre machine en 8.1.

mortimer.pw · 08/12/2009 13:42:53

Guillaume,

Je viens de trouver cela dans le fichier de log du jour du dernier reboot de la machine :

2009-11-24 12:01:14 CSTFATAL: terminating connection due to administrator command
2009-11-24 12:01:14 CSTLOG: received smart shutdown request
2009-11-24 12:01:14 CSTLOG: shutting down
2009-11-24 12:01:14 CSTLOG: database system is shut down
2009-11-24 12:01:15 CSTLOG: logger shutting down
2009-11-24 12:32:33 CSTLOG: could not connect socket for statistics collector: Le rÃ©seau n'est pas accessible.
2009-11-24 12:32:33 CSTLOG: disabling statistics collector for lack of working socket
2009-11-24 12:32:33 CSTLOG: database system was shut down at 2009-11-24 12:01:14 CST
2009-11-24 12:32:33 CSTLOG: checkpoint record is at 61/A7749448
2009-11-24 12:32:33 CSTLOG: redo record is at 61/A7749448; undo record is at 0/0; shutdown TRUE
2009-11-24 12:32:33 CSTLOG: next transaction ID: 34170859; next OID: 25315878
2009-11-24 12:32:33 CSTLOG: next MultiXactId: 1556; next MultiXactOffset: 3346
2009-11-24 12:32:33 CSTLOG: database system is ready
2009-11-24 12:32:33 CSTLOG: transaction ID wrap limit is 1107833619, limited by database "postgres"

Cela peut-il aider ?

gleu · 08/12/2009 14:08:07

Le collecteur de stats discute avec les autres processus via une connexion UDP. Donc, quelques vérifications à faire : SELinux installé ? autre firewall installé ? localhost disponible ? (que dit un ping localhost par exemple)

mortimer.pw · 09/12/2009 08:54:00

Bonjour Guillaume,

La commande ping localhost me retourne :
[postgres@jips ~]$ ping localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl=64 time=0.030 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.015 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=0.013 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=4 ttl=64 time=0.014 ms
--- localhost.localdomain ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.013/0.017/0.030/0.007 ms, pipe 2

L'équipe système m'assure que SELinux n'est pas installé, ni un autre Firewall et que la configuration réseau est correcte.

Aurais-tu d'autres pistes ?

Merci.

mortimer.pw · 09/12/2009 09:32:34

Guillaume,

Sur la machine où ça ne marche pas : White Box Enterprise Linux release 4 (manifestdestiny)
Sur une autre machine où cela fonctionne : Red Hat Enterprise Linux AS release 4 (Nahant)

Si cela peut aider au diagnostic.

Marc Cousin · 09/12/2009 09:46:31

C'est assez surprenant : le code récupère l'adresse localhost, crée une socket UDP en écoute dessus, puis essaye de s'y connecter. C'est cette dernière étape uniquement qui échoue sur ton serveur. À part une règle l'interdisant sur le système, je ne vois pas ce qui pourrait déclencher ça.
Et les règles pouvant l'interdire, sur une Red Hat, c'est SELinux ou une règle de firewall a priori.
Je pense qu'il faut insister auprès des admins système pour qu'ils vérifient tout ça.

J'ai extrait le code qui pose pb :

#include <unistd.h>
#include <fcntl.h>
#include <sys/param.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <netdb.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <signal.h>
#include <time.h>
#define closesocket close
#define TESTBYTEVAL ((char) 199)
int pgStatSock = -1;
static struct sockaddr_storage pgStatAddr;

int
pg_getaddrinfo_all(const char *hostname, const char *servname,
const struct addrinfo * hintp, struct addrinfo ** result)
{
int rc;

/* not all versions of getaddrinfo() zero *result on failure */
*result = NULL;

/* NULL has special meaning to getaddrinfo(). */
rc = getaddrinfo((!hostname || hostname[0] == '\0') ? NULL : hostname,
servname, hintp, result);

return rc;
}

int main(void)
{
int ret,alen;
int tries=0;
struct addrinfo *addrs = NULL,
*addr,
hints;
char test_byte;

hints.ai_flags = AI_PASSIVE;
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM;
hints.ai_protocol = 0;
hints.ai_addrlen = 0;
hints.ai_addr = NULL;
hints.ai_canonname = NULL;
hints.ai_next = NULL;

ret = pg_getaddrinfo_all("localhost", NULL, &hints, &addrs);
if (ret || !addrs)
{
printf("could not resolve \"localhost\": %s\n",
gai_strerror(ret));
exit(1);
}
for (addr = addrs; addr; addr = addr->ai_next)
{
/* Ignore AF_UNIX sockets, if any are returned. */
if (addr->ai_family == AF_UNIX)
continue;

if (++tries > 1)

printf("trying another address for the statistics collector\n");

/*
* Create the socket.
*/
if ((pgStatSock = socket(addr->ai_family, SOCK_DGRAM, 0)) < 0)
{
printf("could not create socket for statistics collector\n");
continue;
}

/*
* Bind it to a kernel assigned port on localhost and get the assigned
* port via getsockname().
*/
if (bind(pgStatSock, addr->ai_addr, addr->ai_addrlen) < 0)
{
printf("could not bind socket for statistics collector\n");
closesocket(pgStatSock);
pgStatSock = -1;
continue;
}

alen = sizeof(pgStatAddr);
if (getsockname(pgStatSock, (struct sockaddr *) & pgStatAddr, &alen) < 0)
{
printf("could not get address of socket for statistics collector\n");
closesocket(pgStatSock);
pgStatSock = -1;
continue;
}
/*
* Connect the socket to its own address. This saves a few cycles by
* not having to respecify the target address on every send. This also
* provides a kernel-level check that only packets from this same
* address will be received.
*/
if (connect(pgStatSock, (struct sockaddr *) & pgStatAddr, alen) < 0)
{
printf("could not connect socket for statistics collector\n");
closesocket(pgStatSock);
pgStatSock = -1;
continue;
}

/*
* Try to send and receive a one-byte test message on the socket. This
* is to catch situations where the socket can be created but will not
* actually pass data (for instance, because kernel packet filtering
* rules prevent it).
*/
test_byte = TESTBYTEVAL;

if (send(pgStatSock, &test_byte, 1, 0) != 1)
{
printf("could not send test message on socket for statistics collector\n");
closesocket(pgStatSock);
pgStatSock = -1;
continue;
}
}
}

Tu le mets dans un fichier C et tu le compiles avec gcc (gcc -o test mon_fichier.c)
Le programme devrait reproduire l'erreur. Si c'est bien le cas, tu devrais pouvoir t'en servir pour montrer aux admins système ce qui cloche.

mortimer.pw · 09/12/2009 12:37:12

Guillaume,

L'exécution du programme ne retourne rien, pas la moindre ligne de message.

gleu · 09/12/2009 12:56:01

Tu es bien sur la dernière version 8.1 de PostgreSQL ?

mortimer.pw · 09/12/2009 13:00:31

Guillaume,

[postgres@jips ~]$ psql my_bdd
Welcome to psql 8.1.2, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

gleu · 09/12/2009 13:06:59

La dernière version de la branche 8.1 est la 8.1.18. Il serait intéressant de travailler à partir de cette version, histoire de ne pas se creuser la tête sur un problème potentiellement déjà corrigé.

Cependant, j'ai du mal à croire que le problème vient de PostgreSQL. Le message indique clairement un problème d'accès réseau (« could not connect socket for statistics collector: Le rÃ©seau n'est pas accessible. »).

mortimer.pw · 09/12/2009 13:16:20

Guillaume,

Les bases sont en production.

Je suis en train de monter un serveur de test avec White Box 4 et PostgreSQL 8.1.2.

Si j'arrive au même résultat, j'installe 8.1.18
Je n'ai jamais fait de mise à jour, j'espère que cela est simple et rapide.

Je t'informe au plus vite.

Merci encore pour ton aide.

gleu · 09/12/2009 14:24:06

C'est simple et rapide, ça ne demande pas de sauvegarde. En gros, il faut arrêter le serveur PostgreSQL, mettre en place les nouveaux exécutables et relancer PostgreSQL. Au maximum dix minutes d'interruption.

mortimer.pw · 09/12/2009 16:34:03

Guillaume,

J'ai réinstallé un PostgreSQL 8.1.2 sur une machine White Box 4, l'autovacuum fonctionne.

Malheureusement l'OS est : White Box Enterprise Linux release 4 (Manifestdestiny Respin 2)

Y aurait-il une différence entre White Box Enterprise Linux release 4 (Manifestdestiny) et White Box Enterprise Linux release 4 (Manifestdestiny Respin 2) ?

L'équipe système ne peut plus me fournir une White Box 4 pas "Respin 2".

Je ne sais plus quoi tester.

Mon chef n'est pas trop chaud pour la mise à jour en live sur la production.

gleu · 09/12/2009 17:12:30

Y aurait-il une différence entre White Box Enterprise Linux release 4 (Manifestdestiny) et White Box Enterprise Linux release 4 (Manifestdestiny Respin 2) ?

C'est une question à poser sur un forum White Box. Je ne connaissais même pas cet distribution linux avant ce thread.

mortimer.pw · 09/12/2009 17:29:12

Guillaume,

J'ai de nouvelles infos.

Chaque dimanche, les tâches suivantes sont lancées :
vacuumdb -a -f -z
reindexdb -a
reindexdb -s

Dans le fichier de log, pour le vacuumdb, je vois ceci :
2009-12-06 08:05:02 CSTLOG: transaction ID wrap limit is 1108100205, limited by database "geo"
2009-12-06 08:05:02 CSTLOG: transaction ID wrap limit is 1108100205, limited by database "geo"
2009-12-06 08:05:02 CSTLOG: duration: 1263.598 ms statement: VACUUM FULL ANALYZE;

Idem pour les bases postgres et template1.

Pour le reindexdb, je ne vois rien pour la base geo, alors que je vois cela pour les 2 autres :
2009-12-06 09:31:38 CSTLOG: duration: 312.526 ms statement: SELECT datname FROM pg_database WHERE datallowconn;
2009-12-06 09:31:43 CSTLOG: duration: 5005.807 ms statement: REINDEX DATABASE postgres;

Lorsque je fais un \l sous psql, il m'affiche bien la liste des bases.

As-tu une explication pour cela ?
Est-ce lié au problème de l'autovacuum ?

mortimer.pw · 08/02/2010 09:27:23

Bonjour Guillaume,
J'ai arrêté et redémarré PostgreSQL aprés que la machine soit complétement démarrée.
Les 2 services stats_buffer et stats_collector sont démarrés.
C'est donc bien qu'il y a un problème avec le réseau.
J'ai demandé à l'équipe système de modifier l'ordre des démarrage des différents services.
A présent tout fonctionne bien.
Désolé pour le temps perdu.
Merci encore.

#1 08/12/2009 12:57:21

Paramètrage et démarrage de l'autovacuum

#2 08/12/2009 13:05:45

Re : Paramètrage et démarrage de l'autovacuum

#3 08/12/2009 13:16:18

Re : Paramètrage et démarrage de l'autovacuum

#4 08/12/2009 13:42:53

Re : Paramètrage et démarrage de l'autovacuum

#5 08/12/2009 14:08:07

Re : Paramètrage et démarrage de l'autovacuum

#6 09/12/2009 08:54:00

Re : Paramètrage et démarrage de l'autovacuum

#7 09/12/2009 09:32:34

Re : Paramètrage et démarrage de l'autovacuum

#8 09/12/2009 09:46:31

Re : Paramètrage et démarrage de l'autovacuum

#9 09/12/2009 12:37:12

Re : Paramètrage et démarrage de l'autovacuum

#10 09/12/2009 12:56:01

Re : Paramètrage et démarrage de l'autovacuum

#11 09/12/2009 13:00:31

Re : Paramètrage et démarrage de l'autovacuum

#12 09/12/2009 13:06:59

Re : Paramètrage et démarrage de l'autovacuum

#13 09/12/2009 13:16:20

Re : Paramètrage et démarrage de l'autovacuum

#14 09/12/2009 14:24:06

Re : Paramètrage et démarrage de l'autovacuum

#15 09/12/2009 16:34:03

Re : Paramètrage et démarrage de l'autovacuum

#16 09/12/2009 17:12:30

Re : Paramètrage et démarrage de l'autovacuum

#17 09/12/2009 17:29:12

Re : Paramètrage et démarrage de l'autovacuum

#18 08/02/2010 09:27:23

Re : Paramètrage et démarrage de l'autovacuum

Pied de page des forums

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux