Resolved Very slow migration

[manos]

Server operating system version

ALMALINUX 8.6

Plesk version and microupdate number

19.0.44

Hello,

Used to migrate sites from server to server very fast, suddenly started to take hours between a pair of servers


Source server (development) :
64G RAM, 8 Core, 1 gigabit uplink
CENTOS 7.9 latest
Plesk 18.0.44 Update #2
No active sites there only development so always cpu usage is 1-2%


Destination server (production) :
64G RAM, 8 Core, 1 gigabit uplink
ALMALINUX 8.6 latest
Plesk 18.0.44 Update #2
cpu usage is 10-15%, no active backup task


Migration stalls for hours at

Fetch configuration data from Plesk servers​

Any idea?

 

[manos]

Wrong thread, should be at linux, admins could you move it?

 

[IgorG]

Try to find more details with the help of migration logs: https://support.plesk.com/hc/en-us/articles/213403509#pmm

 

[manos]

Thanks Igor

Checked all, no errors just way too much time!

 

[manos]

Any idea?

 

[IgorG]

Any idea?

There are too few details.
I advise you to contact Plesk technical support. They will investigate the problem and find the cause directly on your server.

 

[Bitpalast]

An off-the-record idea to this: Try to create a full local backup on the source server, then analyze the backup runtime behavior using the free Plesk backup telemetrics extension. The process of migrating is very similar to the process of a full backup. When you have - for example - very many files, backing the up or migrating them can consume a lot of time. Some other factors might also come into play. One advantage of this test is that you will see whether transport or target server is the bottle neck or whether reading the source files is the bottle neck.

 

[manos]

An off-the-record idea to this: Try to create a full local backup on the source server, then analyze the backup runtime behavior using the free Plesk backup telemetrics extension. The process of migrating is very similar to the process of a full backup. When you have - for example - very many files, backing the up or migrating them can consume a lot of time. Some other factors might also come into play. One advantage of this test is that you will see whether transport or target server is the bottle neck or whether reading the source files is the bottle neck.

Hi,

Thanks for reply

Backup is very fast

 

[Bitpalast]

So it is either a network issue or a target server issue. I'd probably look into network packets next, if the connection is stable or if there are packet losses. You could do this by running these commands on BOTH of the machines vice versa to test against the other. There should not be any or only an insignifcant number of packet losses in both directions if the network connection is stable:

On the source server:
# /usr/sbin/mtr -s 1000 -r -c 1000 <ip of target server> > <name of log file, e.g. mtr_test.log>

At about the same time on the target server:
# /usr/sbin/mtr -s 1000 -r -c 1000 <ip of source server> > <name of log file, e.g. mtr_test.log>

This will run a while. Check the results to see if there are any significant number of packets lost or not.

If the test is bad, your data center needs to figure out why the routing between your servers does not work right. If the test is good, check if you have enabled software firewalls on source and target server. Disable them for a test and try the migration again.

 

[manos]

So it is either a network issue or a target server issue. I'd probably look into network packets next, if the connection is stable or if there are packet losses. You could do this by running these commands on BOTH of the machines vice versa to test against the other. There should not be any or only an insignifcant number of packet losses in both directions if the network connection is stable:

On the source server:
# /usr/sbin/mtr -s 1000 -r -c 1000 <ip of target server> > <name of log file, e.g. mtr_test.log>

At about the same time on the target server:
# /usr/sbin/mtr -s 1000 -r -c 1000 <ip of source server> > <name of log file, e.g. mtr_test.log>

This will run a while. Check the results to see if there are any significant number of packets lost or not.

If the test is bad, your data center needs to figure out why the routing between your servers does not work right. If the test is good, check if you have enabled software firewalls on source and target server. Disable them for a test and try the migration again.

Thank you very much for useful replies, good to know how to check such things

Both servers are at with 1 gigabit uplink at same network so it was not the issue

Finally found that the erroneous service plans asssgnments were the cause
as i described here:

Issue - Wrong statistics at service plan

I had delete 6 subscriptions from plesk panel but strangely there were still references for these 6 at
Subscriptions and PlansSubscriptions tables.

Did a psa db backup and removed the 6 entries from both tables, tested with 2 migrations and were really fast.

Thanks again for your time