记录修改wordpress上传文件大小引发的一系列问题

为什么只给2M?

最近在博客上准备上传文件的时候发现,最大上传文件有个2M的大小限制。就算不考虑一些比较大的音频和视频文件,很多相机拍的照片都不止2M大小。为了能够去掉这个大小限制,只好去网上查一下解决方案。

我就要给10M

网上给出的修改方法基本上分为3类,分别是修改 “functions.php” 、 “php.ini” 和 “.htaccess”。具体可以参考 WordPress最大上传文件大小限制修改

我是参照了修改 “.htaccess” 文件的方法,添加了以下内容。

php_value upload_max_filesize 10M
php_value post_max_size 10M
php_value max_execution_time 300
php_value max_input_time 300

从修改的内容上可以看出来,其实根本原因是php限制了上传文件最大2M。那为什么不去修改 “php.ini” 文件呢?

因为我只需要这个改动对我当前的wordpress生效即可。修改 “php.ini” 文件的话,则会影响整个系统。

修改两个文件的区别可以参考: What is the difference between php.ini and .htaccess?

修改完成之后,记得重启服务(httpd)。再打开wp的上传界面,可以看到”最大上传文件大小”已经显示为10M了。

头疼的mysql

既然已经改完了,那就上传一些大于2M的照片试一下效果吧。于是,我选取了二三十张照片点击上传。经过一段时间的等待,随之而来的并不是提交成功的提示信息,而是纹丝不动的上传进度条。现在的情况是,进度条一动不动,也没有任何错误信息,难道是网络不好导致上传没速度吗?还是后台出了什么问题?

为了确定服务是不是都正常,于是查看了一下所有服务的状态 service --status-all 。果然,mysql服务出现了异常。服务后有以下提示信息: MySQL is not running, but lock file (/var/lock/subsys/mysql[FAILED]

根据错误信息,以及在 stackoverflow 上查到的内容,使用 lsof 命令之后重启mysql服务正常。

注意:

  1. 输入 serivce mysql restart 会返回错误:myslq: unrecognized service 。这是因为像很多其他的Linux服务一样(httpd/vsftpd),mysql的服务名应该以d结尾,即 myslqd

    具体可参考:

    Why do some processes end with the letter “d”?

    Why do some Linux files have a ‘d’ suffix?

  2. MySQL的log路径是通过配置文件/usr/local/mysql/etc/my.cnf来指定的。找到对应的文件即可查看 mysql-error.log

  3. 通过查看log可以发现有以下错误:[ERROR] /usr/local/mysql/bin/mysqld: Table ‘./mysql/user’ is marked as crashed and should be repaired。可以通过phpadmin管理界面直接修复。修复方法请参考: Table is marked as crashed and should be repaired

  4. 有时候命令行中能看到下面的命令,这是因为直接运行mysqld程序来启动MySQL服务的方法很少见,mysqld_safe脚本会在启动MySQL服务器后继续监控其运行情况,并在其死机时重新启动它。

    /usr/local/mysql/bin/mysqld_safe: line 178: 27657 Killed                  nohup /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --plugin-dir=/usr/local/mysql/lib64/plugin --user=mysql --log-error=/usr/local/mysql/data/mysql-error.log --open-files-limit=512 --pid-file=/usr/local/mysql/data/mysql.pid --socket=/usr/local/mysql/data/mysql.sock --port=3306 < /dev/null > /dev/null 2>&1
    /usr/local/mysql/bin/mysqld_safe: line 178: 28673 Killed                  nohup /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --plugin-dir=/usr/local/mysql/lib64/plugin --user=mysql --log-error=/usr/local/mysql/data/mysql-error.log --open-files-limit=512 --pid-file=/usr/local/mysql/data/mysql.pid --socket=/usr/local/mysql/data/mysql.sock --port=3306 < /dev/null > /dev/null 2>&1 > /dev/null 2>&1
    
  5. Stop server: ERROR! MySQL server PID file could not be found!

nginx原来也会搞鬼

数据库服务重启成功之后,就不敢那么放肆的上传文件了,这次只好先选取一张大于2M的照片上传。进度条xiu的一下就跑完了,不过并不是说明上传成功了,而是提示了 http错误 。为了能够确定到底是网络问题还是图片大小导致的问题,我又选取了一张大小小于2M的图片上传。进度条再次xiu的一下就跑完了,上传成功。这样看来,还是文件大小导致了上传失败啊。

再次根据错误信息 http错误 去网上搜索解答。看到有一篇文章里面有提到,如果是使用的nginx服务器,那么nginx的配置也会影响到上传文件的大小。于是我便找到了nginx的错误日志(/var/log/nginx/error.log),里面果然有错误:client intended to send too large body

找到的错误原因,解决起来就方便了。只需要在nginx的配置文件里面指定client_max_body_size的大小就可以了。

注意:修改了nginx配置需要重新加载。nginx -s reload

原来不是mysql的错!

nginx配置好了之后再来测试上传文件,这次终于成功上传了大于2M的照片!

可惜这次成功的喜悦没有持续太久就有发现问题了!mysql服务又出问题了!

出问题了那就去看error_log吧,在日志中能够看到很多同样的错误—- InnoDB: Error: pthread_create returned 11 。查了一下错误原因:这个错误原因主要是因为线程创建失败,要么是创建的线程数超出硬件资源的允许值,要么是该线程占用的内存大小超过系统的限制值。

一般的解决方案都是建议不限制占用的内存大小(ulimit -s unlimited)。但是根据mysql的错误日志来看,数据库开始出现异常是在我修改了 .htaccess 文件之后才出现的,所以最根本原因应该并不是内存分配的大小不够,而是还存在其他方面的问题。

参考资料:

  1. MySQL常见问题及处理方案
  2. MySQL – InnoDB: Error: pthread_create returned 11

就在这个问题不知道怎么解决的时候,中国好同事出现了!

不是内存不够吗?那先用 free -m看一下当前内存的使用情况。free内存确实没有了!那是什么占用了内存呢?再通过top命令来看一下是哪些进程在占用内存呢!这样一看就明了了,原来是有很多httpd的进程在占用着内存。于是重启一下httpd服务,再次查看内存使用情况,一切回复正常。

这是我的猜想

后来仔细回想了一下整个流程,有可造成数据库经常出现异常的原因应该是,最开始在只修改了 .htaccess 文件的时候上传了太多大于2M的文件,而此时nginx中的配置并没有修改,就导致了有很多的httpd的进程卡死了,一直占用着内存又结束不了。

而在所有配置都已经修改好,并且服务都重启之后,数据库也没有再出现问题了!

发表评论

电子邮件地址不会被公开。 必填项已用*标注