ECS部署WordPress踩坑记录

2019年1月24日 0 条评论 366 次阅读 0 人点赞

1 nginx配置

解决方案:本站WordPress采用LNMP(Linux+Nginx+MySQL+PHP)环境进行搭建,本站的nginx配置文件详情见图1,需要注意的是需要对fastcgi相关参数进行配置(需要注意fastcgi_params的位置,本例中该文件位置为/etc/nginx/fastcgi_params),否则PHP-FPM将无法工作,nginx将无法处理PHP请求。

图1 WordPress网站nginx配置实例

2 WordPress更新、上传主题或上传文件时失败

问题描述:在管理界面(wp-admin)更新WordPress版本、安装主题、上传媒体文件时出现错误,提示没有权限。

问题分析:安装WordPress时,如果是直接拿到WordPress的压缩包进行解压,安装时的用户往往不是WordPress的默认用户,比如说使用root用户拿到安装包并解压之后,WordPress整个安装目录的权限为755,属主为root,然而WordPress安装完成后,通过管理台进行文件上传相关操作时,使用的是WordPress的默认用户(并非root用户),而非root用户对WordPress安装目录只有读和执行权限,没有写入权限,故上传文件时会失败。

解决方案:WordPress安装时会有一个默认用户,我们首先需要找出这个用户,方法很简单,首先我们修改WordPress安装目录(典型安装目录为/var/www/wordpress)的权限为777(chomod -r 777 /var/www/wordpress),修改完成后,所有用户都有了写文件权限,此时我们再通过控制台任意上传一个文件,登录服务器查看该文件的信息,可以找到该用户的属主(典型用户为apache);然后将WordPress安装目录的属主变更为apache(chown -r apache:apache /var/www/wordpress);最后再将安装目录的权限恢复为755(chmod -r 755 /var/www/wordpress),至此该问题解决完毕。

3 上传文件异常413 Request Entity Too Large

问题描述:在上传主题包时,上传失败,报错为413 Request Entity Too Large

问题分析:由返回的错误信息大致可以看出是由于文件过大导致的上传失败,查询百度相关资料,发现问题是出在nginx的配置上,nginx的默认client_max_body_size为1m,当上传文件超过这个大小时就会导致这个报错。

解决方案:修改nginx配置文件(该文件有两个,一个是nginx本身的配置文件/etc/nginx/nginx.conf,另一个是针对网站的配置文件,本站的路径为/etc/nginx/conf.d/wordpress.conf)的client_max_body_size参数,具体大小视具体文件上传文件的大小而定,本站设置为50m,然后重启nginx服务(systemctl restart nginx)。

4 建立数据库连接时出错

问题描述:在访问WordPress网站时,经常发现报建立数据库连接时出错。

问题分析:建立数据库连接时出错,问题提示已经很明显了,WordPress连接数据库出现异常了。此时可以从两个方向进行排查,一是检查wp-config.php文件,看数据库的相关配置是否正常(这个一般是没有问题的,因为这个报错并不是新建WordPress网站时报的,而是在使用过程中报的);二是检查MySQL服务是否正常,本例中发现MySQL服务被异常停止了(systemctl status mysqld),检查MySQL的日志(常规目录为/var/log/mysqld.log),发现有如图2报错,观察报错信息,可以发现关键问题在于cannot allocate memory for the buffer pool,很明显这是内存不够导致的,这是由于我的ECS配置比较低,内存总共就1G,要解决这个问题需要调整MySQL的配置(常规路径为/etc/my.cnf)

图2 mysql.log报错信息

如果不知道MySQL的日志存放目录,可以登录MySQL服务器,通过以下脚本查询日志的存放目录,查询结果见图3,其中log_error就是上述日志所在目录

如何查询MySQL日志存放目录
show variables like '%log%';
图3MySQL日志存放目录

解决方案:修改MySQL的配置my.cnf,将innodb_buffer_pool_size修改为64m(见图4),然后重启MySQL服务即可(systemctl restart mysqld)

图4 my.cnf配置

后续问题:调整MySQL的innodb_buffer_pool_size配置之后,过了两天发现又出现建立数据库连接时出错的问题,很是头疼,数据库缓冲池已经调到64M了,看来其他地方还出了问题。竟然是内存不够,那就从内存角度排查一下吧,看看系统中有没有内存占用高的进程。首先使用以下命令查看了一下系统内存占用前40名的进程情况(见图5),结果让人大吃一惊,php-fpm竟然有20多个进程在,而且每个占用了1点几的内存,经过百度一番发现可以通过设置pm.max_children(该配置文件路径为/etc/php-fpm.d/www.conf,见图6)的大小控制php-fpm子进程的个数,该参数默认的值为50,本站一方面访问量不大,一方面内存又比较小,故将此参数设置为10,同时还要修改pm.max_spare_servers (该值表示保证空闲进程数最大值,如果空闲进程大于此值,此进行清理 ,本站设置为10)和pm.min_spare_servers (保证空闲进程数最小值,如果空闲进程小于此值,则创建新的子进程,本站设置为5)

ps auxw|head -1;ps auxw|sort -rn -k4|head -40
图5 内存占用前40位的进程
图6 php-fpm配置文件

5 访问网站时报502 Bad Gateway

问题描述:访问WordPress网站时报502 Bad Gateway

问题分析:

502 Bad Gateway是指错误网关,无效网关,这通常并不意味着上游服务器已关闭(无响应网关/代理),而是上游服务器和网关/代理不同意的协议交换数据。鉴于互联网协议是相当清楚的,它往往意味着一个或两个机器已不正确或不完全编程。

来源于百度百科

首先我们可以检查nginx是否正常工作(systemctl status nginx),一般而言都是正常的;但是需要注意,WordPress是基于PHP的,nginx本身不能处理PHP,它只是个web服务器,当接收到请求后,如果是php请求,则发给php解释器处理,并把结果返回给客户端,nginx一般是把请求发fastcgi管理进程处理,fascgi管理进程选择cgi子进程处理结果并返回被nginx。本站使用PHP-FPM作为PHP FastCGI管理器,当发生502错误时,还需要检查PHP-FPM是否正常运行(systemctl status php-fpm),本例报错就是由于该进程异常终止而导致的。

解决方案:启动PHP-FPM服务(systemctl start php-fpm)

当WordPress出现异常时,首先需要检查WordPress三大件(MySQL,nginx,PHP-FPM)是否运行正常

WordPress异常时常规排查

ropeal

这个人太懒什么东西都没留下

文章评论(0)