PostgreSQL (erreur sur requête longue)

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

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

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

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é

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

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?

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

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