Vous n'êtes pas identifié(e).
Pages : 1
Merci pour toutes ces infos.
Je vais regarder tout ça, et oui je vais faire d'autres types de comparaison de perf. (appli / requetes) pour m'assurer de la bonne config du nouveau serveur 
Bonne Journée
Bonjour
Merci pour votre réponse.
Alors en effet j'ai globalement un peu moins de ram coté nouveau serveur / l'ancien (256Gb vs 392Gb) et pour les valeurs de l'overcommit j'avoue que je ne connais. Est-ce bien les valeurs CommitLimit de /proc/memInfo ?
Voici ce que sur les 2 serveurs dans memInfo
Ancien Serveur Nouveau Serveur
MemTotal: 396038428 kB 263416368 kB
MemFree: 1518052 kB 157093180 kB
MemAvailable: 318555424 kB 258382888 kB
Buffers: 1112 kB 265444 kB
Cached: 347185344 kB 99559376 kB
SwapCached: 128892 kB 3812 kB
Active: 135375024 kB 12263820 kB
Inactive: 250167600 kB 87594368 kB
Active(anon): 67532096 kB 636372 kB
Inactive(anon): 5375748 kB 518896 kB
Active(file): 67842928 kB 11627448 kB
Inactive(file): 244791852 kB 87075472 kB
Unevictable: 0 kB 0 kB
Mlocked: 0 kB 0 kB
SwapTotal: 6290428 kB 4194300 kB
SwapFree: 4822336 kB 4023804 kB
Dirty: 10344 kB 1664 kB
Writeback: 0 kB 0 kB
AnonPages: 38237712 kB 29668 kB
Mapped: 34280832 kB 563568 kB
Shmem: 34551384 kB 1121240 kB
Slab: 5764996 kB 3630048 kB
SReclaimable: 5540748 kB 3471012 kB
SUnreclaim: 224248 kB 159036 kB
KernelStack: 20144 kB 7488 kB
PageTables: 436444 kB 11332 kB
NFS_Unstable: 0 kB 0 kB
Bounce: 0 kB 0 kB
WritebackTmp: 0 kB 0 kB
CommitLimit: 204309640 kB 135902484 kB
Committed_AS: 81584852 kB 27369240 kB
VmallocTotal: 34359738367 kB 34359738367 kB
VmallocUsed: 1105560 kB 705064 kB
VmallocChunk: 34157101052 kB 34224742396 kB
HardwareCorrupted: 0 kB 0 kB
AnonHugePages: 1689600 kB 4096 kB
HugePages_Total: 0 0
HugePages_Free: 0 0
HugePages_Rsvd: 0 0
HugePages_Surp: 0 0
Hugepagesize: 2048 kB 2048 kB
DirectMap4k: 273344 kB 237540 kB
DirectMap2M: 12263424 kB 5492736 kB
DirectMap1G: 392167424 kB 264241152 kB
Pour CommitLimit la différence n'est pas énorme mais plus marquée pour Committed_AS... Je vais regarder a quoi cela correspond, mais si vous voyez quelque chose qui pourrait expliquer le problème je suis preneuse 
Merci !
Bonjour,
Je suis en train de transférer un serveur postgresql d'une machine (Serveur1) à une autre (Serveur2) et j'en profite donc pour faire un upgrade de la version de PG....
Après qq tests j'ai décidé d'utiliser pg_dump/pg_restore pour le transfert des données en utilisant les options "-F d et -J XXX"
Les serveurs sont sous linux CentOS 7, et les versions de PG sont
* serveur1 : Pg 9.2 - Linux yyyy 3.10.0-1160.83.1.el7.x86_64 #1 SMP Tue Jan 24 08:34:19 CST 2023 x86_64 x86_64 x86_64 GNU/Linux
* serveur2: Pg 15 - Linux xxxx 3.10.0-1160.83.1.el7.x86_64 #1 SMP Tue Jan 24 08:34:19 CST 2023 x86_64 x86_64 x86_64 GNU/Linux
Pour la migration, je me suis connectée sur le serveur2 et j'ai lancé la commande suivante, dans un batch pour les 260 bases (ce qui fait ~6To)
/usr/bin/pg_dump -v -j 380 -F d -h serveur1 -p 5432 -U pgAdmin -d "$db" -f "$bkpdir/$db" OK !
J'ai ensuite lancé la commande pour la restauration, toujours dans un batch:
/usr/bin/pg_restore -v -j 300 -F d -U postgres -d "$dbname" "$dbname" Et j'ai les erreurs suivantes lors de la restauration :
restore: processing item 2922 DEFAULT scan id
pg_restore: creating DEFAULT "public.scan id"
pg_restore: processing item 2924 DEFAULT theoretical_feature id
pg_restore: creating DEFAULT "public.theoretical_feature id"
pg_restore: processing item 2925 DEFAULT tile id
pg_restore: creating DEFAULT "public.tile id"
pg_restore: error: reconnection failed: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: Resource temporarily unavailable
Is the server running locally and accepting connections on that socket?
pg_restore: error: reconnection failed: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: Resource temporarily unavailable
Is the server running locally and accepting connections on that socket?
pg_restore: error: reconnection failed: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: Resource temporarily unavailable
* En descendant la valeur de -j à 220 c'est OK !
* J'ai fait des tests de pg_dump depuis mon serveur PG15 et j'ai le meme problème si je mets une valeur de -j > 220 (je n'ai pas cherché la limite exacte). Donc ce n'est pas pg_restore qui est plus sensible que pg_dump...
Sur le nouveau serveur la configuration et celle d'origine avec les changements suivants (j'ai entre autre utilisé pgtune):
A noter que j'ai 256Go de Ram, 2 proc 8Coeurs, et des disques SSD.
listen_addresses = '*'
max_connections = 500
tcp_keepalives_idle = 300shared_buffers = 32GB
huge_pages = try
work_mem = 100MB
maintenance_work_mem = 2GB
effective_cache_size = 100GB
random_page_cost = 1.1
effective_io_concurrency = 200default_statistics_target = 500
max_worker_processes = 16
max_parallel_workers_per_gather = 8
max_parallel_maintenance_workers = 4
max_parallel_workers = 16
checkpoint_completion_target = 0.9wal_buffers = 16MB
max_wal_size = 16GB
min_wal_size = 4GBlog_min_duration_statement = 5000
log_checkpoints = on
log_connections = on
log_disconnections = on
log_duration = off
log_lock_waits = on
Sur mon ancien serveur j'ai une configuration équivalente (notamment au niveau du max_connection). J'ai cherché un peu de droite de gauche pour savoir d'où pouvait venir le problème en vain. Même si un max_connection à 500 n'est peut être pas optimal, ce qui me gène c'est d'avoir un comportement moins bon sur le nouveau serveur !!
A noter le pg_dump du serveur1 depuis le serveur2 se fait donc au travers du réseau ... moins rapide ... est-ce que cela pourrait avoir un lien ?!
Est-ce qu'il pourrait y avoir une raison au niveau du serveur lui même (kernel ?)
Merci par avance pour votre aide !
Bonne Journée
Pages : 1