Facebook
Twitter
- Server operating system version
- Debian 12
- Plesk version and microupdate number
- 18.0.60
We are planning to change some public IP addresses.
The /opt/psa/bin/reconfigurator tool is what the help pages recommend for plesk servers.
This tool appears to slow to a crawl when it gets to the following step; nothing has been printed for hours after this line;
I've written some queries to track its process. So far It's written 1234 out of ~4,000 DNS records in about 3 hours, an an offline test copy of the real environment (so with no traffic to contend with). It still has several thousand more to go. Suffice to say that it is unacceptably slow, when 'plesk bin repair dns' takes a minute at most, and a quick replace query
for A and AAAA records takes less than a second. Note that I know that the suggested tool does more than just change these db records, it's just that this particular step appears to be running much slower than even a naïve manual effort, such as exporting the dns_recs table to csv, find&replace with notepad++, then importing the csv, then repairing dns.
Running top reveals some sw-engine processes taking up a single cpu core equivalent worth of compute, at first, for the first 10 min or so. After this, cpu usage goes down to a minimum. After ~3hrs, about 4m37s of cpu time (4C/4T allocated) is used by the main sw-engine process.
Since I can't easily see what it's doing (/opt/psa/admin/plib/api-cli/ipmanage.php is obfuscated, the tool calls this with the arguments
) I can't help any further with the cause of the performance issue, I can only speculate. However, that said, the tool works fine if there are not that many domains. So I assume what we have here is some kind of schlemiel the painter's algorithm, in some way.
The /opt/psa/bin/reconfigurator tool is what the help pages recommend for plesk servers.
This tool appears to slow to a crawl when it gets to the following step; nothing has been printed for hours after this line;
Code:
Updating DNS records for IP <oldIP> to <newIP>I've written some queries to track its process. So far It's written 1234 out of ~4,000 DNS records in about 3 hours, an an offline test copy of the real environment (so with no traffic to contend with). It still has several thousand more to go. Suffice to say that it is unacceptably slow, when 'plesk bin repair dns' takes a minute at most, and a quick replace query
Code:
UPDATE `psa`.`dns_recs` SET `val` = 'newIP' WHERE `val` = 'oldIP'for A and AAAA records takes less than a second. Note that I know that the suggested tool does more than just change these db records, it's just that this particular step appears to be running much slower than even a naïve manual effort, such as exporting the dns_recs table to csv, find&replace with notepad++, then importing the csv, then repairing dns.
Running top reveals some sw-engine processes taking up a single cpu core equivalent worth of compute, at first, for the first 10 min or so. After this, cpu usage goes down to a minimum. After ~3hrs, about 4m37s of cpu time (4C/4T allocated) is used by the main sw-engine process.
Since I can't easily see what it's doing (/opt/psa/admin/plib/api-cli/ipmanage.php is obfuscated, the tool calls this with the arguments
Code:
../admin/plib/api-cli/ipmanage.php --remap $mapfile- Does this tool run dns repair after every new record? If so, that would be O(n^2) and get quite slow. If there is another level of indirection you get to O(n^3) and hour-long runtimes for a few thousand records would be all but expected (after all, 1000^3 = 10^9 which is O(cpu speed)).
- Does this tool use some kind of regex to figure what to write in records, if it writes in advanced, non-primary records as well (replacing IP refs in SPF and the like)? If so, recursive backtracking (also called catastrophic backtracking) could kill the performance.
- Does this tool call other files (or cause sw-engine to run) per-record? If it does, that would be very slow as well, as a fair bit of PHP code has to be decrypted several thousand times. If this is done for every record in the db in a similar way as repairing the dns after each change, then 4,000 records blows up to 16,000,000 php file executions, which I'm not surprised to see taking hours.
