VPS下安装Debian Linux,Nginx,MySQL,PHP补充

By /

　　前段时间写过一篇“VPS下安装Debian Linux,Nginx,MySQL,PHP”，介绍了在vps下面搭建基于LNMP的环境。说起来由于使用了LNMP一键安装包可以说是十分的方便，不过由于全部是编译安装所以在今后使用apt-get安装一些软件的时候会出现一些依赖包版本的问题，在这里笔者就略去不说，因此只要当前版本稳定，完全可以只顾及安全方面的更新而无视其它更新了。当然随着LNMP安装包的不断更新，如果有需要也可以整体升级到更新的版本。在测试了2周左右之后笔者将使用过程中的一些细节问题整理出来，以备以后重新搭建的时候查阅。

VPS下安装Debian Linux,Nginx,MySQL,PHP补充
VPS下安装Debian Linux,Nginx,MySQL,PHP补充

Nginx频繁出现502错误的问题

　　该问题并不是是在Nginx运行一段时间后出现的，疯狂google后发现可能的原因为php-cgi进程数量太少（默认开启5个），粗略计算下20M*10=200M，因此在笔者的512M内存上抛10个php-cgi进程应该没什么大问题，所以这里可以调优下。但毕竟并发高了还是会出问题，所以彻底解决办法就是定时检查502是否出现，如果出现重启php-cgi进程。这里要说明一下，笔者的应用基本都算是只用来看的，并没有强烈的事务驱动的需要，因此浏览者最多也就是延迟几秒看到内容，所以定期重启php-cgi并没啥大问题。

检查脚本如下：

#!/usr/bin/php
  <?
  $url = 'http://webrss.org';
  $cmd = '/usr/local/php/sbin/php-fpm restart';

for($i = 0; $i < 5; $i ++){
  $exec = "curl --connect-timeout 3 -I $url 2>/dev/null";
  $res = shell_exec($exec);

if(stripos($res,'502 Bad Gateway') !== false){
  shell_exec($cmd);
  exit();
  }
  }
  ?>

此脚本直接加入到crontab中，每5分钟运行一次即可。

关于wordpress下缓存插件的选择

　　wp super cache和cos-html-cache是笔者主要考量的两款插件，前者笔者使用了2年左右，后者使用了1周。从性能上来讲，笔者认为后者具有更大的优势。优势有两点：

  1. 解析php和操作db带来的性能开销,按照cos-html-cache作者的说法，无论插件加载的再早都无法避免wp去读取一些blog自身信息的过程，例如调用bloginfo()之类的函数。此时最直接的就是导致php-cgi工作同时引发db的工作。而cos-html-cache则巧妙的运用了web server读取文件类型顺序的优势，当已经存在静态html文件的时候会优先抓取html文件（当然这个顺序在vps上是可以人工调整的）的方式避免了不必要的性能开销。
  2. 则来自原wp super cache本身，因为在读取缓存文件过程中势必会需要一个环节来处理是抓取新内容还是读取缓存，cos-html-cache的方式是让web server自行选择，而wp super cache则提供了三种方式默认的方式当然是rewrite了，这其实也是变相借助了web server的能力，但如果无法使用该项则演变为再次经过一道手续由php进行处理，此时php-cgi仍然会参与工作势必导致性能开销。总和上面亮点来看，如果你对性能的追求像笔者一样痴迷的话那么久用cos-html-cache吧。

关于Yet Another Related Posts插件的性能问题

　　yarpp也就是Yet Another Related Posts Plugin的确是一款十分不错的插件，当时当该插件自动创建的表中一个名为：wp_com_yarpp_related_cache的表内数据急速膨胀的时候会出现十分严重的性能问题，笔者的一个数据库中该表记录为15000条，在更新文章的过程中该表的操作就导致mysql长时间出于满负荷状态。简单的说笔者的hostmonster帐号被禁用就是因为这个查询导致的。后来笔者在vps上重新模拟出了和这个情况，在512M + 1G cpu的情况下，可以看到mysql进程长时间出于100%的cpu占用状态。笔者简单查看了该表，发现此表中四个字段做了一个联合索引，但是回想起之前出问题的sql，应该不是同时查询四个字段，于是在”reference_ID和ID”量列上分别作了索引。在之后的两周内，暂时还没遇到过之前的问题。

最后一个问题就是一些php-cgi进程长时间占用cpu的问题

　　该问题笔者几乎可以肯定是由于某些应用中的编码问题导致的，不过笔者实在不精通php,也懒得去追根问底了，毕竟程序也不是自己写的。所以用了一个最简单省力的办法，直接定时重启整个lnmp应用。其方法和检测502类似，只是改重启会选择在一个流量相对比较少的时候自动运行。因为笔者发现有时候即使不出现502错误，也会遇到访问速度下降的问题，这其实就是某个php-cgi进程严重的占用了cpu资源而导致的，但此时如果我们试用的是cos-html-cache的好处就体现出来了，因为无需php-cgi占用cpu资源解析，所以访问速度仍然是不错的。但只要需要php引擎解析速度肯定让你很郁闷的。所以最终笔者干脆就定时自动重启了。

目前使用vps大概2周左右的时间，感触也就这么多，有阐述不正确的地方还请各位高手们指正。以后遇到问题继续记录了。

Scroll to Top