PostgreSQL 8.2, NetBSD 4.0 et 'too many open pipes'

Le
JKB
Bonjour à tous,

Je reviens vers vous en raison d'un problème bizarre. J'utilise une
base de test sur une antique SS20 bipro (cartographie) sur laquelle
tourne un NetBSD 4.0 des familles. Une grosse application
d'optimisation tourne sur une machine distante et effectue des
requêtes sur cette brave SS20 à l'aide de la bibliothèque PQ. Cela
fonctionne (enfin fonctionne presque). Je m'entends, les requêtes
passent sans problème, mais ce matin après deux jours de calcul, mon
programme d'optimisation était dans l'état S (tous les threads).
Je pensais donc avoir écrit un truc foireux dans mon code. Sauf
qu'en essayant d'accéder à ma SS20, je me suis pris dans la figure
un "too many open pipes". Visiblement, NetBSD est resté coincé dans
une requête SQL, mais je ne vois pas trop pourquoi.

Requête :

select s.x1, s.y1, s.x2, s.y2, s.gid, s.length, s.time, s.source,
s.target from streets_base_edges as s, (select edge_id, step from
shortest_path('select gid::int4 as id, source::int4, target::int4,
time::float8 as cost, reverse_time::float8 as reverse_cost from
streets_base_edges', 75232, 54194, false, true)) as a where
a.edge_id=s.gid order by a.step

Si je lance cette requête à la main, ça fonctionne parfaitement.
Je subodore un problème du côté de NetBSD, mais je ne vois pas trop
lequel. À tout hasard, ma séquence d'instruction côté client est :

PQsetdbLogin()
PQstatus()
PQexec()
PQresultStatus()
PQnfields()
PQntuples()
PQgetisnull()
PQgetlength()
PQgetvalue()
PQclear()
PQfinish()

Je ne vois pas trop où un pipe pourrait rester ouvert de ce côté.
Je suis en train de compiler un lsof pour voir ce qui se passe de
façon plus fine côté NetBSD, mais j'ai un peu peur Cette machine
ne fait que répondre à ces requêtes. Elle ne fait strictement rien
d'autre.

Est-ce un problème connu ou ai-je raté quelque chose dans
l'utilisation de la libpq ? Je n'ai pas l'impression que le problème
se pose lorsque le serveur postgres tourne sous Linux.

Cordialement,

JKB

PS: XPost+FU2

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
JKB
Le #6397861
Le 24-04-2008, à propos de
PostgreSQL 8.2, NetBSD 4.0 et 'too many open pipes',
JKB écrivait dans fr.comp.applications.sgbd :
Bonjour à tous,

Je reviens vers vous en raison d'un problème bizarre. J'utilise une
base de test sur une antique SS20 bipro (cartographie) sur laquelle
tourne un NetBSD 4.0 des familles. Une grosse application
d'optimisation tourne sur une machine distante et effectue des
requêtes sur cette brave SS20 à l'aide de la bibliothèque PQ. Cela
fonctionne (enfin fonctionne presque). Je m'entends, les requêtes
passent sans problème, mais ce matin après deux jours de calcul, mon
programme d'optimisation était dans l'état S (tous les threads).
Je pensais donc avoir écrit un truc foireux dans mon code. Sauf
qu'en essayant d'accéder à ma SS20, je me suis pris dans la figure
un "too many open pipes". Visiblement, NetBSD est resté coincé dans
une requête SQL, mais je ne vois pas trop pourquoi.

Requête :

select s.x1, s.y1, s.x2, s.y2, s.gid, s.length, s.time, s.source,
s.target from streets_base_edges as s, (select edge_id, step from
shortest_path('select gid::int4 as id, source::int4, target::int4,
time::float8 as cost, reverse_time::float8 as reverse_cost from
streets_base_edges', 75232, 54194, false, true)) as a where
a.edge_id=s.gid order by a.step

Si je lance cette requête à la main, ça fonctionne parfaitement.
Je subodore un problème du côté de NetBSD, mais je ne vois pas trop
lequel. À tout hasard, ma séquence d'instruction côté client est :

PQsetdbLogin()
PQstatus()
PQexec()
PQresultStatus()
PQnfields()
PQntuples()
PQgetisnull()
PQgetlength()
PQgetvalue()
PQclear()
PQfinish()

Je ne vois pas trop où un pipe pourrait rester ouvert de ce côté.
Je suis en train de compiler un lsof pour voir ce qui se passe de
façon plus fine côté NetBSD, mais j'ai un peu peur... Cette machine
ne fait que répondre à ces requêtes. Elle ne fait strictement rien
d'autre.

Est-ce un problème connu ou ai-je raté quelque chose dans
l'utilisation de la libpq ? Je n'ai pas l'impression que le problème
se pose lorsque le serveur postgres tourne sous Linux.

Cordialement,

JKB

PS: XPost+FU2


Bon, on avance. un lsof | grep PIPE | wc en boucle ne donne rien
d'alarmant. J'ai une vingtaine de pipes et cela ne varie pas en
fonction du nombre de requêtes effectuées. En un sens, cela veut
dire que le fonctionnement de mon programme est sain, mais je ne
vois pas trop pourquoi postgres est parti en vacances sur un
problème de pipes...

JKB, qui sèche...

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Vincent
Le #6399731
Intéressant, de la carto sur NetBSD ?

(Désolé de ne pas pouvoir t'aider, j'ai installé une seule fois PostGres
pour pouvoir utiliser Grass, et je n'ai jamais réussi à obtenir une base
de test valable !)

Vincent
JKB
Le #6399721
Le 24-04-2008, à propos de
Re: PostgreSQL 8.2, NetBSD 4.0 et 'too many open pipes',
Vincent écrivait dans fr.comp.os.bsd :
Intéressant, de la carto sur NetBSD ?


Ouaips...

(Désolé de ne pas pouvoir t'aider, j'ai installé une seule fois PostGres
pour pouvoir utiliser Grass, et je n'ai jamais réussi à obtenir une base
de test valable !)


Postgres, ça fonctionne bien, mais les softs doivent intégrer des
tas de workarounds pour tourner autour des "trous" de netBSD pour
fonctionner, et ça, ce n'est pas gagné ! Je suis en train de pister
le nombre de pipes ouverts, et ça ne grandit pas en fonction du
nombre de requête, c'est même carrément stable. Alors pourquoi le
truc explose-t-il de temps en temps ? Mystère (et ce n'est pas un
cron qui est responsable de l'explosion...).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Manuel Bouyer
Le #6401271
In fr.comp.os.bsd JKB
Bonjour à tous,

Je reviens vers vous en raison d'un problème bizarre. J'utilise une
base de test sur une antique SS20 bipro (cartographie) sur laquelle
tourne un NetBSD 4.0 des familles. Une grosse application
d'optimisation tourne sur une machine distante et effectue des
requêtes sur cette brave SS20 à l'aide de la bibliothèque PQ. Cela
fonctionne (enfin fonctionne presque). Je m'entends, les requêtes
passent sans problème, mais ce matin après deux jours de calcul, mon
programme d'optimisation était dans l'état S (tous les threads).
Je pensais donc avoir écrit un truc foireux dans mon code. Sauf
qu'en essayant d'accéder à ma SS20, je me suis pris dans la figure
un "too many open pipes". Visiblement, NetBSD est resté coincé dans
une requête SQL, mais je ne vois pas trop pourquoi.


C'est quoi qui a renvoye ce message ? postgress, ou une autre appli ?
Je n'ai pas trouve ce message dans les errno standard, donc
je soupsonne que ce soit un message specifique a une appli. Et du coup,
le "pipe" n'est peut-etre pas le pipe au sens unix du terme.
Il faudrait chercher dans la doc pgsql voir s'ils parlent de ce genre de
chose. Il pourrait etre reste bloque sur un manque de ressource autre
(genre memoire partagee, semaphores, etc ...). Tiens je me demande si ca
ne serait pas les "message queues" des IPC system V qu'il apelle pipe.



select s.x1, s.y1, s.x2, s.y2, s.gid, s.length, s.time, s.source,
s.target from streets_base_edges as s, (select edge_id, step from
shortest_path('select gid::int4 as id, source::int4, target::int4,
time::float8 as cost, reverse_time::float8 as reverse_cost from
streets_base_edges', 75232, 54194, false, true)) as a where
a.edge_id=s.gid order by a.step


on fait des truc sun peu plus tordu en pgsql au boulot, sur une base qui
tourne sur un NetBSD 3.1.x i386.


--
Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference
--

JKB
Le #6401261
Le 24-04-2008, à propos de
Re: PostgreSQL 8.2, NetBSD 4.0 et 'too many open pipes',
Manuel Bouyer écrivait dans fr.comp.os.bsd :
In fr.comp.os.bsd JKB
Bonjour à tous,

Je reviens vers vous en raison d'un problème bizarre. J'utilise une
base de test sur une antique SS20 bipro (cartographie) sur laquelle
tourne un NetBSD 4.0 des familles. Une grosse application
d'optimisation tourne sur une machine distante et effectue des
requêtes sur cette brave SS20 à l'aide de la bibliothèque PQ. Cela
fonctionne (enfin fonctionne presque). Je m'entends, les requêtes
passent sans problème, mais ce matin après deux jours de calcul, mon
programme d'optimisation était dans l'état S (tous les threads).
Je pensais donc avoir écrit un truc foireux dans mon code. Sauf
qu'en essayant d'accéder à ma SS20, je me suis pris dans la figure
un "too many open pipes". Visiblement, NetBSD est resté coincé dans
une requête SQL, mais je ne vois pas trop pourquoi.


C'est quoi qui a renvoye ce message ? postgress, ou une autre appli ?
Je n'ai pas trouve ce message dans les errno standard, donc
je soupsonne que ce soit un message specifique a une appli. Et du coup,
le "pipe" n'est peut-etre pas le pipe au sens unix du terme.
Il faudrait chercher dans la doc pgsql voir s'ils parlent de ce genre de
chose. Il pourrait etre reste bloque sur un manque de ressource autre
(genre memoire partagee, semaphores, etc ...). Tiens je me demande si ca
ne serait pas les "message queues" des IPC system V qu'il apelle pipe.


postgres ne fait plus rien (état S ou D, je ne sais plus). Par
contre, je ne peux plus lancer un bête su - (qui me renvoie cette
erreur). N'importe quelle commande utilisant un pipe renvoie une
telle erreur (toutes les autres fonctionnent). N'ayant pas de shell
root, je n'ai rien pu faire sauf rebooter sauvagement la SS20.

select s.x1, s.y1, s.x2, s.y2, s.gid, s.length, s.time, s.source,
s.target from streets_base_edges as s, (select edge_id, step from
shortest_path('select gid::int4 as id, source::int4, target::int4,
time::float8 as cost, reverse_time::float8 as reverse_cost from
streets_base_edges', 75232, 54194, false, true)) as a where
a.edge_id=s.gid order by a.step


on fait des truc sun peu plus tordu en pgsql au boulot, sur une base qui
tourne sur un NetBSD 3.1.x i386.


Possible...

JKB, qui vient de se rabattre sur un linux/sparc pour cette base,
mais qui aimerais bien comprendre...

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.


Manuel Bouyer
Le #6401621
JKB
C'est quoi qui a renvoye ce message ? postgress, ou une autre appli ?
Je n'ai pas trouve ce message dans les errno standard, donc
je soupsonne que ce soit un message specifique a une appli. Et du coup,
le "pipe" n'est peut-etre pas le pipe au sens unix du terme.
Il faudrait chercher dans la doc pgsql voir s'ils parlent de ce genre de
chose. Il pourrait etre reste bloque sur un manque de ressource autre
(genre memoire partagee, semaphores, etc ...). Tiens je me demande si ca
ne serait pas les "message queues" des IPC system V qu'il apelle pipe.


postgres ne fait plus rien (état S ou D, je ne sais plus). Par
contre, je ne peux plus lancer un bête su - (qui me renvoie cette
erreur). N'importe quelle commande utilisant un pipe renvoie une


C'etait pas "too many open files" plutot, le message ?

Le nombre de fichiers max est trop bas sur certaines archis, effectivement.
Mais il suffit de remonter kern.maxfiles dans /etc/sysctl.conf :)
Il est a 3000 sur mon serveur pgsql.

--
Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference
--


JKB
Le #6401611
Le 24-04-2008, à propos de
Re: PostgreSQL 8.2, NetBSD 4.0 et 'too many open pipes',
Manuel Bouyer écrivait dans fr.comp.os.bsd :
JKB
C'est quoi qui a renvoye ce message ? postgress, ou une autre appli ?
Je n'ai pas trouve ce message dans les errno standard, donc
je soupsonne que ce soit un message specifique a une appli. Et du coup,
le "pipe" n'est peut-etre pas le pipe au sens unix du terme.
Il faudrait chercher dans la doc pgsql voir s'ils parlent de ce genre de
chose. Il pourrait etre reste bloque sur un manque de ressource autre
(genre memoire partagee, semaphores, etc ...). Tiens je me demande si ca
ne serait pas les "message queues" des IPC system V qu'il apelle pipe.


postgres ne fait plus rien (état S ou D, je ne sais plus). Par
contre, je ne peux plus lancer un bête su - (qui me renvoie cette
erreur). N'importe quelle commande utilisant un pipe renvoie une


C'etait pas "too many open files" plutot, le message ?


Non. Je pouvais ouvrir un fichier, mais pas un pipe.

Le nombre de fichiers max est trop bas sur certaines archis, effectivement.
Mais il suffit de remonter kern.maxfiles dans /etc/sysctl.conf :)
Il est a 3000 sur mon serveur pgsql.


Question subsidiaire ? La variation de ces variable est-elle prise
en compte dynamiquement ?

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.



Manuel Bouyer
Le #6401901
JKB
C'etait pas "too many open files" plutot, le message ?


Non. Je pouvais ouvrir un fichier, mais pas un pipe.


Alors je ne sais pas d'ou vient ce message. Je ne l'ai pas trouve dans
les sources (ni libc, ni kernel). Et je n'ai jamais vu ca, ca m'est arrive
souvent d'atteindre la limite des fichiers (qui inclu les pipes) mais pas un
truc specifique aux pipes. Il y a des limites dans sysctl kern.pipe, ca peut
peut-etre venir de la (s'il y a beaucoup de pipes qui ne sont pas lu, les
donnees s'accumulent dans le kernel et au bout d'un moment le kernel n'a plus
de memoire pour les pipes).

Le nombre de fichiers max est trop bas sur certaines archis, effectivement.
Mais il suffit de remonter kern.maxfiles dans /etc/sysctl.conf :)
Il est a 3000 sur mon serveur pgsql.


Question subsidiaire ? La variation de ces variable est-elle prise
en compte dynamiquement ?


Oui

--
Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference
--


Vincent
Le #6404511

[…]

Il y a aussi une option dans le kernel pour implémenter des pipes «
smaller but slower ». Essaie toujours ?

Vincent

PS : c'est quoi comme genre de carto ? Ça m'intéresserait bien pour un
reportage, tiens.
JKB
Le #6404881
Le 25-04-2008, à propos de
Re: PostgreSQL 8.2, NetBSD 4.0 et 'too many open pipes',
Vincent écrivait dans fr.comp.os.bsd :

[?]

Il y a aussi une option dans le kernel pour implémenter des pipes «
smaller but slower ». Essaie toujours ?

Vincent

PS : c'est quoi comme genre de carto ? Ça m'intéresserait bien pour un
reportage, tiens.


C'est la carographie complète de la France pour des optimisations de
tournées de voyageurs de commerce.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Publicité
Poster une réponse
Anonyme