PostgreSQL 8.2, NetBSD 4.0 et 'too many open pipes'
13 réponses
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.
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.
Vincent
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
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 !)
(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 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.
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.
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
In fr.comp.os.bsd JKB wrote:
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 --
In fr.comp.os.bsd JKB <knatschke@koenigsberg.fr> wrote:
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 <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
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 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 wrote:
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.
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 <knatschke@koenigsberg.fr> wrote:
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.
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 wrote:
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
JKB wrote:
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 <knatschke@koenigsberg.fr> wrote:
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 <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
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 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 wrote:
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.
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 <knatschke@koenigsberg.fr> wrote:
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.
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 wrote:
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
JKB wrote:
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 --
JKB <knatschke@koenigsberg.fr> wrote:
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 <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
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
[ ]
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.
[ ]
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.
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 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.
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.
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.
