Vous n'êtes pas identifié(e).
bonjour,
j'ai un fichier 4441919 (1giga) dans data/base/72952 quand je fais
./oid2name -d eco -U postgres -f 4441919
il ne le trouve pas , surement car j'ai une grosse requete qui s'est mal passé
Puis je supprimer ce fichier
Sinon comme Faut t'il gerer les filenode orphelins ?
merci
Dernière modification par mich30 (08/06/2011 16:26:45)
Hors ligne
Puis je supprimer ce fichier
Non, surtout pas.
Sinon comme Faut t'il gerer les filenode orphelins ?
PostgreSQL se débrouillera très bien tout seul. Il finira par le supprimer.
Guillaume.
Hors ligne
mercii mais le probleme et que j'ai beaucoup de fichiers filenode "orphelins" de 1 giga
c'est une requete geometrique qui s'est mal passé et cela sature la base de données .
Quand postgres va les enlever ? comment ? avec autovaccum a on ?
Avez vous une doc sur ce type de probleme
merci
Dernière modification par mich30 (08/06/2011 21:52:40)
Hors ligne
C'est le bgwriter qui s'en chargera. À condition que ce soit bien des fichiers inutiles.
Guillaume.
Hors ligne
bon je comprends plus ces filenode ne sont pas referencés dans pg_class
et ca fait un jour qu'ils sont dans dans ce repertoire cela me sature mon espace disque
comment puis je faire ?
merci
Hors ligne
a ce soir j'ai regardé la taille schemas, des tables, des index < 200 giga
et dans mon data \base\72952 j'ai 900 giga donc espace libre de mon mountage de 8 giga
les filenode sont entassé dans ce repertoire a coup de 1giga ( donc au total 900 giga)
j'ai fait un vacuum rien n'y fait , le bgwriter y a longtemps qu'il aurait fait le menage !!
une piste ???? merci
Hors ligne
c'est une mauvaise requete qui s'est passé confirmation à ce jour , toujours 900 giga de plein
est ce que ces valeurs
shared_buffers = 512MB
fsync = on
synchronous_commit = off
wal_writer_delay = 2000ms
checkpoint_segments = 20
checkpoint_timeout = 1min
checkpoint_completion_target = 0.8
checkpoint_warning = 1min
bgwriter_delay = 10ms
bgwriter_lru_maxpages = 1000
bgwriter_lru_multiplier = 10
peuvent resoudre mon probleme??
Hors ligne
Il faudrait déjà comprendre la raison du problème : comment l'exécution d'une requête peut prendre autant d'espace sur le disque ? avec la requête, il serait plus simple de répondre.
Guillaume.
Hors ligne
c'est une requete avec une mauvaise jointure sur une autre table encapsulé dans un create table qui ne sait jamais fait
merci
Hors ligne
Pour aller plus loin, il faut la requête, pas sa description.
Guillaume.
Hors ligne
drop table myschema.infoparc_sample ;
create table myschema.infoparc_sample as
select a.id_parc,a.the_geom,X(a.centroide),Y(a.centroide),b.distvill, b.drp, b.drs, b.dgare,b.dzconst, b.dsurf_eau , c.dist_bat_majic, d.dist_bat_pci,e.dr
from infoparc2010.infop_dist as a
left join
myschema.distance as b on (a.id_parc=b.id_parc)
left join myschema.distance_majic as c on (a.id_parc=c.id_parc)
left join myschema.distance_pci as d on (a.id_parc=d.id_parc)
left join myschema.distance_chemin as e on (a.id_parc=d.id_parc)--- erreur était ici sur d.id_parc au lieu de e.id_parc --> ce qui a conduit à un table gigantesque (la table infoparc2010.infop_dist contient 250 000 obs)
where substr(a.id_parc,1,5) in (select id_insee from myschema.sample1_com);
Hors ligne
Et la correction a corrigé le problème des X Go créés ?
Guillaume.
Hors ligne
malheureusement non on est toujours a 7 giga d'espace libre
la create table myschema.infoparc_sample n'a jamais été crée ce qui est normal
Cette requete a pris tout l'espace disque .
Il faudrez peut etre forcer le bgwriter pour qu'il nettoie mais comment ?
ou autre solution , le probleme est vraiment pointu !
merci d'avance
Hors ligne
j'ai supprimer les filenode orphelins (avec oid2name ou aucune table ets référencé ) et cela marche
merci
Hors ligne
