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
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
JKB
Le #21897651
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.
Publicité
Poster une réponse
Anonyme