PostgreSQL
La base de données la plus sophistiquée au monde.

Ouverture de session

Navigation

Contactez-nous

Administration du site :
"equipe chez postgresqlfr point org"

Contact presse :
"fr chez postgresql point org"

Contact association :
"bureau chez postgresqlfr point org"

Questions PostgreSQL :
 IRC :
  serveur irc.freenode.net
  canal #postgresqlfr

Recherche

Accéder aux archives

« Octobre 2008  
Lun Mar Mer Jeu Ven Sam Dim
  2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  

Syndication

Flux XML

Sondage

Quelle est la version de PostgreSQL la plus répandue sur vos serveurs ?
8.3
10%
8.2
42%
8.1
40%
8.0
2%
7.4
6%
7.3 ou antérieure
0%
Nombre de votes: 48

Pb connection à une base de données : enregistrements lockés??

Technique - général | Pb connection à une base de données : enregistrements lockés??

Par moneyboss le 03/04/2006 - 19:09

Bonjour,

Je rencontre des pb similaires à p.muck qui a posté un sujet au sujet d'enregistrements lockés.

Configuration serveur SGBD : serveur Red Hat ( noyau 2.4.18-14 ) Postgres 7.2.2

J'ai 5 postes clients qui viennent enregistrer des évènements dans 3 tables de la base de ce serveur.

Par rapport à cette configuration, je rencontre 2 pbs majeurs :

1> Le phénomène a commencé il y a un an et demi peut de temps après la mise en service de l'installation . J'ai remarqué lorsque l' 1 des tables contenaient à peu
près 1 millions d'enregistrements, s'il y avait un flux d'informations plus important que d'habitude ( suite à une relance d'un des 5 postes par ex ), le poste client ne pouvait plus enregistrer dans cette table ( messages d'erreurs inconnus par le pilote JDBC voir timeout ). En faisant un top sur le serveur, il y avait un nombre trop important de taches postmaster ( entre 15 et 20 ). Le seul moyen que j'avais trouvé à l'époque pour que le poste client puisse enregister à nouveau dans la table était de supprimer un grd nombre d'enregistrements de la table ( et de les sauvegarder dans une autre ) puis de relancer le service postgres. Si la table était de taille raisonnable ( < 600 000 ) je n'avais aucun pb lors de relance de mes postes. Pourant j'ai relancé ces 5 machines pendant 4 mois tous les 15 jours.

2> Mon 2ème pb arrive seulement maintenant. Suite à une mise à jour de mon application , j'ai relancé mes 5 postes clients. Malgré que la taille de ma table soit très raisonnable ( 500 000 enregistrements ), toutes mes machines ne peuvent plus enregistrées. Mon serveur est à fond ( entre 15 et 20 taches postmaster ). La seule chose qui est changée depuis un an et demi c'est la taille de ma base. En effet, j'aavais initialement 3 tables qui devaient conserver des données pendant 3 mois. Suite au pb précédemment évoqué, chaque mois on a supprimé les données de la table qui est très importante pour la remettre dans une autre table. Ce qui fait qu'aujourd'hui je me retrouve dans ma base avec 2 tables contenant à peine 10 enregistrements et entre 15 et 20 tables de 500 000 enregistrements. Et je pense que c'est de là que vient mon pb.

Par rapport à ces 2 anomalies constatés, je sollicite votre aide pour m'aider à diagnostiquer et corriger la ou les erreurs :

- Est-ce un pb de capcaité de table de postgres ou autre ?
- Est-ce un pb de lock sur la table et comment puis je le savoir ?
- Est-ce mon applicatif qui ferme mal ses connections avec postgres?

Merci d'avance pour votre aide

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.

Bonsoir Avez vous modfier

Christophe Chauvet/ = 5 Avril, 2006 - 21:05

Bonsoir

Avez vous modfier la configuration de PostgreSQL ou du kernel ?

Est-ce un pb de capcaité de table de postgres ou autre ?

Je ne pense pas

- Est-ce un pb de lock sur la table et comment puis je le savoir ?

Peut être mais visiblement il n'est pas déclenché par votre applicatif.

- Est-ce mon applicatif qui ferme mal ses connections avec postgres?

un ps devrait vous indiquer le nombre de connection effectué, regardez également avec netstat.

Autre question, est ce que des VACUUM sont éffectués? si oui à quel fréquence.

Cordialement.

Christophe Chauvet
http://kryskool.org/


Bonsoir, Merci de vous pen

moneyboss/ = 5 Avril, 2006 - 21:25

Bonsoir,

Merci de vous pencher sur mon problème.

Je n'ai effectué de modif de configuration de postgres ou du kernel. J'ai juste moidifier la variable tcp-ip dans le fichier de conf.

Je n'ai jamais effectuer un ps lorsque j'ai ce type de pb. Je l'ai fait en temps normal et je constate que postgres relache certains process quand il le veut. Normalement on devrait voir un process par poste qui émet une requete et celui-ci devrait disparaitre juste apres. Ce n'est pas tout le temps le cas. On dirait qu'il garde un process permanent avec chaque poste.Est-ce lié au driber jdbc ??

Un VACUUM est effectué chaque debut de mois lorsque je suprrime les données du mois précédent.

Merci d'avance

Cordialement


Bonsoir, fais-tu régulièrem

sparky/ = 6 Avril, 2006 - 21:09

Bonsoir, fais-tu régulièrement fonctionner le pg_vacuum ??? Si tu as assez de place disque, tu pourrais installer une nouvelle version de Postgresql, changer dans un autre répertoire et avec un port. Puis faire
la migration avec :
/vers_version7/pg_dump |/vers_version8/pg_restore (il manque les options), arrêter la version 7, changer le port de la 8 et la tester.

Sinon tu as des vues comme pg_xxxx qui te permettent de voir ce qui se passe


Bonjour, J'effectue comme

moneyboss/ = 7 Avril, 2006 - 10:42

Bonjour,

J'effectue comme je l'ai dit auparavant un VACUUM chaque début de mois après suppression des données. Je pense que cette commande est la même que pg_vacuum.

Je ne sais pas si la migration en version 8 arrangerait mon pb Tout d'abord il faudrait que je migre mon os red hat, que je m'assure qu'ensuite mon ancienne ppli fonctionne bien. Il faut que j'installe ensuite postgresql 8. et que je fasse des tests de non regression pour voir si la nouvelle version du driver jdc est compatible.Si c'est réellement nécessaire je le ferai mais comme je l'ai dit dans mon post d'origine, la personne nommée p.muck a posté un pb similaire au mien alors qu'il était en version 8.x

Sinon pour les tables système pg_XXX, c'est un peu vague ce que tu me dits. Il faudrait que je me retrouve de nouveau en situation de blocage, ou que je le repoduise sur ma plateforme d'essai, et que je regarde ensuite des données précises pour identifier le pb excat. C'es pour cette raison que je poste un message afin que l'on me dise qu'est ce que je dois exactement regarder comme infos précises.
Je sais que la table pg_stat_activity est utile pour savoir le nombre de connexion à la base il y a en cours mais ceci reste encore un peu trop léger à mon gout pour résoudre mon pb.

Voilà pour le moment. je suis à votre écoute pour toute manip à tester.

Merci d'avance et bonne journée.

PS : quelqu'un connaît un moyen simple et rapide surtout, pour insérer un très grd nombre de données dans une table


Bonjour, En réponse au p

SAS/ = 7 Avril, 2006 - 17:45

Bonjour,

En réponse au ps, avez-vous jeté un oeil du côté de COPY ?

Stéphane Schildknecht


Bonjour, Merci pour la com

moneyboss/ = 10 Avril, 2006 - 13:37

Bonjour,

Merci pour la commande, je la connaissais déjà mais je ne me souvenais plus de son utilité.

Il ne me reste plus qu'à générer automatiquement un fichier contenant un certain nombre d'évènements et de le faire restaurer dans la table.

Merci


Il n'est pas utile de migrer

sparky/ = 7 Avril, 2006 - 22:12

Il n'est pas utile de migrer l' OS pour installer une version 8.1 de postgresql : si les RPMS ne fonctionnent pas, reprends le tarball et compile-le puis installe le de manière bien séparée. (exemple ./configure && make --prefix=/usr/local/psql81 && make install)

Mes explications sont un peu vagues mais la documentation l'est moins ;-)
http://docs.postgresqlfr.org/pgsql-7.4.12-fr/monitoring.html


Bonjour, Etant donné que

moneyboss/ = 10 Avril, 2006 - 13:49

Bonjour,

Etant donné que je suis un simple utilisateur linux avec tres peu d'experience, je pensais qu'il était impératif de migrer l'OS pour installer.

Est-il cependant indispensable de l'installer dans un autre répertoire?

Concernant la surveillance de postgres, j'ai déjà testé la table pg_stat_activity au travers d'un script posté ici par une personne. J'ai aussi affiché simplement la liste des process postgres, mais tout ceci en fonctionnement normal.

Il faudrait que je reproduise mon pb en insérant sur ma plateforme plus d'1 million d'enregistrement.

Je posterai alors les résultats trouvés afin que vous puissiez m'apporter votre aide.

Bonne journée.


Bonjour

Christophe Chauvet/ = 10 Avril, 2006 - 16:17

Bonjour

Il n'est peu être pas nécessaire d'installer une version plus recente de PG, mais par contre il va être necessaire d'affiner les réglages du postgresql.conf ainsi que les paramètre du noyau système.

pour cela il nous faudrait quelques infos supplémentaires :

Matérielle
Processeur (nombre et type)
RAM
Disque (taille, (RAID 0, 1, 5) ?)

Software
Version du kernel (uname -r)
Les SHMMAX (cat /proc/sys/kernel/shmmax)
Les SHMALL (cat /proc/sys/kernel/shmall)

Ainsi que le nombre de connexions simultanées.

Le serveur est t'il dedié a PostgreSQL ?

Cordialement.

Christophe Chauvet
http://kryskool.org/


Bonjour, Voici les informa

moneyboss/ = 11 Avril, 2006 - 13:11

Bonjour,

Voici les informations que vous m'avez demandées :

Matérielle :
HP Proliant ML350 G2 début année 2003, processeur i686
1 Go de RAm
4 disques durs SCSI Hot Swapable 36 Go en raid 5 matériel ( carte smartarray 5i/532 )

Software
Linux Red Hat 8 noyau 2.4.18-14
SHMMAX : 33554432
SHMALL : 2097152

Le nombre de connexion simultanées dans postgresql est de 32, je pense car ma ligne est commentée. Par ailleurs, toutes les lignes de ce fichier sont commentées, exceptées celle de tcp_ip qui est à true

Ce serveur sert :
* serveur SGBD :
- 5 serveurs applicatifs qui enregistrent des evts survenant sur le site
- 3 postes clients qui à l'occasion consultent l'historique au travers 1/= à 2 requêtes

* serveur web applicatif :
au démarrage des serveurs, ceux-ci rapatrient des données. De la même façon, les serveurs sauvegardent quelques fichiers sur cette machine le soir

De manière générale, le taux d'occupation processeur de la machine est de 5% environ

Bonne journée


Bonjour, J'ai effectué qu

moneyboss/ = 12 Avril, 2006 - 17:02

Bonjour,

J'ai effectué quelques tests aujourd'hui.
J'ai ajouté 1200000 enregistrements dans ma table des évènements. Mon serveur SGBD se trouvait alors en bon fonctionnement ( CPU peu utilisée, aucun pb d'archivage de mes serveurs applicatifs ... ).
J'ai alors relancé le serveur applicatif d'adresse Ip 192.192.1.12. j'ai constaté alors qu'il connaissait des pbs d'archivage avec le SGBD ( pas de réponse au bout 30s suite à une requête ).
En faisant un top sur le SGBD, j'ai constaté qu'il y avait une tâche postmaster qui durait environ 35s ( compteur linux ). Cette tâche disparaissait en suite puis revenait 2/3 secondes après. J'ai effectué ensuite la commande "ps auxww | grep ^postgres" qui affichait les lignes suivantes :

postgres 743 0.0 0.1 10112 1732 ? S Apr11 0:00 /usr/bin/postmaster -i
postgres 745 0.0 0.1 10904 1504 ? S Apr11 0:00 postgres: stats buffer process
postgres 746 0.0 0.1 9952 1580 ? S Apr11 0:00 postgres: stats collector process
postgres 13974 0.0 0.1 4172 1432 pts/0 S 09:54 0:00 -bash
postgres 14912 0.0 0.1 4172 1424 pts/1 S 10:34 0:00 -bash
postgres 15582 0.0 0.1 5832 1708 pts/1 S 11:38 0:00 psql HISTO
postgres 15583 1.3 0.2 10536 3356 ? S 11:38 0:13 postgres: postgres HISTO [local] idle
postgres 15695 0.3 0.2 10540 3416 ? S 11:48 0:01 postgres: intravision HISTO 192.192.137.137 idle
postgres 15696 0.2 0.2 10536 3408 ? S 11:48 0:00 postgres: intravision HISTO 192.192.137.136 idle
postgres 15805 0.4 0.2 10544 3396 ? S 11:52 0:00 postgres: intravision HISTO 192.192.1.15 idle
postgres 15808 1.3 0.2 10544 3412 ? S 11:52 0:01 postgres: intravision HISTO 192.192.1.14 idle
postgres 15810 0.3 0.2 10544 3396 ? S 11:52 0:00 postgres: intravision HISTO 192.192.1.13 idle
postgres 15819 46.8 0.2 10804 3476 ? R 11:52 0:47 postgres: intravision HISTO 192.192.1.12 SELECT
postgres 15854 39.3 0.2 10536 3344 ? R 11:53 0:12 postgres: intravision HISTO 192.192.1.12 SELECT

J'ai laissé tourné ensuite 3 heures sans rien faire et j'avais toujours le même problème.

D'après moi, je me situais au prémice du pb que je cite depuis le début.

J'ai ajouté après de nouveau 1200000 enregistrements et j'ai constaté alors une dizaine de tâches postmaster en faisant un top, ce qui occupaient 90% de la CPU.
Voici le résultat de la commande avec ps :

postgres 743 0.0 0.1 10112 1732 ? S Apr11 0:00 /usr/bin/postmaster -i
postgres 745 0.0 0.1 10904 1516 ? S Apr11 0:00 postgres: stats buffer process
postgres 746 0.0 0.1 9960 1588 ? S Apr11 0:00 postgres: stats collector process
postgres 13974 0.0 0.1 4172 1432 pts/0 S 09:54 0:00 -bash
postgres 14912 0.0 0.1 4172 1424 pts/1 S 10:34 0:00 -bash
postgres 15582 0.0 0.1 5832 1708 pts/1 S 11:38 0:00 psql HISTO
postgres 15583 0.1 0.2 10544 3408 ? S 11:38 0:20 postgres: postgres HISTO [local] idle
postgres 18122 8.7 0.2 10536 3348 ? R 15:51 1:05 postgres: intravision HISTO 192.192.1.12 SELECT
postgres 18128 7.9 0.2 10536 3352 ? R 15:52 0:54 postgres: intravision HISTO 192.192.1.12 SELECT
postgres 18136 7.8 0.2 10536 3344 ? R 15:53 0:49 postgres: intravision HISTO 192.192.1.12 SELECT
postgres 18144 8.3 0.2 10536 3352 ? R 15:54 0:47 postgres: intravision HISTO 192.192.1.12 SELECT
postgres 18170 7.9 0.2 10536 3344 ? R 15:55 0:40 postgres: intravision HISTO 192.192.1.12 SELECT
postgres 18179 7.9 0.2 10536 3352 ? R 15:56 0:35 postgres: intravision HISTO 192.192.1.12 SELECT
postgres 18188 7.3 0.2 10536 3352 ? R 15:57 0:28 postgres: intravision HISTO 192.192.1.12 SELECT
postgres 18195 7.2 0.2 10536 3352 ? R 15:58 0:23 postgres: intravision HISTO 192.192.1.12 SELECT
postgres 18203 6.3 0.2 10536 3352 ? R 15:59 0:17 postgres: intravision HISTO 192.192.1.12 SELECT
postgres 18210 8.0 0.2 10536 3352 ? R 16:00 0:16 postgres: intravision HISTO 192.192.1.12 SELECT
postgres 18220 9.6 0.2 10536 3348 ? R 16:01 0:14 postgres: intravision HISTO 192.192.1.12 SELECT
postgres 18229 10.2 0.2 10536 3348 ? R 16:02 0:08 postgres: intravision HISTO 192.192.1.12 SELECT
postgres 18237 16.4 0.2 10536 3328 ? R 16:03 0:04 postgres: intravision HISTO 192.192.1.12 SELECT

J'ai laissé le serveur dans l'état actuel au cas où vous auriez des manips à me faire exécuter.

Par rapport aux résultats, j'ai quelque chose qui me chagrine. Si j'ai bien compris le principe des connexions à la base, je ne devrais trouvé qu'une seule ligne d'adresse 192.192.1.12 qui correspond à la connexion établie entre mon serveur SGBD et mon serveur applicatif, via le driver JDBC. Cette ligne devrait être permanente tant que le driver ne ferme pas la connexion et être à l'état "idle" la plupart du temps, lorsqu'il n'y a pas de requête de la part du serveur.
Or d'après le résultat du test 1, je constate que cette ligne disparaît 2/3 secondes, ce qui impliquerait une fermeture de la connexion de la part de mon serveur applicatif. Ceci me semble étrange mais ne me gêne pas encore de trop ( a voir dans le code ).

Par contre, je ne m'explique pas pourquoi dans le 2ème test je me retrouve avec une dizaine de connexions postgres à l'état SELECT.

Quelqu'un peut-il m'expliquer ce qu'il se produit exactement? Postgres ne serait-il pas en train d'essayer de traiter plusieurs fois la même requête?

Merci d'avance pour votre aide


Bonjour, Y-a-t-il quelqu'u

moneyboss/ = 20 Avril, 2006 - 07:57

Bonjour,

Y-a-t-il quelqu'un pour m'aider , je me désespère ????


Bonjour

Christophe Chauvet/ = 20 Avril, 2006 - 16:44

Bonjour

J'ai l'impression que votre applicatif lance ses requetes en paralelle, en ouvrant plusieur connection simultanée.

Quel version du driver JDBC utilisé, j'ai trouvé quelque message en rapport avec un problème similaire en JDBC, mais aussi la façon d'implémenté les requêtes

Essayé éventuellement de replacer le driver JDBC de la 7.2 par le dernier disponible http://jdbc.postgresql.org/download.html#jdbcselection

Cordialement.

Christophe Chauvet
http://kryskool.org/


© PostgreSQLFr, tous droits réservés.
Site déclaré à la CNIL sous le numéro 1074678, conformément à la Loi en vigueur.