plus d'infos

aitali/ = 3 Juillet, 2007 - 10:21

bonjour et merci pour votre reponse:
au niveau du swap, j'ai un probleme bizarre ! swap used =0
voici les infos:

top - 10:30:33 up 1:02, 2 users, load average: 1.26, 0.68, 0.51
Tasks: 103 total, 5 running, 98 sleeping, 0 stopped, 0 zombie
Cpu(s): 98.2% us, 1.8% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 2074760k total, 552200k used, 1522560k free, 19816k buffers
Swap: 2040244k total, 0k used, 2040244k free, 431804k cached

none 1037380 0 1037380 0% /dev/shm
/dev/sda2 60174944 1293088 55825092 3% /var
donc var est occupé a 3% seulement !!!

ma base est installée dans /var/postgresql/
et dans ce repertoire j'ai: bin data doc include lib man share

dans data j'ai :

base pg_clog pg_ident.conf pg_subtrans pg_twophase pg_xlog postmaster.opts
global pg_hba.conf pg_multixact pg_tblspc PG_VERSION postgresql.conf postmaster.pid

dans base, j'ai les fichiers suivants:

drwx------ 6 postgres postgres 4096 Jun 30 20:44 .
drwx------ 10 postgres postgres 4096 Jul 3 09:33 ..
drwx------ 2 postgres postgres 4096 Jun 30 20:42 1
drwx------ 2 postgres postgres 4096 Jun 30 20:40 10818
drwx------ 2 postgres postgres 4096 Jul 3 10:03 10819
drwx------ 3 postgres postgres 12288 Jul 3 09:36 16384

j'ai testé ces fichiers comme ceci, mais ces fichiers sont vides !!!

postgres=# SELECT relname, relkind from pg_class where relfilenode='10818';
relname | relkind
---------+---------
(0 rows)

postgres=# SELECT relname, relkind from pg_class where relfilenode='10819';
relname | relkind
---------+---------
(0 rows)

postgres=# SELECT relname, relkind from pg_class where relfilenode='16384';
relname | relkind
---------+---------
(0 rows

je vous remercie

Plusieurs choses

SAS/ = 10 Juillet, 2007 - 15:18

Bonjour,

Le fait que la swap ne soit pas utilisée n'est, en soi, pas un problème. D'autant plus que la RAM disponible est loin d'être entièrement utilisée.

Cela laisse soupçonner une configuration qui ne tire pas parti de mémoire disponible sur le serveur. Une piste de plus :-)

Concernant les "fichiers" du répertoire "base", il s'agit en fait de répertoires correspondant chacun à une base de données. Pour avoir connaissance de la taille des fichiers des bases, il faut descendre un cran en dessous.

Librement,
Stéphane Schildknecht
dalibo
PostgreSQLFr

pas de swap utilisé, c'est t

jmreymond/ = 4 Juillet, 2007 - 16:59

pas de swap utilisé, c'est toujours ça de gagné mais avec du swap, le CPU n'est pas à 100% Sous Linux/Unix, la commande top indiquera quel process prend tout le CPU et si c'est postgres, il faut s'inquiéter

Jean-Max Reymond
CKR Solutions Open Source
http://www.ckr-solutions.com

Probleme de CPU resolu en partie !

aitali/ = 6 Juillet, 2007 - 11:22

avec VCCUM FULL sur toute la base a permis de netoyer la base, mais pas les indexs des grosses tables
! est ce normal ? est ce qu'il faut faire un vaccum analyze des tables une a une ? et un Vacuum full index en plus de Vacuum full de la base ?
merci

il faut que tu fasse un reind

Matthieu guerchet/ = 6 Juillet, 2007 - 11:40

il faut que tu fasse un reindexdb -a pour récupérrer de la place des index.

taille des indexs

aitali/ = 10 Juillet, 2007 - 15:18

bonjour a tous,
j'ai executé cette commande sur ma base et j'ai le resultat suivant !
select * from v_stats_size_pretty ;

nom | tuples | volume_total | volume_donnees | volume_index
------------------------+--------+--------------+----------------+--------------
table100 | 82643 | 448 MB | 100 MB | 348 MB

comme vous pouvez le constater, le volume de l'index est trois fois plus gros que les données !!
avez vous une idée sur la facon la plus efficace de resoudre ce probleme a long terme ?
merci d'avance

Reindex, vacuum ?

SAS/ = 10 Juillet, 2007 - 15:24

Qu'ont donné la réindexation et le vacuum ?

Librement,
Stéphane Schildknecht
dalibo
PostgreSQLFr

Reindex, vacuumdb --full ....?

aitali/ = 12 Juillet, 2007 - 09:56

merci pour votre reponse,
en fait,le reindex et vacuum: analyze, full, ... et toutes les options, ont permis de réduire la taille des données et des index, mais la taille des index reste importante par rapport aux données, a l'heure actuelle, apres reindex et vacuum, j'ai les infos suivantes:

nom | tuples | volume_total | volume_donnees | volume_index
------------------------+--------+--------------+----------------+--------------

tablex | 83409 | 437 MB | 100 MB | 337 MB
question: est ce que l'heritage marche bien sous postgres ?
question: est ce qu'il y a un moyen de partitionner les tables sans utiliser l'heritage ?
question: avez vous une idée de la solution a ce probleme ? car cette table va encore grossir a moyen terme
merci encore