Re: 15 pg_upgrade with -j

Jeff Ross <jross@openvistas.net>

From: Jeff Ross <jross@openvistas.net>
To: pgsql-general@lists.postgresql.org
Date: 2023-05-22T23:29:39Z
Lists: pgsql-general
On 5/22/23 5:24 PM, Adrian Klaver wrote:
> On 5/22/23 16:20, Jeff Ross wrote:
>> Hello!
>>
>> We are moving from 10 to 15 and are in testing now.
>>
>> Our development database is about 1400G and takes 12 minutes to 
>> complete a pg_upgrade with the -k (hard-links) version. This is on a 
>> CentOS 7 server with 80 cores.
>>
>> Adding -j 40 to use half of those cores also finishes in 12 minutes 
>> and ps / top/ htop never show more than a single process at a time in 
>> use.
>>
>> Bumping that to -j 80 to use them all also finishes in 12 minutes and 
>> still only a single process.
>>
>> Running the suggested vacuum analyze after pg_upgrade completes takes 
>> about 19 minutes.  Adding -j 40 takes that time down to around 5 
>> minutes, jumps the server load up over 30 and htop shows 40 processes.
>>
>> If -j 40 helps there--why not with pg_upgrade?
>
> From docs:
>
> https://www.postgresql.org/docs/current/pgupgrade.html
>
> The --jobs option allows multiple CPU cores to be used for 
> copying/linking of files and to dump and restore database schemas in 
> parallel; a good place to start is the maximum of the number of CPU 
> cores and tablespaces. This option can dramatically reduce the time to 
> upgrade a multi-database server running on a multiprocessor machine.
>
> So is the 1400G mostly in one database in the cluster?
>
>>
>> The full commands we are using for pg_upgrade are pretty stock:
>>
>> time /usr/pgsql-15/bin/pg_upgrade -b /usr/pgsql-10/bin/ -B 
>> /usr/pgsql-15/bin/ -d /var/lib/pgsql/10/data -D /var/lib/pgsql/15up -k
>> time /usr/pgsql-15/bin/pg_upgrade -b /usr/pgsql-10/bin/ -B 
>> /usr/pgsql-15/bin/ -d /var/lib/pgsql/10/data -D /var/lib/pgsql/15up 
>> -k -j 40
>> time /usr/pgsql-15/bin/pg_upgrade -b /usr/pgsql-10/bin/ -B 
>> /usr/pgsql-15/bin/ -d /var/lib/pgsql/10/data -D /var/lib/pgsql/15up 
>> -k -j 80
>>
>> Our production database is closer to 1900G.  If we're looking at a 30 
>> minute pg_upgrade window we'll be okay but if there is anything we 
>> can do to knock that time down we will and any suggestions to do so 
>> would be greatly appreciated.
>>
>> Jeff Ross
>
Yes, one big database with about 80 schemas and several other smaller 
databases so -j should help, right?

Jeff