PostgreSQL 8.2, NetBSD 4.0 et 'too many open pipes'
1 réponse
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 :
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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
JKB
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 :
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.
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 :
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.
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 :
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.
