PostgreSQL (erreur sur requête longue)

Le
JKB
Bonjour à tous,

Je suis en train de mettre au point des algorithmes de calcul
d'itinéraires qui tournent autour de PostGIS. J'ai réussi à
mouliner une région française sans problème. J'essaye maintenant de
faire la même chose sur la France entière et j'ai quelques
problèmes. J'ai écrit une moulinette d'intégration des données
(celle qui fonctionne parfaitement sur une région) qui s'arrête sur
la France après à peu près deux jours de calcul lors de la
transformation de la base en graphe :

PL/pgSQL function "create_graph_tables" line 11 at EXECUTE statement
psql:integration_finale.sql:101: INFO: CREATE TABLE / UNIQUE créera un
index implicite « streets_base_vertices_geom_id_key » pour la table «
streets_base_vertices »
CONTEXT: instruction SQL « CREATE TABLE streets_base_vertices (id
serial, geom_id int4 NOT NULL UNIQUE) »
PL/pgSQL function "create_graph_tables" line 11 at EXECUTE statement
psql:integration_finale.sql:101: INFO: CREATE TABLE créera des
séquences implicites « streets_base_edges_id_seq » pour la colonne
serial « streets_base_edges.id »
CONTEXT: instruction SQL « CREATE TABLE streets_base_edges (id serial,
source int, target int, cost float8, reverse_cost float8) »
PL/pgSQL function "create_graph_tables" line 15 at EXECUTE statement
Processus arrêté
rayleigh:[/opt/routing/scripts] > echo $?
137

Je n'arrive pas à trouver la signification du code d'erreur 137.
Dans les logs de PostgreSqL, j'ai ceci :

PL/pgSQL function "create_graph_tables" line 11 at EXECUTE
statement
2008-04-21 01:12:35 CEST INFO: CREATE TABLE créera des séquences
implicites « streets_base_edges_id_seq » pour la colonne serial «
streets_base_edges.id »
2008-04-21 01:12:35 CEST CONTEXTE : instruction SQL « CREATE TABLE
streets_base_edges (id serial, source int, target int, cost float8,
reverse_cost float8) »
PL/pgSQL function "create_graph_tables" line 15 at EXECUTE
statement
2008-04-21 05:02:04 CEST LOG: paquet de démarrage incomplet
2008-04-21 10:02:05 CEST LOG: paquet de démarrage incomplet
2008-04-21 15:02:07 CEST LOG: paquet de démarrage incomplet
2008-04-21 20:02:07 CEST LOG: paquet de démarrage incomplet
2008-04-22 00:02:04 CEST LOG: paquet de démarrage incomplet
2008-04-22 05:02:07 CEST LOG: paquet de démarrage incomplet

Je ne vois pas pourquoi la fonction en question s'arrête. Le
problème est reproductible et je ne sais plus où chercher pour
corriger le truc Je ne pense pas que le problème proviennent des
capacités du serveur (j'ai essayé sur une machine avec 2 Go de
mémoire, ça a planté au bout de 20 jours de calcul [long en raison
des accès disques SATA particulièrement lents], puis sur une Sparc
U60 avec 1 Go [disques en U320] qui donne le même résultat en moins de 48
heures).

Toute idée sera la bienvenue

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.
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
JB
Le #21897751
JKB a écrit:
Bonjour à tous,

Je suis en train de mettre au point des algorithmes de calcul
d'itinéraires qui tournent autour de PostGIS. J'ai réussi à
mouliner une région française sans problème. J'essaye maintenant de
faire la même chose sur la France entière et j'ai quelques
problèmes. J'ai écrit une moulinette d'intégration des données
(celle qui fonctionne parfaitement sur une région) qui s'arrête sur
la France après à peu près deux jours de calcul lors de la
transformation de la base en graphe :

PL/pgSQL function "create_graph_tables" line 11 at EXECUTE statement
psql:integration_finale.sql:101: INFO: CREATE TABLE / UNIQUE créera un
index implicite « streets_base_vertices_geom_id_key » pour la table «
streets_base_vertices »
CONTEXT: instruction SQL « CREATE TABLE streets_base_vertices (id
serial, geom_id int4 NOT NULL UNIQUE) »
PL/pgSQL function "create_graph_tables" line 11 at EXECUTE statement
psql:integration_finale.sql:101: INFO: CREATE TABLE créera des
séquences implicites « streets_base_edges_id_seq » pour la colonne
serial « streets_base_edges.id »
CONTEXT: instruction SQL « CREATE TABLE streets_base_edges (id serial,
source int, target int, cost float8, reverse_cost float8) »
PL/pgSQL function "create_graph_tables" line 15 at EXECUTE statement
Processus arrêté
rayleigh:[/opt/routing/scripts] > echo $?
137

Je n'arrive pas à trouver la signification du code d'erreur 137.
Dans les logs de PostgreSqL, j'ai ceci :

PL/pgSQL function "create_graph_tables" line 11 at EXECUTE
statement
2008-04-21 01:12:35 CEST INFO: CREATE TABLE créera des séquences
implicites « streets_base_edges_id_seq » pour la colonne serial «
streets_base_edges.id »
2008-04-21 01:12:35 CEST CONTEXTE : instruction SQL « CREATE TABLE
streets_base_edges (id serial, source int, target int, cost float8,
reverse_cost float8) »
PL/pgSQL function "create_graph_tables" line 15 at EXECUTE
statement
2008-04-21 05:02:04 CEST LOG: paquet de démarrage incomplet
2008-04-21 10:02:05 CEST LOG: paquet de démarrage incomplet
2008-04-21 15:02:07 CEST LOG: paquet de démarrage incomplet
2008-04-21 20:02:07 CEST LOG: paquet de démarrage incomplet
2008-04-22 00:02:04 CEST LOG: paquet de démarrage incomplet
2008-04-22 05:02:07 CEST LOG: paquet de démarrage incomplet

Je ne vois pas pourquoi la fonction en question s'arrête. Le
problème est reproductible et je ne sais plus où chercher pour
corriger le truc... Je ne pense pas que le problème proviennent des
capacités du serveur (j'ai essayé sur une machine avec 2 Go de
mémoire, ça a planté au bout de 20 jours de calcul [long en raison
des accès disques SATA particulièrement lents], puis sur une Sparc
U60 avec 1 Go [disques en U320] qui donne le même résultat en moins de 48
heures...).

Toute idée sera la bienvenue...

JKB



bonjour,
cette liste d'erreur ne renseigne pas cette valeur!
http://docs.postgresqlfr.org/8.2/errcodes-appendix.html

une idée:
-l'espace mémoire, le nombre de sémaphores, le nombre de fichier ouvert...
ce sont les valeurs standard du noyau?

les moteurs du commence sgbd font changer ces valeurs
A+
JB
JKB
Le #21897741
Le 22-04-2008, à propos de
Re: PostgreSQL (erreur sur requête longue),
JB écrivait dans fr.comp.applications.sgbd :


JKB a écrit:
Bonjour à tous,

Je suis en train de mettre au point des algorithmes de calcul
d'itinéraires qui tournent autour de PostGIS. J'ai réussi à
mouliner une région française sans problème. J'essaye maintenant de
faire la même chose sur la France entière et j'ai quelques
problèmes. J'ai écrit une moulinette d'intégration des données
(celle qui fonctionne parfaitement sur une région) qui s'arrête sur
la France après à peu près deux jours de calcul lors de la
transformation de la base en graphe :

PL/pgSQL function "create_graph_tables" line 11 at EXECUTE statement
psql:integration_finale.sql:101: INFO: CREATE TABLE / UNIQUE créera un
index implicite « streets_base_vertices_geom_id_key » pour la table «
streets_base_vertices »
CONTEXT: instruction SQL « CREATE TABLE streets_base_vertices (id
serial, geom_id int4 NOT NULL UNIQUE) »
PL/pgSQL function "create_graph_tables" line 11 at EXECUTE statement
psql:integration_finale.sql:101: INFO: CREATE TABLE créera des
séquences implicites « streets_base_edges_id_seq » pour la colonne
serial « streets_base_edges.id »
CONTEXT: instruction SQL « CREATE TABLE streets_base_edges (id serial,
source int, target int, cost float8, reverse_cost float8) »
PL/pgSQL function "create_graph_tables" line 15 at EXECUTE statement
Processus arrêté
rayleigh:[/opt/routing/scripts] > echo $?
137

Je n'arrive pas à trouver la signification du code d'erreur 137.
Dans les logs de PostgreSqL, j'ai ceci :

PL/pgSQL function "create_graph_tables" line 11 at EXECUTE
statement
2008-04-21 01:12:35 CEST INFO: CREATE TABLE créera des séquences
implicites « streets_base_edges_id_seq » pour la colonne serial «
streets_base_edges.id »
2008-04-21 01:12:35 CEST CONTEXTE : instruction SQL « CREATE TABLE
streets_base_edges (id serial, source int, target int, cost float8,
reverse_cost float8) »
PL/pgSQL function "create_graph_tables" line 15 at EXECUTE
statement
2008-04-21 05:02:04 CEST LOG: paquet de démarrage incomplet
2008-04-21 10:02:05 CEST LOG: paquet de démarrage incomplet
2008-04-21 15:02:07 CEST LOG: paquet de démarrage incomplet
2008-04-21 20:02:07 CEST LOG: paquet de démarrage incomplet
2008-04-22 00:02:04 CEST LOG: paquet de démarrage incomplet
2008-04-22 05:02:07 CEST LOG: paquet de démarrage incomplet

Je ne vois pas pourquoi la fonction en question s'arrête. Le
problème est reproductible et je ne sais plus où chercher pour
corriger le truc... Je ne pense pas que le problème proviennent des
capacités du serveur (j'ai essayé sur une machine avec 2 Go de
mémoire, ça a planté au bout de 20 jours de calcul [long en raison
des accès disques SATA particulièrement lents], puis sur une Sparc
U60 avec 1 Go [disques en U320] qui donne le même résultat en moins de 48
heures...).

Toute idée sera la bienvenue...

JKB



bonjour,
cette liste d'erreur ne renseigne pas cette valeur!
http://docs.postgresqlfr.org/8.2/errcodes-appendix.html



C'est bien mon problème...

une idée:
-l'espace mémoire, le nombre de sémaphores, le nombre de fichier ouvert...
ce sont les valeurs standard du noyau?



Oui.

les moteurs du commence sgbd font changer ces valeurs



Ce qui est surprenant, c'est que la requête semble se poursuivre et
que seul le client semble planté :

Cpu0 : 2.0%us, 2.6%sy, 0.0%ni, 81.1%id, 14.3%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 20.3%us, 16.3%sy, 0.0%ni, 0.0%id, 61.8%wa, 0.3%hi, 1.3%si, 0.0%st
Mem: 1013072k total, 1004896k used, 8176k free, 3576k buffers
Swap: 1951792k total, 195616k used, 1756176k free, 600888k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
6544 postgres 20 0 51336 29m 27m R 16.5 3.0 980:28.89 2 postgres
5245 benedict 20 0 231m 87m 23m S 4.4 8.9 448:53.34 0 iceape-bin

Y a-t-il moyen par un artifice de voir ce que fait postgres ou
faut-il attendre en espérant que la fin se passe bien ?

Cordialement,

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.
JB
Le #21897731
JKB a écrit:
Le 22-04-2008, à propos de
Re: PostgreSQL (erreur sur requête longue),
JB écrivait dans fr.comp.applications.sgbd :


JKB a écrit:

Bonjour à tous,

Je suis en train de mettre au point des algorithmes de calcul
d'itinéraires qui tournent autour de PostGIS. J'ai réussi à
mouliner une région française sans problème. J'essaye maintenant de
faire la même chose sur la France entière et j'ai quelques
problèmes. J'ai écrit une moulinette d'intégration des données
(celle qui fonctionne parfaitement sur une région) qui s'arrête sur
la France après à peu près deux jours de calcul lors de la
transformation de la base en graphe :

PL/pgSQL function "create_graph_tables" line 11 at EXECUTE statement
psql:integration_finale.sql:101: INFO: CREATE TABLE / UNIQUE créera un
index implicite « streets_base_vertices_geom_id_key » pour la table «
streets_base_vertices »
CONTEXT: instruction SQL « CREATE TABLE streets_base_vertices (id
serial, geom_id int4 NOT NULL UNIQUE) »
PL/pgSQL function "create_graph_tables" line 11 at EXECUTE statement
psql:integration_finale.sql:101: INFO: CREATE TABLE créera des
séquences implicites « streets_base_edges_id_seq » pour la colonne
serial « streets_base_edges.id »
CONTEXT: instruction SQL « CREATE TABLE streets_base_edges (id serial,
source int, target int, cost float8, reverse_cost float8) »
PL/pgSQL function "create_graph_tables" line 15 at EXECUTE statement
Processus arrêté
rayleigh:[/opt/routing/scripts] > echo $?
137

Je n'arrive pas à trouver la signification du code d'erreur 137.
Dans les logs de PostgreSqL, j'ai ceci :

PL/pgSQL function "create_graph_tables" line 11 at EXECUTE
statement
2008-04-21 01:12:35 CEST INFO: CREATE TABLE créera des séquences
implicites « streets_base_edges_id_seq » pour la colonne serial «
streets_base_edges.id »
2008-04-21 01:12:35 CEST CONTEXTE : instruction SQL « CREATE TABLE
streets_base_edges (id serial, source int, target int, cost float8,
reverse_cost float8) »
PL/pgSQL function "create_graph_tables" line 15 at EXECUTE
statement
2008-04-21 05:02:04 CEST LOG: paquet de démarrage incomplet
2008-04-21 10:02:05 CEST LOG: paquet de démarrage incomplet
2008-04-21 15:02:07 CEST LOG: paquet de démarrage incomplet
2008-04-21 20:02:07 CEST LOG: paquet de démarrage incomplet
2008-04-22 00:02:04 CEST LOG: paquet de démarrage incomplet
2008-04-22 05:02:07 CEST LOG: paquet de démarrage incomplet

Je ne vois pas pourquoi la fonction en question s'arrête. Le
problème est reproductible et je ne sais plus où chercher pour
corriger le truc... Je ne pense pas que le problème proviennent des
capacités du serveur (j'ai essayé sur une machine avec 2 Go de
mémoire, ça a planté au bout de 20 jours de calcul [long en raison
des accès disques SATA particulièrement lents], puis sur une Sparc
U60 avec 1 Go [disques en U320] qui donne le même résultat en moins de 48
heures...).

Toute idée sera la bienvenue...

JKB




bonjour,
cette liste d'erreur ne renseigne pas cette valeur!
http://docs.postgresqlfr.org/8.2/errcodes-appendix.html




C'est bien mon problème...


une idée:
-l'espace mémoire, le nombre de sémaphores, le nombre de fichier ouvert...
ce sont les valeurs standard du noyau?




Oui.


les moteurs du commence sgbd font changer ces valeurs




Ce qui est surprenant, c'est que la requête semble se poursuivre et
que seul le client semble planté :

Cpu0 : 2.0%us, 2.6%sy, 0.0%ni, 81.1%id, 14.3%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 20.3%us, 16.3%sy, 0.0%ni, 0.0%id, 61.8%wa, 0.3%hi, 1.3%si, 0.0%st
Mem: 1013072k total, 1004896k used, 8176k free, 3576k buffers
Swap: 1951792k total, 195616k used, 1756176k free, 600888k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
6544 postgres 20 0 51336 29m 27m R 16.5 3.0 980:28.89 2 postgres
5245 benedict 20 0 231m 87m 23m S 4.4 8.9 448:53.34 0 iceape-bin

Y a-t-il moyen par un artifice de voir ce que fait postgres ou
faut-il attendre en espérant que la fin se passe bien ?

Cordialement,

JKB




toujours sous réserve,
la quantité de mémoire utilisée est importante, je ne connais pas la
taille des blocs, mais il en resterait 1 ou 2 de disponible
la directive wait a une valeur importante, des io asynchrones?

-la fonctionnalité accounting est-elle implélentée?
cela permet de regarder avec l'outil sar
-un outil graphique existe-t-il? son observation est parfois révélateur

j'en revient à ma 1° observation, le fichier /etc/sysctl.conf
posséde-t-il les valeurs préconisées dans tout moteur de sgbd?
nota ces valeurs sont également utile pour tout autre fonctionnalité
A+
JB
JKB
Le #21897721
Le 22-04-2008, à propos de
Re: PostgreSQL (erreur sur requête longue),
JB écrivait dans fr.comp.applications.sgbd :
Ce qui est surprenant, c'est que la requête semble se poursuivre et
que seul le client semble planté :

Cpu0 : 2.0%us, 2.6%sy, 0.0%ni, 81.1%id, 14.3%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 20.3%us, 16.3%sy, 0.0%ni, 0.0%id, 61.8%wa, 0.3%hi, 1.3%si, 0.0%st
Mem: 1013072k total, 1004896k used, 8176k free, 3576k buffers
Swap: 1951792k total, 195616k used, 1756176k free, 600888k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
6544 postgres 20 0 51336 29m 27m R 16.5 3.0 980:28.89 2 postgres
5245 benedict 20 0 231m 87m 23m S 4.4 8.9 448:53.34 0 iceape-bin

Y a-t-il moyen par un artifice de voir ce que fait postgres ou
faut-il attendre en espérant que la fin se passe bien ?

Cordialement,

JKB




toujours sous réserve,
la quantité de mémoire utilisée est importante, je ne connais pas la
taille des blocs, mais il en resterait 1 ou 2 de disponible
la directive wait a une valeur importante, des io asynchrones?



Ce sont les accès disque provoqués par postgres.

-la fonctionnalité accounting est-elle implélentée?
cela permet de regarder avec l'outil sar



Non.

-un outil graphique existe-t-il? son observation est parfois révélateur



Non plus. La configuration est (aux variables gérant la mémoire
près) celle par défaut de debian/testing. Je ne pense pas que le
problème proviennent d'un dépassement de mémoire d'autant plus que
la routine en question est simplissime :

REATE OR REPLACE FUNCTION create_graph_tables(geom_table varchar,
column_type varchar)
RETURNS void AS
$$
DECLARE
geom record;
edge_id int;
myrec record;
source_id int;
target_id int;
vertices_table varchar := quote_ident(geom_table) ||
'_vertices';
edges_table varchar := quote_ident(geom_table) || '_edges';
BEGIN
EXECUTE 'CREATE TABLE ' || vertices_table || ' (id serial,
geom_id ' || quote_ident(column_type) || ' NOT
NULL UNIQUE)';
EXECUTE 'CREATE INDEX ' || vertices_table || '_id_idx on ' ||
vertices_table || ' (id)';

EXECUTE 'CREATE TABLE ' || edges_table || ' (id serial, source
int, target int, ' || 'cost float8, reverse_cost float8,
UNIQUE (source, target))';
EXECUTE 'CREATE INDEX ' || edges_table || '_source_target_idx on '
|| edges_table || ' (source, target)';

FOR geom IN EXECUTE 'SELECT gid as id, ' || ' source_id AS
source, ' || ' target_id AS target FROM ' ||
quote_ident(geom_table) LOOP

SELECT INTO source_id insert_vertex(vertices_table,
geom.source);
SELECT INTO target_id insert_vertex(vertices_table,
geom.target);

edge_id := nextval(edges_table || '_id_seq');
EXECUTE 'INSERT INTO ' || edges_table || ' (id, source,
target) VALUES (' || edge_id || ', '
|| quote_literal(source_id) || ', '
|| quote_literal(target_id) || ')';

EXECUTE 'UPDATE ' || quote_ident(geom_table) ||
' SET edge_id = ' || edge_id || ' WHERE gid = ' ||
quote_literal(geom.id);
END LOOP;
RETURN;
END;
$$
LANGUAGE 'plpgsql' VOLATILE STRICT;

Ce truc tourne sur une antique SS20 (deux HyperSPARC's/200 MHz avec
512 Mo de mémoire), mais bien trop lentement. Ce qui me semble
surtout louche, c'est l'absence totale de message d'erreur.

j'en revient à ma 1° observation, le fichier /etc/sysctl.conf
posséde-t-il les valeurs préconisées dans tout moteur de sgbd?
nota ces valeurs sont également utile pour tout autre fonctionnalité



Je n'ai pas de valeurs particulières en dehors du nombre max de fichiers
ouverts par processus de 4096 (1024 par défaut). Par ailleurs, j'ai
essayé de faire tourner le truc sur un C2D avec une configuration
brute de fonderie, le résultat est le même (je ne cherche pas à
optimiser le serveur puisque une fois cette routine passée, je vais
utiliser un serveur distant).

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.
JB
Le #21897711
JKB a écrit:
Le 22-04-2008, à propos de
Re: PostgreSQL (erreur sur requête longue),
JB écrivait dans fr.comp.applications.sgbd :

Ce qui est surprenant, c'est que la requête semble se poursuivre et
que seul le client semble planté :

Cpu0 : 2.0%us, 2.6%sy, 0.0%ni, 81.1%id, 14.3%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 20.3%us, 16.3%sy, 0.0%ni, 0.0%id, 61.8%wa, 0.3%hi, 1.3%si, 0.0%st
Mem: 1013072k total, 1004896k used, 8176k free, 3576k buffers
Swap: 1951792k total, 195616k used, 1756176k free, 600888k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
6544 postgres 20 0 51336 29m 27m R 16.5 3.0 980:28.89 2 postgres
5245 benedict 20 0 231m 87m 23m S 4.4 8.9 448:53.34 0 iceape-bin

Y a-t-il moyen par un artifice de voir ce que fait postgres ou
faut-il attendre en espérant que la fin se passe bien ?

Cordialement,

JKB




toujours sous réserve,
la quantité de mémoire utilisée est importante, je ne connais pas la
taille des blocs, mais il en resterait 1 ou 2 de disponible
la directive wait a une valeur importante, des io asynchrones?




Ce sont les accès disque provoqués par postgres.


-la fonctionnalité accounting est-elle implélentée?
cela permet de regarder avec l'outil sar




Non.


-un outil graphique existe-t-il? son observation est parfois révélateur




Non plus. La configuration est (aux variables gérant la mémoire
près) celle par défaut de debian/testing. Je ne pense pas que le
problème proviennent d'un dépassement de mémoire d'autant plus que
la routine en question est simplissime :

REATE OR REPLACE FUNCTION create_graph_tables(geom_table varchar,
column_type varchar)
RETURNS void AS
$$
DECLARE
geom record;
edge_id int;
myrec record;
source_id int;
target_id int;
vertices_table varchar := quote_ident(geom_table) ||
'_vertices';
edges_table varchar := quote_ident(geom_table) || '_edges';
BEGIN
EXECUTE 'CREATE TABLE ' || vertices_table || ' (id serial,
geom_id ' || quote_ident(column_type) || ' NOT
NULL UNIQUE)';
EXECUTE 'CREATE INDEX ' || vertices_table || '_id_idx on ' ||
vertices_table || ' (id)';

EXECUTE 'CREATE TABLE ' || edges_table || ' (id serial, source
int, target int, ' || 'cost float8, reverse_cost float8,
UNIQUE (source, target))';
EXECUTE 'CREATE INDEX ' || edges_table || '_source_target_idx on '
|| edges_table || ' (source, target)';

FOR geom IN EXECUTE 'SELECT gid as id, ' || ' source_id AS
source, ' || ' target_id AS target FROM ' ||
quote_ident(geom_table) LOOP

SELECT INTO source_id insert_vertex(vertices_table,
geom.source);
SELECT INTO target_id insert_vertex(vertices_table,
geom.target);

edge_id := nextval(edges_table || '_id_seq');
EXECUTE 'INSERT INTO ' || edges_table || ' (id, source,
target) VALUES (' || edge_id || ', '
|| quote_literal(source_id) || ', '
|| quote_literal(target_id) || ')';

EXECUTE 'UPDATE ' || quote_ident(geom_table) ||
' SET edge_id = ' || edge_id || ' WHERE gid = ' ||
quote_literal(geom.id);
END LOOP;
RETURN;
END;
$$
LANGUAGE 'plpgsql' VOLATILE STRICT;

Ce truc tourne sur une antique SS20 (deux HyperSPARC's/200 MHz avec
512 Mo de mémoire), mais bien trop lentement. Ce qui me semble
surtout louche, c'est l'absence totale de message d'erreur.


j'en revient à ma 1° observation, le fichier /etc/sysctl.conf
posséde-t-il les valeurs préconisées dans tout moteur de sgbd?
nota ces valeurs sont également utile pour tout autre fonctionnalité




Je n'ai pas de valeurs particulières en dehors du nombre max de fichiers
ouverts par processus de 4096 (1024 par défaut). Par ailleurs, j'ai
essayé de faire tourner le truc sur un C2D avec une configuration
brute de fonderie, le résultat est le même (je ne cherche pas à
optimiser le serveur puisque une fois cette routine passée, je vais
utiliser un serveur distant).

JKB



chez moi un exemple:
sous root
sysctl -a|grep shm

j'ai 4Gb sur 2 machines soit :
kernel.shmmax = 4294967295
et pour une Debian, la valeur standard 33554432
33 Mbits est la valeur par défaut
le process arrivé à cette limite swap même s'il reste de la RAM
pour les ipc je ne me rappelle plus si panic()!
A+
JB

une trace de la commande ipcs -a svp?
JKB
Le #21897701
Le 22-04-2008, à propos de
Re: PostgreSQL (erreur sur requête longue),
JB écrivait dans fr.comp.applications.sgbd :


JKB a écrit:
Le 22-04-2008, à propos de
Re: PostgreSQL (erreur sur requête longue),
JB écrivait dans fr.comp.applications.sgbd :

Ce qui est surprenant, c'est que la requête semble se poursuivre et
que seul le client semble planté :

Cpu0 : 2.0%us, 2.6%sy, 0.0%ni, 81.1%id, 14.3%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 20.3%us, 16.3%sy, 0.0%ni, 0.0%id, 61.8%wa, 0.3%hi, 1.3%si, 0.0%st
Mem: 1013072k total, 1004896k used, 8176k free, 3576k buffers
Swap: 1951792k total, 195616k used, 1756176k free, 600888k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
6544 postgres 20 0 51336 29m 27m R 16.5 3.0 980:28.89 2 postgres
5245 benedict 20 0 231m 87m 23m S 4.4 8.9 448:53.34 0 iceape-bin

Y a-t-il moyen par un artifice de voir ce que fait postgres ou
faut-il attendre en espérant que la fin se passe bien ?

Cordialement,

JKB




toujours sous réserve,
la quantité de mémoire utilisée est importante, je ne connais pas la
taille des blocs, mais il en resterait 1 ou 2 de disponible
la directive wait a une valeur importante, des io asynchrones?




Ce sont les accès disque provoqués par postgres.


-la fonctionnalité accounting est-elle implélentée?
cela permet de regarder avec l'outil sar




Non.


-un outil graphique existe-t-il? son observation est parfois révélateur




Non plus. La configuration est (aux variables gérant la mémoire
près) celle par défaut de debian/testing. Je ne pense pas que le
problème proviennent d'un dépassement de mémoire d'autant plus que
la routine en question est simplissime :

REATE OR REPLACE FUNCTION create_graph_tables(geom_table varchar,
column_type varchar)
RETURNS void AS
$$
DECLARE
geom record;
edge_id int;
myrec record;
source_id int;
target_id int;
vertices_table varchar := quote_ident(geom_table) ||
'_vertices';
edges_table varchar := quote_ident(geom_table) || '_edges';
BEGIN
EXECUTE 'CREATE TABLE ' || vertices_table || ' (id serial,
geom_id ' || quote_ident(column_type) || ' NOT
NULL UNIQUE)';
EXECUTE 'CREATE INDEX ' || vertices_table || '_id_idx on ' ||
vertices_table || ' (id)';

EXECUTE 'CREATE TABLE ' || edges_table || ' (id serial, source
int, target int, ' || 'cost float8, reverse_cost float8,
UNIQUE (source, target))';
EXECUTE 'CREATE INDEX ' || edges_table || '_source_target_idx on '
|| edges_table || ' (source, target)';

FOR geom IN EXECUTE 'SELECT gid as id, ' || ' source_id AS
source, ' || ' target_id AS target FROM ' ||
quote_ident(geom_table) LOOP

SELECT INTO source_id insert_vertex(vertices_table,
geom.source);
SELECT INTO target_id insert_vertex(vertices_table,
geom.target);

edge_id := nextval(edges_table || '_id_seq');
EXECUTE 'INSERT INTO ' || edges_table || ' (id, source,
target) VALUES (' || edge_id || ', '
|| quote_literal(source_id) || ', '
|| quote_literal(target_id) || ')';

EXECUTE 'UPDATE ' || quote_ident(geom_table) ||
' SET edge_id = ' || edge_id || ' WHERE gid = ' ||
quote_literal(geom.id);
END LOOP;
RETURN;
END;
$$
LANGUAGE 'plpgsql' VOLATILE STRICT;

Ce truc tourne sur une antique SS20 (deux HyperSPARC's/200 MHz avec
512 Mo de mémoire), mais bien trop lentement. Ce qui me semble
surtout louche, c'est l'absence totale de message d'erreur.


j'en revient à ma 1° observation, le fichier /etc/sysctl.conf
posséde-t-il les valeurs préconisées dans tout moteur de sgbd?
nota ces valeurs sont également utile pour tout autre fonctionnalité




Je n'ai pas de valeurs particulières en dehors du nombre max de fichiers
ouverts par processus de 4096 (1024 par défaut). Par ailleurs, j'ai
essayé de faire tourner le truc sur un C2D avec une configuration
brute de fonderie, le résultat est le même (je ne cherche pas à
optimiser le serveur puisque une fois cette routine passée, je vais
utiliser un serveur distant).

JKB



chez moi un exemple:
sous root
sysctl -a|grep shm

j'ai 4Gb sur 2 machines soit :
kernel.shmmax = 4294967295
et pour une Debian, la valeur standard 33554432
33 Mbits est la valeur par défaut



En l'occurrence, ça ne swappe pas vraiment. Bon, je vais augmenter
le truc.

Root rayleigh:[~] > sysctl kernel.shmmaxS6870912
kernel.shmmax = 536870912

le process arrivé à cette limite swap même s'il reste de la RAM
pour les ipc je ne me rappelle plus si panic()!
A+
JB

une trace de la commande ipcs -a svp?



Root rayleigh:[~] > ipcs -a

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x0052e2c1 0 postgres 600 29409280 5
0x00000000 32769 gdm 600 393216 2 dest

------ Semaphore Arrays --------
key semid owner perms nsems
0x0052e2c1 0 postgres 600 17
0x0052e2c2 32769 postgres 600 17
0x0052e2c3 65538 postgres 600 17
0x0052e2c4 98307 postgres 600 17
0x0052e2c5 131076 postgres 600 17
0x0052e2c6 163845 postgres 600 17
0x0052e2c7 196614 postgres 600 17
0x00000000 229383 www-data 600 1

------ Message Queues --------
key msqid owner perms used-bytes messages

Root rayleigh:[~] >

Voilà, voilà...

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.
Thierry B.
Le #21897421
--{ JKB a plopé ceci: }--

rayleigh:[/opt/routing/scripts] > echo $?
137

Je n'arrive pas à trouver la signification du code d'erreur 137.



C'est un code d'exit(), ça, puisque tu le retrouve dans $? et il
est donc passé dans les mains de ton shell.

137-128 -> 9 -> SIGKILL

Il te faut remonter plus haut dans la chaine...

--
J'ai l'impression que TeX, c'est un peu comme une partie d'échec. Avec
les macros, on a un source « mouvant » et il faut calculer plusieurs coups
à l'avance, sauf qu'avec TeX, on ne peut pas bouger les pièces pour voir.
--{ F, dans fct.tex }--
Publicité
Poster une réponse
Anonyme