Vous n'êtes pas identifié(e).
Pages : 1
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 ?
Hors ligne
« 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.
Guillaume.
Hors ligne
Bonjour Guillaume,
Merci pour la réponse.
Je vois pourtant ces 2 process tourner sur une autre machine en 8.1.
Hors ligne
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 ?
Hors ligne
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)
Guillaume.
Hors ligne
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.
Hors ligne
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.
Hors ligne
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.
Marc.
Hors ligne
Guillaume,
L'exécution du programme ne retourne rien, pas la moindre ligne de message.
Hors ligne
Tu es bien sur la dernière version 8.1 de PostgreSQL ?
Guillaume.
Hors ligne
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
Hors ligne
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. »).
Guillaume.
Hors ligne
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.
Hors ligne
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.
Guillaume.
Hors ligne
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.
Hors ligne
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.
Guillaume.
Hors ligne
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 ?
Hors ligne
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.
Hors ligne
Pages : 1
