ok je vais faire ceci mais c

ahlonko/ = 27 Mars, 2007 - 14:29

ok je vais faire ceci mais certainement ce soir quand il n'y aura personne de connecter. Je vous signale que l'autovaccum est activé depuis toujours . (je l'ai arrêté depuis ce week end pour observer le fonctionnement du serveur)

merci

j'aime bien librement, :)

Là sont les dernières ligne

ahlonko/ = 27 Mars, 2007 - 22:02

Là sont les dernières lignes du vaccum ...vous en pensez quoi ?

INFO: la carte des espaces libres contient 8152 pages dans 352 relations
DETAIL: Un total de 10560 emplacements de pages est utilisé (ceci incluant la surcharge).
10560 emplacements de pages sont requis pour tracer tout l'espace libre.
Les limites actuelles sont : 110000 emplacements de pages, 1000 relations, utilisant 709 Ko.

Merci

Après le "vacuum -fav -U pos

ahlonko/ = 28 Mars, 2007 - 00:20

Après le "vacuum -fav -U posgres" je relève dans le log les mêmes messages relatifs aux limite de réinitialisation comme suit:
LOG: La limite de réinitialisation de l'ID de transaction est 1138008674, limité par la base de données <>

Est ce méchant ? surtout qu'en ce moment il n'y pas d'activité sur le serveur.

Merci

help please ...

ahlonko/ = 28 Mars, 2007 - 16:14

help please ...

hum...

SAS/ = 28 Mars, 2007 - 19:25

Je pense que les deux problèmes ne sont pas liés.

Le redémarrage du serveur doit provenir d'un autre problème. Avez-vous autre chose dans les logs ?

Sinon, puisque le problème semble revenir de manière régulière, pourriez-vous activer les logs des requêtes de façon à trouver quelle requête pourrait être à l'origine de redémarrage ?

Librement,
Stéphane Schildknecht
dalibo
PostgreSQLFr

Merci pour votre aide Stépha

ahlonko/ = 29 Mars, 2007 - 07:28

Merci pour votre aide Stéphane , si je comprends bien j'ai deux problèmes! le redémarrage qui me préoccupe plus et le réinitialisation de l'ID de transaction (est ce un réel problème?) .
Une autre question SVP , est ce que vous pouvez me confirmer que le redémarrage par le postmaster peut être dû à une erreur de syntaxe dans une rêquete? parceque mes collègues ne semblent pas être de cet avis que j'ai déjà relevé.

Cordialement,

C'est possible

SAS/ = 29 Mars, 2007 - 12:18

Il est possible effectivement qu'une erreur de programmation entraîne un plantage du client, et donc un redémarrage du serveur.

Librement,
Stéphane Schildknecht
dalibo
PostgreSQLFr

Merci .

ahlonko/ = 29 Mars, 2007 - 12:20

Merci .

La mémoire qui ne se libère pas !!!!

ahlonko/ = 14 Avril, 2007 - 11:18

Bonjour ,
j'expérimente toujours des redémarrages du serveur postmaster , et la remarque faite est la variation de la mémoire(RAM) : Je m'explique, au début de la journée (9H)j'ai une utilisation de 400Mo utilisée sur 2 Go de RAM avec 0 connexion au serveur PG. A 11H (avec une centaine de connexions) je suis à 60 Mo de libre sur les 2Go. A 19H avec O connexion je suis toujours à 60Mo de libre. Pour récupérer la mémoire je redémarre la machine (en précisant que le redémarrage de PG , ne libère pas la mémoire). Je n'ai pas programmé l'application cliente mais les programmeurs m'ont signifié fermer les connexions ODBC quand l'utilisateur ferme son application. L'application cliente sous windows communique avec le serveur PG sous Linux(GNU Debian) par le biais d'établissement d'une connexion OBDC .
Merci pour vos lumières à venir
Ahlonko

bonjour pourriez vous inst

Christophe Chauvet/ = 14 Avril, 2007 - 12:57

bonjour

pourriez vous installer ce script coté serveur, et surveiller vers 19h si il reste des connexions au serveur, si vous regardez ce script vous aurez la requête qui est lancé si vous voulez vous faire un outils de monitoruing

Vu le nombre de connexions simultannées que vous avez, je vous conseillerais de regarder du coté de PgPool et aisni limiter le nombre de connexion directe à PostgreSQL et pouvoir mieux répartir les ressources.

Cordialement.

Christophe Chauvet
KrysKool.org

merci pour ces directives que

ahlonko/ = 14 Avril, 2007 - 13:35

merci pour ces directives que je vais suivre dès lundi.
cordialement,

Ahlonko

Bonsoir Christophe, Quand j'

ahlonko/ = 16 Avril, 2007 - 22:49

Bonsoir Christophe,
Quand j'ai regardé le script j'ai été un peu pessimiste bien soit un bon outil pour le monitoring de PG. Je l'ai néanmoins utilisé et cela n'a pas résolu mon problème de mémoires. Ce matin avec pgsession -l j'ai eu comme résultat 67 et il ne me restait 300 Mo de RAM sur 2Go . Ce soir avec la même commande le résultat fut 0 , et il ne me reste plus que 57Mo. Et il n'y pas de doute que l'utilisation première de la RAM soit liée à PG , mais je ne m'explique pas qu'après déconnexion de tous les utilisateurs , je ne récupère pas cette mémoire ...
Concernant PgPool l'outil semble intéressant mais je préfère ne pas le mettre en oeuvre pour l'heure pour cause que j'utilise déjà Slony pour la réplication et que je crains sa gourmandise en ressources , mon réel souci en ce moment...
Des outils pour voir au niveau du système la gestion qui est faite de la mémoire ???
Merci .

Cordialement,

Bonjour

Christophe Chauvet/ = 17 Avril, 2007 - 08:50

Bonjour

Quel version de la 8.1 utilisez vous ?

Sinon vous nous indiquez que même en redémarrant le service PostgreSQL il ne se passe rien, donc pourriez vous lancer un ipcclean, service à l'arret bien sûr, éventuellement faire un ipcs -m avant et comparez les résultats AVANT/APRES (voir même nous mettre le résultat ici).

Quand a PgPool il peut être placer sur une autre machine, qui ne contient pas forcement un PostgreSQL Server d'installer.

Cordialement.

Christophe Chauvet
KrysKool.org

psql (PostgreSQL) 8.1.8 cont

ahlonko/ = 19 Avril, 2007 - 07:50

psql (PostgreSQL) 8.1.8
contient le support pour l'édition de la ligne de commande

Avant Redémarrage du serveur

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x0052e2c1 0 postgres 600 72073216 2
0x00000000 32769 root 600 7296 4 dest

Après Redémarrage

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x0052e2c1 0 postgres 600 72073216 2
0x00000000 32769 root 600 7296 11 dest

Cordialement,

Ahlonko