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

Pages : 1 2 3 4 5 6

#26 Optimisation » UPDATE massif » 12/02/2013 19:31:21

gom
Réponses : 17

Bonjour,


J'ai fait une reprise de données sur un Datawarehouse et la volumétrie a explosé ! Je suis passé de 670 Go à 1,4 To ! hmm


Non je n'ai pas fait d'INSERT ! smile J'ai bien fait uniquement des UPDATE.


Cette explosion de la volumétrie apparaît principalement sur 3 tables :


-- Table 1
-- Prod : 54 GB + 36 GB
-- Recette : 104 GB + 92 GB


-- Table 2
-- Prod : 111 GB + 54 GB
-- Recette : 248 GB + 108 GB


-- Table 3
-- Prod : 126 GB + 72 GB
-- Recette : 349 GB + 253 GB



Je pensais faire comme ça pour résoudre ce problème, mais rien que sur la plus petite table au bout de 3 heures le VACUUM FULL n'est toujours pas fini !!


DROP INDEX ...;

vacuum full ...;

CREATE INDEX ...;

vacuum analyze ...;


Une autre idée ? Est-ce qu'un paramétrage particulier de PostgreSQL.conf aiderait ?


Gôm

#27 Re : Optimisation » Quelle quantité de RAM allouer ? » 12/02/2013 19:12:28

gom
gleu a écrit :

Ai-je quelque chose à modifier au final ?

Oui, baisser work_mem.

Merci.


A combien ?

#28 Re : Optimisation » Quelle quantité de RAM allouer ? » 30/01/2013 15:12:37

gom

Bonjour rjuju !


rjuju a écrit :

tout simplement parce que 25% de la RAM pour le shared_buffers est un réglage qui convient bien en général.

OK donc je laisse le shared_buffers à 2GB. Merci. smile



rjuju a écrit :

Postgres utilise des accès disques standard, et le cache système est donc à prendre en compte.

Cela signifie que plutôt d'augmenter le shared_buffers, il vaudrait mieux que je vérifie le paramétrage du cache système ?



rjuju a écrit :

De plus, la valeur de work_mem est très haute (300 Mo), et une grande quantité de RAM peut être utilisée pour les tris.

Je n'ai pas compris. Ai-je quelque chose à modifier au final ?



rjuju a écrit :

Le paramètre wal_buffers pourrait par contre être montée à 16Mo.

OK je change ça tout de suite. Encore merci ! wink



Précision : ma base de Prod est un Datawarehouse et mon serveur tourne sur Redhat 5.4.


Gôm

#29 Optimisation » Quelle quantité de RAM allouer ? » 30/01/2013 12:56:31

gom
Réponses : 5

Bonjour,


Question simple et courte : pourquoi le serveur de Prod de mon client a un shared_buffers à 2GB alors que le serveur (dédié avec seulement la base de Prod) possède 8GB de RAM ?


# - Connexions -
listen_addresses = ’*’
# - Memoire -
shared_buffers = 2GB
wal_buffers = 8MB
work_mem = 300MB
maintenance_work_mem = 512MB
# - Journaux de transactions -
checkpoint_segments = 50
checkpoint_timeout = 10min
checkpoint_completion_target = 0.9
# - Optimiseur -
effective_cache_size = 5376MB
random_page_cost = 2.0
# - Statistiques -
track_activity_query_size = 4096
# - Traces -
log_filename = ’postgresql-%Y-%m-%d.log’
log_truncate_on_rotation = off
log_line_prefix = ’%t [%p] : [%l-1] ’
lc_messages = ’C’
log_checkpoints = on
log_lock_waits = on
log_temp_files = 0
log_autovacuum_min_duration = 0
# - Module pg_stat_statements -
shared_preload_libraries = ’pg_stat_statements’
custom_variable_classes = ’pg_stat_statements’
pg_stat_statements.max = 1000
pg_stat_statements.track = top
pg_stat_statements.save = on



Merci d'éclairer ma lanterne ! wink


Gôm

#30 Re : Général » pgdump sans index ? » 21/01/2013 19:08:50

gom

Aïe je pensais pouvoir restaurer ma base sans les index et "relancer le pg_restore" uniquement pour la création d'index.


Est-ce possible sans éditer le dump en le coupant en 2 ?

#31 Re : Général » pgdump sans index ? » 21/01/2013 16:56:08

gom

Je pensais avoir la place de faire ma restauration étant donné que les index sont à calculés après coup. J'ai faux ? sad

#32 Re : Général » pgdump sans index ? » 21/01/2013 15:31:48

gom
gleu a écrit :

Vous ne pouvez pas vous en assurer, à moins de connaître la taille de la base au final.


661 Go avec les index.

#33 Re : Général » pgdump sans index ? » 21/01/2013 13:01:00

gom

Je me suis mal exprimé : 637 - 537 = 100 Go de dispo théoriquement, alors que seuls 69 Go sont affichés. (J'ai édité mon précédent post.)


Si je veux relancer ma restauration, comment puis-je m'assurer de ne pas avoir à nouveau l'erreur ?


ERREUR:  n'a pas pu étendre la relation base/19635/1259 : Aucun espace disponible sur le périphérique

#34 Re : Général » pgdump sans index ? » 21/01/2013 12:48:59

gom

Comment ça du ménage "par lui" ?


Sinon je constate que Linux me dit que j'occupe 89% d'espace disque pour cette partition, alors que 637-537 = 100 Go de dispo signifie plutôt qu'il me reste plus de 15% de libre, donc que j'occuperais 84% et quelques, et non 89% ?! hmm

[root@monserveur backups_prod]# df -h
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/sda1             2,0G  271M  1,6G  15% /
/dev/mapper/vg_root-lv_sigexpl
                      496M   19M  452M   4% /sigexpl
/dev/mapper/vg_root-lv_tmp
                      992M   34M  908M   4% /tmp
/dev/mapper/vg_root-lv_app
                      9,7G  3,6G  5,7G  39% /app
/dev/mapper/vg_root-lv_home
                      2,0G   68M  1,8G   4% /home
/dev/mapper/vg_root-lv_usr
                      4,9G  1,3G  3,4G  27% /usr
/dev/mapper/vg_root-lv_var
                      4,9G  295M  4,4G   7% /var
tmpfs                  12G     0   12G   0% /dev/shm
/dev/mapper/vg_root-lv_pgdata
                      637G  537G   69G  89% /app/pgdata

#35 Re : Général » pgdump sans index ? » 21/01/2013 10:56:24

gom

Bonjour,


Merci.


J'ai encore un problème ... j'ai à priori saturé l'espace disque :


pg_restore: [programme d'archivage (db)] Erreur à  partir de l'entrée TOC 4148 ; 0 0 ACL table_1 user_dwh
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  n'a pas pu étendre la relation base/19635/1259 : Aucun espace disponible sur le périphérique
ASTUCE : Vérifiez l'espace disque disponible.
    Command was: REVOKE ALL ON TABLE table_1 FROM PUBLIC;
REVOKE ALL ON TABLE table_1 FROM user_dwh;
GRANT ALL...
pg_restore: [programme d'archivage (db)] Erreur à  partir de l'entrée TOC 4149 ; 0 0 ACL table_2 user_dwh
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  n'a pas pu étendre la relation base/19635/1259 : Aucun espace disponible sur le périphérique
ASTUCE : Vérifiez l'espace disque disponible.
    Command was: REVOKE ALL ON TABLE table_2 FROM PUBLIC;
REVOKE ALL ON TABLE table_2 FROM user_dwh...
pg_restore: [programme d'archivage (db)] Erreur à  partir de l'entrée TOC 4150 ; 0 0 ACL pg_stat_statements postgres
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  la relation « pg_stat_statements » n'existe pas
    Command was: REVOKE ALL ON TABLE pg_stat_statements FROM PUBLIC;
REVOKE ALL ON TABLE pg_stat_statements FROM postgres;
GRANT ALL ON TABLE...
ATTENTION : erreurs ignorées lors de la restauration : 800


Ces commandes me disent que "non" je n'ai pas saturé le disque ! Je ne comprends pas (oui encore !). hmm


[root@monserveur backups_prod]# fdisk -l

Disque /dev/sda: 730.8 Go, 730815528960 octets
255 heads, 63 sectors/track, 88849 cylinders
Unités = cylindres de 16065 * 512 = 8225280 octets

Périphérique Amorce    Début         Fin      Blocs    Id  Systême
/dev/sda1   *           1         261     2096451   83  Linux
/dev/sda2             262       88849   711583110   8e  Linux LVM
[root@monserveur backups_prod]# mount
/dev/sda1 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/mapper/vg_root-lv_sigexpl on /sigexpl type ext3 (rw,noatime)
/dev/mapper/vg_root-lv_tmp on /tmp type ext3 (rw,noatime)
/dev/mapper/vg_root-lv_app on /app type ext3 (rw,noatime)
/dev/mapper/vg_root-lv_home on /home type ext3 (rw,noatime)
/dev/mapper/vg_root-lv_usr on /usr type ext3 (rw,noatime)
/dev/mapper/vg_root-lv_var on /var type ext3 (rw,noatime)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/mapper/vg_root-lv_pgdata on /app/pgdata type ext3 (rw,noatime)
[root@monserveur backups_prod]# du / -s -h
542G    /
[root@monserveur backups_prod]# du /app -s -h
540G    /app
[root@monserveur backups_prod]# du /app/pgdata -s -h
537G    /app/pgdata
[root@monserveur backups_prod]# du /app/pgdata/backups_prod/ -s -h
410G    /app/pgdata/backups_prod/
[root@monserveur backups_prod]# du /app/pgdata/base -s -h
127G    /app/pgdata/base
[root@monserveur backups_prod]# df
Sys. de fich.        1K-blocs       Occupé Disponible Capacité Monté sur
/dev/sda1              2030736    276512   1649404  15% /
/dev/mapper/vg_root-lv_sigexpl
                        507748     18768    462766   4% /sigexpl
/dev/mapper/vg_root-lv_tmp
                       1015704     34108    929168   4% /tmp
/dev/mapper/vg_root-lv_app
                      10157368   3673332   5959748  39% /app
/dev/mapper/vg_root-lv_home
                       2031440     68720   1857864   4% /home
/dev/mapper/vg_root-lv_usr
                       5078656   1281392   3535120  27% /usr
/dev/mapper/vg_root-lv_var
                       5078656    301344   4515168   7% /var
tmpfs                 12337992         0  12337992   0% /dev/shm
/dev/mapper/vg_root-lv_pgdata
                     667880040 562492588  71469132  89% /app/pgdata



Gôm

#36 Re : Général » pgdump sans index ? » 20/01/2013 22:29:53

gom
Marc Cousin a écrit :

Le contrib pg_stat_statement est installé sur le serveur de départ, mais pas sur celui d'arrivée (il doitmanquer le packages de contribs postgres sur le serveur d'arrivée). Si vous voulez l'activer sur le serveur d'arrivée il faudra aussi le mettre dans shared_preload_libraries, dans le fichiers postgresql.conf, comme sur le serveur de départ.

Bonjour,

Est-ce que cela empêche la restauration des données ?

Je ne peux malheureusement pas me connecter pour l'instant pour m'en assurer avec pg_stat_activity.

Merci messieurs pour votre aide ! wink

Et c'est bien noté pour le pg_dumpall ! smile


Gôm

#37 Re : Général » pgdump sans index ? » 18/01/2013 18:59:50

gom

Dernière question ... comment savoir si les données sont en train d'être chargées ? En bref : suivre la restauration des données.


Le "psql -l" m'a effectivement permis de constater que ma base a bien été créée. Merci Marc ! smile

#38 Re : Général » pgdump sans index ? » 18/01/2013 18:53:49

gom

Merci Guillaume.

Le problème est que j'ai eu à créer tous les users et les répertoires pour les tablespaces ... sinon le restore fonctionnait pas ... "forcément" vous allez dire, mais fallait-il encore savoir que pg_restore n'allait pas le faire. Encore que pour les tablespaces j'aurais pu m'en douter ! roll


Bon par contre j'ai encore des erreurs, qu'en pensez-vous ?


[root@monserveur pgdata]# pg_restore mabase_infocentre_20121211.tar -U postgres -C -d postgres
pg_restore: [archiveur] n'a pas pu ouvrir le fichier en entrée « mabase_infocentre_20121211.tar » : Aucun fichier ou répertoire de ce type
[root@monserveur pgdata]# pg_restore backups_prod/mabase_infocentre_20121211.tar -U postgres -C -d postgres
pg_restore: [programme d'archivage (db)] Erreur pendant le traitement de la TOC (« PROCESSING TOC ») :
pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 32 ; 1255 17753 FUNCTION pg_stat_statements() postgres
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  n'a pas pu accéder au fichier « $libdir/pg_stat_statements » : Aucun fichier ou répertoire de ce type
    Command was: CREATE FUNCTION pg_stat_statements(OUT userid oid, OUT dbid oid, OUT query text, OUT calls bigint, OUT total_time double pre...
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  la fonction public.pg_stat_statements() n'existe pas
    Command was: ALTER FUNCTION public.pg_stat_statements(OUT userid oid, OUT dbid oid, OUT query text, OUT calls bigint, OUT total_time doub...
pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 33 ; 1255 17752 FUNCTION pg_stat_statements_reset() postgres
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  n'a pas pu accéder au fichier « $libdir/pg_stat_statements » : Aucun fichier ou répertoire de ce type
    Command was: CREATE FUNCTION pg_stat_statements_reset() RETURNS void
    LANGUAGE c
    AS '$libdir/pg_stat_statements', 'pg_stat_stateme...
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  la fonction public.pg_stat_statements_reset() n'existe pas
    Command was: ALTER FUNCTION public.pg_stat_statements_reset() OWNER TO postgres;


pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2636 ; 1259 17754 VIEW pg_stat_statements postgres
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  la fonction pg_stat_statements() n'existe pas
LIGNE 2 : ...atements.total_time, pg_stat_statements.rows FROM pg_stat_st...
                                                               ^
ASTUCE : Aucune fonction ne correspond au nom donné et aux types d'arguments.
Vous devez ajouter des conversions explicites de type.
    Command was: CREATE VIEW pg_stat_statements AS
    SELECT pg_stat_statements.userid, pg_stat_statements.dbid, pg_stat_statements.query, p...
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  la relation « public.pg_stat_statements » n'existe pas
    Command was: ALTER TABLE public.pg_stat_statements OWNER TO postgres;

#39 Re : Général » pgdump sans index ? » 18/01/2013 17:46:12

gom

Merci Marc !


J'ai donc lancé cette commande (après avoir édité mon "postgresql.conf" et fait un reload) : 

pg_restore mabase_infocentre_20121211.tar -U postgres -C

Comment savoir si ma base a bien été créée au début de la restauration et que maintenant les données sont en train d'être restaurées ?



Gôm

#40 Re : Général » pgdump sans index ? » 18/01/2013 16:50:08

gom

Sinon (plus simple), je peux faire ça, non ?


pg_restore mabase_infocentre_20121211.tar -C -U postgres -w

#41 Re : Général » pgdump sans index ? » 18/01/2013 16:36:13

gom

Cette commande est bonne ?

pg_restore mabase_infocentre_20121211.tar -U postgres -w -d mabase_infocentre

J'ai retrouvé un paramétrage que vous m'aviez donné en 2010.

# - Specifique restauration -
fsync = off
checkpoint_segments = 200
checkpoint_timeout = 20min
maintenance_work_mem = 1GB


Est-il toujours valable ? Puis-je le mettre en place simplement en éditant "postgresql.conf" ?


Comment savoir quelles bases sont présentes sur mon serveur (en lignes de commandes Linux) ?

#42 Re : Général » pgdump sans index ? » 18/01/2013 16:17:58

gom

Bonjour,


La commande a pu être passée chez le client sans problème particulier ... par contre la restauration a été une autre histoire ! sad Il m'a été impossible de déchiffrer le dump à partir du compte root. Je ne sais toujours pas pourquoi ... personne en interne n'a été capable de m'aider. J'ai donc copier le dump sur un serveur Windows où j'ai installé PGP et j'ai déchiffré sur Windows ... avant de tout renvoyer sur le serveur Linux !! roll


Au final la restauration a duré 6 jours ... oui oui 6 jours (sans compter le temps de déchiffrage et de décompression) ! Tout le contenu du dump s'affichait sur la sortie standard. Je ne sais pas si c'est normal. hmm


J'ai restauré ainsi : 


pg_restore mabase_infocentre_20121211.tar -U postgres -w

Ai-je fait une erreur n'y avait-il pas un moyen d'accélérer les choses ?


2ème et dernière question : comment se fait-il que je ne puisse pas accéder à la base que je viens de restaurer ? Le user qui a été restauré en même temps que la base n'est, apparemment, pas utilisable depuis PgAdmin sur mon PC sous Windows. Je ne peux utiliser que le user "postgres", le problème est que ce user n'a accès qu'à la base "postgres".


Que dois-je modifier pour que mon user "user_infocentre" soit utilisable depuis mon PC ?



Merci d'avance ! smile


Gôm

#43 Re : Optimisation » Requête à optimiser » 18/01/2013 15:13:24

gom

Désolé moi aussi pour le temps de réponse !


Le problème est résolu grâce à un changement fonctionnel. Techniquement rien n'a pu être fait pour améliorer les choses !

#44 Re : Optimisation » Requête à optimiser » 28/12/2012 19:05:53

gom

J'ai fait ça :


DROP INDEX index_cible;

VACUUM FULL ANALYZE table_cible;

CREATE INDEX index_cible
  ON table_cible
  USING btree
  (anneesem);


Malheureusement, j'ai peur que cela ne change rien, parce qu'en fait si le plan d'exécution change c'est simplement par que les semaines dont je parlais n'existent pas dans la table ! sad


anneesem;count(*)
"2012S51";145345
"2012S50";146918
"2012S49";145560
"2012S48";143669
"2012S47";142365
"2012S46";142066
"2012S45";142442
"2012S44";140548

#45 Re : Optimisation » Requête à optimiser » 28/12/2012 18:40:56

gom

Non je n'ai pas essayé.


Faire un "VACUUM ANALYZE table_cible" ?

#46 Re : Optimisation » Requête à optimiser » 28/12/2012 18:20:17

gom

Bonjour,


Marc Cousin a écrit :

PostgreSQL n'essaye pas de déduire des informations dues à la transitivité des opérateurs, pour les inégalités. Il ne le fait que pour les égalités.

Il ne va pas déduire de

  join table_source b on (a.code = b.code and '2011S02' <= b.annee_semaine and b.annee_semaine <= a.annee_semaine)
    where a.annee_semaine = '2012S01'

que

b.annee_semaine <= '2012S01'

Je ne suis pas sûr que ça puisse avoir un impact énorme sur la requête, mais pouvez-vous essayer de remplacer a.annee_semaine par '2012S01' dans la clause de jointure, et réessayer (et nous montrer le nouveau plan) ?


Non cela ne change rien ... malheureusement !


Voici 2 explain (les explain analyze sont en cours) de la même requête mais avec une condition différente.


Temps de réponse catastrophiques ! sad

"Bitmap Heap Scan on table_cible aa  (cost=2231.66..7442511.43 rows=143138 width=60)"
"  Recheck Cond: ((anneesem)::text = '2012S44'::text)"
"  ->  Bitmap Index Scan on index_cible  (cost=0.00..2195.88 rows=143138 width=0)"
"        Index Cond: ((anneesem)::text = '2012S44'::text)"
"  SubPlan 1"
"    ->  GroupAggregate  (cost=0.00..51.87 rows=1 width=26)"
"          ->  Result  (cost=0.00..51.84 rows=2 width=26)"
"                One-Time Filter: (($1)::text = '2012S44'::text)"
"                ->  Nested Loop  (cost=0.00..51.84 rows=2 width=26)"
"                      ->  Index Scan using index_source on table_source a  (cost=0.00..24.89 rows=1 width=22)"
"                            Index Cond: (((dwh_gtin)::text = ($0)::text) AND ((dwh_anneesem)::text = '2012S44'::text))"
"                      ->  Index Scan using index_source on table_source b  (cost=0.00..26.93 rows=2 width=26)"
"                            Index Cond: (((b.dwh_gtin)::text = ($0)::text) AND ('2012S45'::text <= (b.dwh_anneesem)::text) AND ((b.dwh_anneesem)::text <= (a.dwh_anneesem)::text))"

Temps de réponse exceptionnels !! smile Mais pourquoi ?! neutral

"Index Scan using index_cible on table_cible aa  (cost=0.00..56.24 rows=1 width=60)"
"  Index Cond: ((anneesem)::text = '2012S43'::text)"
"  SubPlan 1"
"    ->  GroupAggregate  (cost=0.00..51.87 rows=1 width=26)"
"          ->  Result  (cost=0.00..51.84 rows=2 width=26)"
"                One-Time Filter: (($1)::text = '2012S43'::text)"
"                ->  Nested Loop  (cost=0.00..51.84 rows=2 width=26)"
"                      ->  Index Scan using index_source on table_source a  (cost=0.00..24.89 rows=1 width=22)"
"                            Index Cond: (((dwh_gtin)::text = ($0)::text) AND ((dwh_anneesem)::text = '2012S43'::text))"
"                      ->  Index Scan using index_source on table_source b  (cost=0.00..26.93 rows=2 width=26)"
"                            Index Cond: (((b.dwh_gtin)::text = ($0)::text) AND ('2012S44'::text <= (b.dwh_anneesem)::text) AND ((b.dwh_anneesem)::text <= (a.dwh_anneesem)::text))"

La seule différence est que la deuxième requête a comme condition '2012S43' sur "table_cible". J'obtiens le même plan d'exécution pour toutes les semaines antérieures à '2012S43' jusqu'à '2012S01'.


Le passage à la semaine '2012S44' serait la goutte qui fait déborder le vase imploser PostgreSQL ?!



Gôm

#47 Re : Général » Estimer la fragmentation (en pourcentage) de tous mes index ? » 12/12/2012 01:05:53

gom

Merci.


Etant en version 8.4 "basique" je dois commencer par installer cette extension. C'est bien cela ?


http://www.postgresql.org/docs/8.4/static/contrib.html



Gôm

#48 Général » Estimer la fragmentation (en pourcentage) de tous mes index ? » 11/12/2012 18:17:37

gom
Réponses : 4

Bonjour,

Savez-vous si c'est possible via une requête SQL ?

Je sais le faire en SQL Server mais pas en PostgreSQL. sad

J'ai bien lu ça : http://www.dalibo.org/glmf109_operation … postgresql, puis ça : http://blog.guillaume.lelarge.info/inde … gstattuple mais ça ne répond pas à mon besoin.


Gôm

#49 Re : Général » pgdump sans index ? » 30/11/2012 19:03:23

gom

La commande ne peut pas aller à son terme je n'ai pas assez d'espace disque sur mon serveur de tests. Tant pis je vais livrer la commande et le client va la tester sur son serveur de Recette.



Merci pour tout. smile


Gôm

#50 Re : Général » pgdump sans index ? » 29/11/2012 13:02:01

gom

Mon fichier ne fait que 459 Ko (ou 459 Mo ?) ? Si c'est ça alors l'espace disque restant sur mon serveur est un peu inquiétant, non ?!!



Gôm

Pages : 1 2 3 4 5 6

Pied de page des forums

Propulsé par FluxBB