Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
j'ai un souci sur la restauration des base de données.
j'utilise pgAdmin pour faire ma restauration et pour une base de 9Mo il me faut 45min (2Go plus de 24h).
Ma configuration est :
PostgreSQL : 9.2
Système: Windows 2012 (Mon système est virtualisé)
Temps d'activité du disque: 90%
Vitesse écriture: 1.5Mo
Processeur (4Proc virtuel): 7%
Mémoire: 16G dont 1.8 Utilisée
mon fichier postgresql.conf: (ces lignes sont bien commentées)
#checkpoint_segments = 3 # in logfile segments, min 1, 16MB each
#checkpoint_timeout = 5min # range 30s-1h
#checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0
#checkpoint_warning = 30s # 0 disables
Avez vous une idée pour arriver à des temps correct ?
quelle sont les bonnes pratique pour le chekpoint_segments ?
Désoler si je suis passé à coté d'un sujet déjà existant
merci
Hors ligne
Je crois que le problème est plus grave qu'une simple configuration de PostgreSQL.
Je prends une 9.2 de base, avec une configuration de base. Je crée une base de 352 Mo (soit 39 fois plus grosse que la votre), très simpliste. Je la sauvegarde, je la restaure. Durée de la restauration : 11 secondes. ONZE SECONDES. Je vous accorde que je ne suis pas sur windows. Je vous accorde aussi qu'un PostgreSQL sous Linux a des chances d'être plus rapide que le même PostgreSQL sous Windows. Mais j'ai du mal à croire que ça fasse une telle différence.
Le seul point qui pourrait expliquer une énorme lenteur, c'est si votre sauvegarde (ou plutôt votre restauration) passe par des INSERT au lieu des COPY habituels. En dehors de ça, regardez plutôt au niveau de la machine (et quoiqu'on vous dise, la supervision, c'est pas pour avoir de meilleures performances).
Guillaume.
Hors ligne
Un test vite fait montre que la restauration d'une sauvegarde avec INSERT est énormément plus lente. Reste à savoir ce qu'il en est pour vous.
Guillaume.
Hors ligne
Bonjour,
ah oui ... 
11 petite minuscule seconde .......
Le seul point qui pourrait expliquer une énorme lenteur, c'est si votre sauvegarde (ou plutôt votre restauration) passe par des INSERT au lieu des COPY habituels.
effectivement mes sauvegardes sont faites avec des INSERT
j'ai lu ici http://forums.postgresql.fr/viewtopic.php?id=2507 une personne qui avait des soucis de temps (bon je suis pas dans le même contexte et c'est pas la même taille de base de données)
la configuration qui avait été choisi pour lui était celle-ci
# - Specifique UPDATE massif -
maintenance_work_mem = 2GB
wal_buffers = 32MB
#fsync = on
synchronous_commit = off
checkpoint_segments = 200
checkpoint_timeout = 20min
checkpoint_warning = 0
Effectivement le faite de mettre "synchronous_commit = off" me fait passer à moins de 1min pour ma base de 9Mo.
Après est ce que tout ça rentre dans les bonnes pratique ? je sais pas ...
Hors ligne
La première question à se poser est pourquoi utiliser l'option --inserts. En dehors de pouvoir utiliser le dump avec un autre moteur de bases de données, je ne vois que des désagréments.
Guillaume.
Hors ligne
Bonjour,
je reviens vers vous après avoir du mettre de coté la restauration et sauvegarde de ma base de donnée.
voici donc comment est sauvegardé ma base de donnée
pg_dump.exe --host localhost --port 5432 --username postgres --format custom --blobs --column-inserts --disable-dollar-quoting --file D:\exportBDD\Base_de_test.backup "db_base_test"
une fois la sauvegarde effectuée la restauration d'une base d’environ 1,7G me prenait au moins 48h !!
comme je le disais plus haut en modifiant les paramètres du fichier postgresql.conf cela ma permis de diminuer le temps de restauration
Paramètre modifié
# - Specifique UPDATE massif -
maintenance_work_mem = 2GB
wal_buffers = 32MB
#fsync = on
synchronous_commit = off
checkpoint_segments = 200
checkpoint_timeout = 20min
checkpoint_warning = 0
j'ai pris note de votre remarque gleu et j'ai donc retiré le paramètre --column-inserts de ma commande de sauvegarde
pg_dump.exe --host localhost --port 5432 --username postgres --format custom --blobs --disable-dollar-quoting --file D:\exportBDD\Base_de_test.backup "db_base_test"
je suis passer à une restauration de 20min 
Je me permet d’alourdir mon message avec un extrait de mon fichier postgresql.conf afin que vous pussiez si possible me conseiller sur les bonnes pratiques à adopter pour optimiser mon serveur.
Extrait Postgresql.conf
#------------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#------------------------------------------------------------------------------
# - Memory -
shared_buffers = 32MB # min 128kB
# (change requires restart)
#temp_buffers = 8MB # min 800kB
#max_prepared_transactions = 0 # zero disables the feature
# (change requires restart)
# Note: Increasing max_prepared_transactions costs ~600 bytes of shared memory
# per transaction slot, plus lock space (see max_locks_per_transaction).
# It is not advisable to set max_prepared_transactions nonzero unless you
# actively intend to use prepared transactions.
#work_mem = 1MB # min 64kB
maintenance_work_mem = 1GB # min 1MB
#max_stack_depth = 2MB # min 100kB
# - Disk -
#temp_file_limit = -1 # limits per-session temp file space
# in kB, or -1 for no limit
# - Kernel Resource Usage -
#max_files_per_process = 1000 # min 25
# (change requires restart)
#shared_preload_libraries = '' # (change requires restart)
# - Cost-Based Vacuum Delay -
#vacuum_cost_delay = 0ms # 0-100 milliseconds
#vacuum_cost_page_hit = 1 # 0-10000 credits
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 1-10000 credits
# - Background Writer -
#bgwriter_delay = 200ms # 10-10000ms between rounds
#bgwriter_lru_maxpages = 100 # 0-1000 max buffers written/round
#bgwriter_lru_multiplier = 2.0 # 0-10.0 multipler on buffers scanned/round
# - Asynchronous Behavior -
#effective_io_concurrency = 1 # 1-1000; 0 disables prefetching
#------------------------------------------------------------------------------
# WRITE AHEAD LOG
#------------------------------------------------------------------------------
# - Settings -
#wal_level = minimal # minimal, archive, or hot_standby
# (change requires restart)
#fsync = on # turns forced synchronization on or off
synchronous_commit = off # synchronization level;
# off, local, remote_write, or on
#wal_sync_method = fsync # the default is the first option
# supported by the operating system:
# open_datasync
# fdatasync (default on Linux)
# fsync
# fsync_writethrough
# open_sync
#full_page_writes = on # recover from partial page writes
wal_buffers = 32MB # min 32kB, -1 sets based on shared_buffers
# (change requires restart)
#wal_writer_delay = 200ms # 1-10000 milliseconds
#commit_delay = 0 # range 0-100000, in microseconds
#commit_siblings = 5 # range 1-1000
# - Checkpoints -
checkpoint_segments = 200 # in logfile segments, min 1, 16MB each
checkpoint_timeout = 20min # range 30s-1h
#checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0
checkpoint_warning = 0 # 0 disables
# - Archiving -
#archive_mode = off # allows archiving to be done
# (change requires restart)
#archive_command = '' # command to use to archive a logfile segment
# placeholders: %p = path of file to archive
# %f = file name only
# e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
#archive_timeout = 0 # force a logfile segment switch after this
# number of seconds; 0 disables
#------------------------------------------------------------------------------
# REPLICATION
#------------------------------------------------------------------------------
# - Sending Server(s) -
# Set these on the master and on any standby that will send replication data.
#max_wal_senders = 0 # max number of walsender processes
# (change requires restart)
#wal_keep_segments = 0 # in logfile segments, 16MB each; 0 disables
#replication_timeout = 60s # in milliseconds; 0 disables
# - Master Server -
# These settings are ignored on a standby server.
#synchronous_standby_names = '' # standby servers that provide sync rep
# comma-separated list of application_name
# from standby(s); '*' = all
#vacuum_defer_cleanup_age = 0 # number of xacts by which cleanup is delayed
# - Standby Servers -
# These settings are ignored on a master server.
#hot_standby = off # "on" allows queries during recovery
# (change requires restart)
#max_standby_archive_delay = 30s # max delay before canceling queries
# when reading WAL from archive;
# -1 allows indefinite delay
#max_standby_streaming_delay = 30s # max delay before canceling queries
# when reading streaming WAL;
# -1 allows indefinite delay
#wal_receiver_status_interval = 10s # send replies at least this often
# 0 disables
#hot_standby_feedback = off # send info from standby to prevent
# query conflicts
#------------------------------------------------------------------------------
# AUTOVACUUM PARAMETERS
#------------------------------------------------------------------------------
#autovacuum = on # Enable autovacuum subprocess? 'on'
# requires track_counts to also be on.
#log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
# their durations, > 0 logs only
# actions running at least this number
# of milliseconds.
#autovacuum_max_workers = 3 # max number of autovacuum subprocesses
# (change requires restart)
#autovacuum_naptime = 1min # time between autovacuum runs
#autovacuum_vacuum_threshold = 50 # min number of row updates before
# vacuum
#autovacuum_analyze_threshold = 50 # min number of row updates before
# analyze
#autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum
#autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum
# (change requires restart)
#autovacuum_vacuum_cost_delay = 20ms # default vacuum cost delay for
# autovacuum, in milliseconds;
# -1 means use vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
# autovacuum, -1 means use
# vacuum_cost_limit
Merci à vous
Hors ligne
Selon moi le meilleur moyen d'optimiser votre serveur serait de le passer sous linux Sinon, sans connaître les caractéristiques du serveur et des disques, impossible de vous aider.
Julien.
https://rjuju.github.io/
Hors ligne
je peux uniquement modifier ce qui est logiciel.
Système ou matériel physique ne peuvent être modifié.
Windows 2012 x64 (Virtualisé)
16G Ram
Intel Xeon 1.90 Ghz (4 Processeur virtuel)
il est virtualisé via Hyper-V sur un serveur windows 2012 qui est configuré en raid 5
Hors ligne
Sans vouloir sans lancer dans une guerre de tranchés sur les OS et la virtualisation, je dirais diplomatiquement qu'avec Windows sur un serveur virtualisé et avec du RAID-5, vous avez mis toutes les chances de votre côté pour ne pas avoir des performances de folie.
Ceci étant dit, je vous conseille d'augmenter le shared_buffers en le passant à 256 Mo. Le reste ne peut pas se configurer sans comprendre ce que font les applicatifs avec le serveur.
Guillaume.
Hors ligne
Pages : 1
