Vous n'êtes pas identifié(e).
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
Hors ligne
Bonjour,
n'y aurait-il pas un problème d'oomkiller ?
Par exemple le système linux qui tue des process postgresql par manque de ressources (à cause notamment d'un trop grand nombre de jobs par pg_restore (l'option -j)).
Que valent les paramètres overcommit.xxx sur votre nouveau serveur ? par rapport à l'ancien ?
Cordialement,
Sébastien.
Hors ligne
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 !
Hors ligne
Bonjour,
plus d'info ici :
https://www.kernel.org/doc/Documentatio … accounting
mais il faut regarder :
/proc/sys/vm/overcommit_memory
This file contains the kernel virtual memory accounting mode.
Values are:
0: heuristic overcommit (this is the default)
1: always overcommit, never check
2: always check, never overcommit
si ta valeur est à 0 alors tes process peuvent être tués par oom killer.
Cordialement,
Sébastien.
Hors ligne
en complément, c'est documenter aussi (en français ;-) ) dans la doc officielle :
https://docs.postgresql.fr/15/kernel-re … OVERCOMMIT
bonne lecture.
(mais en dehors de ça, il ne faut pas être trop gourmand avec le paramètre -j de pg_dump et pg_restore, c'est vraiment en fonction des ressources du serveur)
Cordialement,
Sébastien.
Hors ligne
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
Hors ligne