Vous n'êtes pas identifié(e).

Pages : 1 2 3 4 5 6

#51 Re : Général » pgdump sans index ? » 29/11/2012 12:59:50

gom

C'est pas mieux ... mais là je sais pourquoi ! hmm


[postgres@serveurtest test_dump]$ time /app/mon_projet/pgsql/bin/pg_dump -p 5433 -c -C -O -o --format=c --compress=0 mabase | gzip -c > dwh_20121128.dmp.tar.gzip

gzip: stdout: No space left on device

real    5m19.118s
user    3m38.377s
sys     0m43.320s
[postgres@serveurtest test_dump]$ ll
total 470332
-rw-r--r-- 1 postgres postgres 481144832 nov 29 11:19 dwh_20121128.dmp.tar.gzip



Gôm

#52 Re : Général » pgdump sans index ? » 29/11/2012 12:20:34

gom

Aïe ... j'ai le message d'erreur suivant. sad


[postgres@serveurtest test_dump]$ /app/mon_projet/pgsql/bin/pg_dump -p 5433 -c -C -O -Fc --compress=0 mabase | gzip -c > dwh_20121128.dmp.tar.gzip
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  cache lookup failed for index 84038
pg_dump: The command was: SELECT t.tableoid, t.oid, t.relname AS indexname, pg_catalog.pg_get_indexdef(i.indexrelid) AS indexdef, t.relnatts AS indnkeys, i.indkey, i.indisclustered, c.contype, c.conname, c.tableoid AS contableoid, c.oid AS conoid, (SELECT spcname FROM pg_catalog.pg_tablespace s WHERE s.oid = t.reltablespace) AS tablespace, array_to_string(t.reloptions, ', ') AS options FROM pg_catalog.pg_index i JOIN pg_catalog.pg_class t ON (t.oid = i.indexrelid) LEFT JOIN pg_catalog.pg_depend d ON (d.classid = t.tableoid AND d.objid = t.oid AND d.deptype = 'i') LEFT JOIN pg_catalog.pg_constraint c ON (d.refclassid = c.tableoid AND d.refobjid = c.oid) WHERE i.indrelid = '63797'::pg_catalog.oid ORDER BY indexname


C'est parce que j'ai enlevé l'option "-o" ?


Je viens de faire une relance avec cette option (pour voir) :


time /app/mon_projet/pgsql/bin/pg_dump -p 5433 -c -C -O -o --format=c --compress=0 mabase | gzip -c > dwh_20121128.dmp.tar.gzip


Gôm

#53 Re : Général » pgdump sans index ? » 28/11/2012 17:29:17

gom

Comme ça ! roll


/app/mon_projet/pgsql/bin/pg_dump -p 5433 -c -C -O --format=c --compress=0 mabase | gzip -c > dwh_20121128.dmp.tar.gzip

Merciiiii ! smile



Gôm

#54 Re : Général » pgdump sans index ? » 28/11/2012 17:25:16

gom

J'ai lancé exactement cette commande sur mon serveur de tests, mais du coup j'ai un fichier .dmp et un fichier .tar.gzip ! hmm


/app/mon_projet/pgsql/bin/pg_dump -p 5433 -c -C -O --format=c --compress=0 -f /home/postgres/moi/test_dump/dwh_20121128.dmp mabase | gzip -c > dwh_20121128.dmp.tar.gzip

Comment puis-je faire pour avoir uniquement le fichier .tar.gzip ?



Gôm

#55 Re : Général » pgdump sans index ? » 28/11/2012 16:30:55

gom

Je ne vais pas pouvoir tester sur une volumétrie équivalente. Mon environnement de tests contient très peu de données par rapport à celui où va être passé cette commande.


Mais bon, après avoir lu ça : http://nerdbynature.de/s9y/?251 neutral yikes cool


Je vais au final demander à passer le pg_dump avec ces options là :


pg_dump -c -C -O --format=c --compress=0 -f /chemin/de/monfichier.dmp mabase | pigz -c > monfichier_dump.tar.pigz


Gôm

#56 Re : Général » pgdump sans index ? » 28/11/2012 13:13:42

gom

Sinon ... pigz ou pbzip2 => http://blog.bearstech.com/2011/10/compr … bzip2.html ?!


Mon objectif est certes de gagner de la place, mais aussi de gagner du temps ! Pour faire simple si je gagne 50% en compression, mais que je mets 50% de temps en plus (sachant que j'ai une base qui fait 660 Go dont 250 Go d'Index) alors je préfère perdre les 50% de compression.


J'espère que cet exemple vous aidera à me conseiller. wink

#57 Re : Général » pgdump sans index ? » 28/11/2012 13:07:46

gom

Merci messieurs ! smile


Je vais donc faire :

pg_dump -c -C -O --format=c --compress=0 -f /chemin/de/monfichier.dmp mabase | pbzip2 -c > monfichier_dump.tar.bz2

OK ?

#58 Re : Général » pgdump sans index ? » 28/11/2012 11:25:36

gom
gleu a écrit :

J'ai lu qu'il était possible de désactiver des index : http://stackoverflow.com/questions/6146 … n-postgres

C'est possible, oui. Pour l'instant. Il n'est pas garanti que cela fonctionne toujours. Tripoter les catalogues systèmes est souvent le meilleur moyen de faire des bêtises smile

OK, c'est noté. Merci.


gleu a écrit :

Est-ce que du coup mon pg_dump sera sans index ?

Non, il sera sauvegardé.

évidemment sans index ce serait plus rapide !

Certainement pas la copie, vu que seul l'ordre de création d'index est présent dans le dump. Pas ses données. La restauration, par contre, là, oui smile

Génial, c'est exactement ce que je voulais ! Il ne me restera qu'à gérer correctement le pg_restore pour que les index ne soient pas créés à la restauration. Je le ferai manuellement après. Mon souhait est de restaurer uniquement les données, puis les index.


gleu a écrit :

Par défaut, --format=c correspond à --compress=5 ?

Bonne question. Par défaut, ça utilise le niveau de compression par défaut de zlib. Mais je n'en sais pas plus.

OK.


gleu a écrit :

Combien de temps vais-je perdre avec un --compress=9 par rapport à la valeur par défaut ?

Beaucoup ?

C'est évidemment impossible à dire comme ça. Un test que j'ai effectué avec un client montrait que passer de 1 à 2 doublait le temps de compression.

Et combien de place je vais gagner entre un --compress=5 et un --compress=9 ?

Peu ?

Là aussi, c'est évidemment impossible à dire.

Personnellement, je ne pense pas qu'il y ait un gros intérêt pour passer d'un niveau 5 à un niveau 9. J'aurais plutôt tendance à désactiver la compression et à envoyer le résultat de la sauvegarde à un outil de compression parallélisé. Ce sera beaucoup plus performant, et permettra du coup un meilleur niveau de compression.


Du coup je laisse "--format=c" (qui permet entre autre de compresser), mais j'enlève "--compress" ?

pg_dump -c -C -O -b -o --format=c -f /chemin/de/monfichier.dmp mabase

Si j'ai bien compris "--format=c" = "-Fc" or : http://www.postgresql.org/docs/8.4/stat … gdump.html, donc je suis obligé de laisser cette option si je veux pouvoir restaurer sans les index (car le dump sera ordonné, donc facile de supprimer toutes les commandes de création d'index), l'inconvénient est que je vais perdre du temps à cause de la compression par défaut. J'ai bon ?


Quel outil de compression parallélisé dois-je utiliser ? Je ne vois pas comment cela va fonctionner et comment le mettre en œuvre.



Gôm

#59 Re : Général » pgdump sans index ? » 27/11/2012 18:46:21

gom

Par défaut, --format=c correspond à --compress=5 ?

Combien de temps vais-je perdre avec un --compress=9 par rapport à la valeur par défaut ? Et combien de place je vais gagner entre un --compress=5 et un --compress=9 ?


Beaucoup de questions, mais malheureusement G**gle ne m'a pas aidé ! wink


Gôm

#60 Général » pgdump sans index ? » 27/11/2012 17:30:13

gom
Réponses : 43

Bonjour,


Question simple ! smile


J'ai lu qu'il était possible de désactiver des index : http://stackoverflow.com/questions/6146 … n-postgres


Est-ce que du coup mon pg_dump sera sans index ?

pg_dump -c -C -O -b -o --format=c --compress=9 -f /chemin/de/monfichier.dmp mabase

Ma base (Datawarehouse) fait presque 700 Go, dont au moins 1/3 d'index. Sachant que je suis obligé de passer mon dump d'un environnement à l'autre via un disque dur externe ... évidemment sans index ce serait plus rapide ! hmm


A propos, si quelqu'un connait la requête pour calculer le nombre d'octets que représentent mes index ... je suis preneur ! Version PostgreSQL : 8.4.4 (Linux)



Gôm

#61 Re : Optimisation » Paralléliser le recalcul des index » 13/11/2012 15:43:42

gom
rjuju a écrit :

Quand vous dites sauvegarde à froid, c'est une sauvegarde base de donnée arrêtée ? Si oui, le fait d'arrêter la base vide le shared_buffers, et tant que celui-ci n'est pas rempli les performances seront bien évidemment moindre. Il est bien entendu possible de sauvegarder la base à chaud.

Quels inconvénients à sauvegarder à chaud ? Si aucun, alors puis-je recommander systématiquement des sauvegardes à chaud ?


rjuju a écrit :

Quel est le volume total de vos index ? (SELECT sum(pg_relation_size(oid)) FROM pg_class WHERE relkind = 'i'; )

73189769216 octets = 68.1632843 gigabytes


rjuju a écrit :

Pour optimiser ce traitement, il faut d'abord identifier la source de contention. Si c'est le cpu, il faut effectivement essayer de lancer plusieurs REINDEX en parallèle. Il est plus probable que la contention vienne des disques, ceux-ci étant fortement sollicités lors d'un REINDEX (lecture de la table si non présent en cache, création des index sur disque et génération d'une grand quantité de wal).

Une des premières possibilités d'optimisation est d'utiliser un filesystem séparé et rapide pour le répertoire pg_xlog, afin de pouvoir paralléliser les écritures des wals et des fichiers de données.


Comment savoir si le point de contention est le CPU ou le disque ?

Je croyais qu'il était impossible avec PostgreSQL de lancer des REINDEX est parallèle ?! neutral


Gôm

#62 Re : Optimisation » Paralléliser le recalcul des index » 12/11/2012 12:37:13

gom
rjuju a écrit :

En 8.4, la nécessité de faire un REINDEX est en général lié au VACUUM FULL. Constatez-vous un gain de performances après ce REINDEX ? Le moyen le plus simple de voir si le reindex est efficace est de comparer la taille des index avant et après (select relname,pg_relation_size(oid) from pg_class where relkind = 'i' order by 2 desc);


De plus, les tables aussi peuvent également être fragmentées. Est-ce que l'autovacuum est activé ?


Quelle est la valeur actuelle du paramètre maintenance_work_mem ? Vous pouvez changer ce paramètre en sql. Par exemple: SET maintenance_work_mem to '500B';

Oui je constate un gain de performance lorsque je fais un REINDEX. Le problème est que je ne peux plus faire de REINDEX DATABASE "Ma_base".

Oui l'autovacuum est activé.

show autovacuum;
> on
SHOW maintenance_work_mem;
> 512MB

512 Mo est suffisant pour un serveur disposant de 8 Go de RAM.


Gôm

#63 Re : Optimisation » Paralléliser le recalcul des index » 26/10/2012 16:52:10

gom

Bonjour,

Oui je suis obligé (du moins c'est ce que je pense) car mes données en tables bougent énormément chaque semaine.

Certaines tables sont entièrement vidées et réalimentées, les autres sont mises à jour (INSERT de nouvelles données et UPDATE des anciennes données).

Comment savoir quels index sont trop fragmentés et doivent être réindexés ? Peut-être est-ce la solution à mon problème, non ?

Sinon je ne peux que lancer des instructions SQL donc je ne pourrai pas modifier maitenance_work_mem à la volée.


Gôm

#64 Re : Optimisation » Plantage REINDEX par manque d'espace disque » 26/10/2012 16:07:50

gom

Petit retour ... au final j'ai fait comme ça :


SELECT 'DROP INDEX IF EXISTS ' || nspname || '.' || relname || ';' as "DROP INDEX"
from pg_class c, pg_namespace 
where relkind='i' and relnamespace not in 
    (select oid 
     from pg_namespace 
     where nspname in ('pg_catalog','pg_toast')
    ) 
and c.oid not in (select indexrelid from pg_index where indisprimary ) 
and c.relowner = nspowner 
order by nspname;
VACUUM FULL ANALYZE;
SELECT pg_get_indexdef(oid) || ';' as "CREATE INDEX"
from pg_class 
where relkind='i' and relnamespace not in 
    (select oid 
     from pg_namespace 
     where nspname in ('pg_catalog','pg_toast')
    ) 
and oid not in (select indexrelid from pg_index where indisprimary);

Gôm

#65 Optimisation » Paralléliser le recalcul des index » 26/10/2012 16:03:23

gom
Réponses : 9

Bonjour,


Je travaille sur un entrepôt de données sous PostgreSQL 8.4.4 (sous Redhat 4.1.2-46 64 bits).


Mon problème est simple à expliquer mais je ne vois clairement pas comment le résoudre ! hmm


Je fais un REINDEX d'une base de données Décisionnel chaque weekend ainsi :

REINDEX DATABASE "Mon_DWH"

Le problème : environ 42 heures d'exécution alors que je suis sensé lancer le REINDEX à 3h00 le samedi matin et les bases sont sauvegardées à froid à 20h00 le dimanche soir.


Un coup sur 2 mon REINDEX ne passe pas ! sad


Gôm

#66 Re : Général » Auto verrouillage de la table où je fais des INSERT ?! » 14/06/2012 14:02:57

gom

1000 INSERT par transaction. J'ai essayé avec 1 INSERT pour 1 transaction, mais rien n'y fait ! hmm

#67 Général » Auto verrouillage de la table où je fais des INSERT ?! » 14/06/2012 12:15:13

gom
Réponses : 3

Bonjour,

Je lance des INSERT depuis un ETL et j'ai des ExclusiveLock, des AccessShareLock et des RowExclusiveLock sur la table.

En résumé ... je m'auto-verrouille ! roll hmm

select t.relname,l.locktype,page,virtualtransaction,pid,mode,granted 
from pg_locks l, pg_stat_all_tables t 
where l.relation=t.relid 
order by relation asc;

"ma_table";"relation";;"14/63596";7415;"RowExclusiveLock";t


Une idée ?

Gôm

#68 Re : PgAdmin3 » Masquer les colonnes tableoid, cmax, xmax, etc. ? » 12/03/2012 15:56:58

gom

Trouvé ...

Fichier > Préférences > (Onglet) Navigateur => Décocher "Afficher les objets systèmes dans l'arborescence".

Gôm

#69 PgAdmin3 » Masquer les colonnes tableoid, cmax, xmax, etc. ? » 12/03/2012 15:52:20

gom
Réponses : 1

Bonjour,

PgAdmin 1.12.3 ou 1.14.0

Comment masquer ces colonnes (http://dave.webdev.pgadmin.org/docs/1.6 … lumns.html) ?


Merci d'avance ! smile

Gôm

#70 Re : Général » Ajouter un rôle en SELECT uniquement sur toutes les tables d'une base » 25/10/2011 13:57:30

gom

C'est toujours pareil ... je cherche sur le net ... je cherche sur le net ... je trouve pas ... je poste sur le forum ... je continue à chercher et je trouve ! roll

select 'grant select on '||schemaname||'.'||tablename||' to util_select;' from pg_tables where schemaname in ('mon_schema_1', 'mon_schema_2', 'mon_schema_4') order by schemaname, tablename;

Source: http://serverfault.com/questions/60508/ … 002#147002


Gôm

#71 Général » Ajouter un rôle en SELECT uniquement sur toutes les tables d'une base » 25/10/2011 13:41:13

gom
Réponses : 1

Bonjour,

Je travaille avec PostgreSQL 8.4 (donc la syntaxe version 9.0 ne fonctionne pas ! wink)

CREATE ROLE util_select LOGIN
  ENCRYPTED PASSWORD 'md5............................'
  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
GRANT CONNECT 
    ON DATABASE "MA_BDD"
    TO util_select;

Les scripts ci-dessus fonctionnent parfaitement par contre je ne sais pas comment faire ça (suis-je obligé de le faire table par table ?!) :

GRANT SELECT 
    ON DATABASE "MA_BDD"
    TO util_select;

Gôm

#72 Re : Migration » Migration PostgreSQL 8.4.4 (Linux) vers SQL Server 2008 R2 » 09/06/2011 10:26:45

gom

L'éditeur assure du support pour son application mais pas sur les bases de données où son application peut être installée (Oracle, SQL Server, etc.), comme n'importe quel éditeur.

Sinon en interne à mon entreprise, non je n'ai pas de support, expert, etc. SQL Server. sad

Je me disais qu'en demandant ici, l'un d'entre vous aurait peut-être réalisé une migration SQL Server -> PostgreSQL et constaté une baisse significative de la volumétrie. C'est-à-dire l'inverse de ce que moi je constate en réalisant une migration dans l'autre sens !! mad


Gôm

#73 Migration » Migration PostgreSQL 8.4.4 (Linux) vers SQL Server 2008 R2 » 09/06/2011 10:19:25

gom
Réponses : 3

Bonjour,

Une question de migration qui ne va "pas dans le bon sens" pour des pro-PostgreSQL, mais je tente ma chance tout de même ! wink

Je suis dans l'obligation de réaliser une migration vers SQL Server car l'éditeur de mon application, qui utilise actuellement PostgreSQL, refuse d'assurer du support tant que je serai sous PostgreSQL. Bref ...

Mon problème est que la volumétrie de ma base de données a explosée !

PostgreSQL = 270Go d'espace disque total.

SQL Server 2008 R2 = 320Go !!! hmm


Sauriez-vous me dire d'où cela peut bien venir ? Sachant que d'après mes quelques premières vérifications, l'espace disque occupé par chaque type de donnée est identique (nombre d'octets).

Gôm

#74 Re : Optimisation » Plan d'exécution catastrophique malgré des Index ? » 27/04/2011 17:45:22

gom

Installation faite et effectivement ... c'est mieux ! big_smile


Merci merci et merci encore pour tout ! cool

Gôm

#75 Re : Optimisation » Plan d'exécution catastrophique malgré des Index ? » 27/04/2011 17:10:23

gom

Dans PgAdmin lorsque je clique sur mon serveur dont je veux modifier le postgresql.conf et que je vais dans Menu "Outils" -> "Configuration du serveur" : "Configuration du serveur" est grisé, alors que sur mes autres serveurs ce n'est pas le cas. Sais-tu pourquoi ? sad


Gôm

Pages : 1 2 3 4 5 6

Pied de page des forums

Propulsé par FluxBB