今天小伙伴向Kaijia反映万年没有动的VestaCP面板突然间响应缓慢，Kaijia登录检查发现每次点击VestaCP面板中任意功能，均需要等待3~5秒时间才能响应，而同时间服务器并无高负载、高IO情况，VestaCP管理下的网页亦可飞速打开。

为了找到延时原因，Kaijia在/usr/local/vesta/php/etc/php-fpm.conf开启了VestaCP的慢执行日志（slow log），获得以下记录：

[03-Feb-2018 23:00:54]  [pool www] pid 2721
script_filename = /usr/local/vesta/web//list/web/index.php
[0x00007f8ead529798] exec() /usr/local/vesta/web/list/web/index.php:9

[03-Feb-2018 23:01:03]  [pool www] pid 2721
script_filename = /usr/local/vesta/web//list/web/index.php
[0x00007f8ead529708] shell_exec() /usr/local/vesta/web/list/web/index.php:12

VestaCP的傻瓜式迁移方法对于简单示例来说非常方便，在旧新示例上分别执行v-backup-user和v-restore-user命令即可完成，这一过程假定了两台服务器上所有的配置均为默认安装，因此在对VestaCP配置作出过调整的情况下会迁移则会出现错误。

Kaijia昨天一直运行VestaCP的服务器到期，考虑网络因素决定将VestaCP迁移到阿里云中。考虑到扩展需求（吃内存的MySQL 5.7），Kaijia决定利用两台1G内存的云服务器，第一台运行除了MySQL以外的其他服务，第二台（设定域名为mysql.kaijia.me）单独运行MySQL，并将其添加为VestaCP的远程MySQL服务器。这样的配置与虚拟主机商采用的策略相同，但因此调整，在将VestaCP用户迁移到新服务器时便会出现问题：

[email protected]:~# v-restore-user kaijia kaijia.2017-10-18.tar

— DB —
2017-10-18 21:31:14 kaijia_example
Error: mysql config parsing failed

阅读更多