Monthly Archives: March 2015

如何找出僵死进程的父进程

Posted by on 2015/03/24 No comments

今天在查看进程的时候，看到无数个cat，就像这样
Screen Shot 2015-03-24 at 23.14.53

然后我killall杀掉进程后变成这样：

Screen Shot 2015-03-24 at 23.16.09

但这个时候死活杀不掉了。。这是为毛？？接下来我只能通过查看进程状态才行了，如下：

> cat /proc/32741/status                                                                                                      
Name:	cat
State:	Z (zombie)
Tgid:	32741
Ngid:	0
Pid:	32741
PPid:	32710
TracerPid:	0
Uid:	1000	1000	1000	1000
Gid:	100	100	100	100
FDSize:	0
Groups:	2 7 50 91 92 93 95 96 100
Threads:	1
SigQ:	27/63909
SigPnd:	0000000000000000
ShdPnd:	0000000000004000
SigBlk:	0000000000000000
SigIgn:	0000000000000000
SigCgt:	0000000180000000
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	0000003fffffffff
Seccomp:	0
Cpus_allowed:	ff
Cpus_allowed_list:	0-7
Mems_allowed:	00000000,00000001
Mems_allowed_list:	0
voluntary_ctxt_switches:	2
nonvoluntary_ctxt_switches:	1

查出PPid，就是parent pid（父进程id），有了这个PPid，再查出导致此问题的进程，把它kill掉即可！

> cat /proc/32710/status                                                                                                     
Name:	chrome
State:	S (sleeping)
Tgid:	32710
Ngid:	0
Pid:	32710
PPid:	1
TracerPid:	0
Uid:	1000	1000	1000	1000
Gid:	100	100	100	100
FDSize:	256
Groups:	2 7 50 91 92 93 95 96 100
VmPeak:	  341320 kB
VmSize:	  341080 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	   47000 kB
VmRSS:	   47000 kB
VmData:	    1660 kB
VmStk:	     136 kB
VmExe:	   90652 kB
VmLib:	   60344 kB
VmPTE:	     464 kB
VmSwap:	       0 kB
Threads:	1
SigQ:	27/63909
SigPnd:	0000000000000000
ShdPnd:	0000000000000000
SigBlk:	0000000000000000
SigIgn:	0000000000000000
SigCgt:	0000000180000000
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	0000003fffffffff
Seccomp:	0
Cpus_allowed:	ff
Cpus_allowed_list:	0-7
Mems_allowed:	00000000,00000001
Mems_allowed_list:	0
voluntary_ctxt_switches:	261533773
nonvoluntary_ctxt_switches:	45982
> killall chrome

查出来的结果！居然是chrome！！

PHP中执行Mongo的一个性能问题

Posted by on 2015/03/21 No comments

最近正好在使用mongodb，在完成基础功能的时候，我习惯性的会对其性能进行一些测试，首先在mongo 2.6.4下进行测试，php版本会5.6。测试工具我使用的wrt，这是一个非常好用的压力测试工具，而且可以配合lua脚本，测试和聚合。

在Mongo 2.6.4下测试情况

由于业务的需要，我用500个并发+1分钟请求来进行了测试，主要针对读取，插入，更新已经调用执行js脚本。

1. mongo数据读取操作，结果是1320 reqs/sec。

2. mongo数据插入操作，结果是1240 reqs/sec。

3. mongo数据更新操作，结果是1250 reqs/sec。

以上三个结果，我还算能接受，但是接下来的测试，让我彻底惊到了。

由于业务上的需求，我在设计整个构架的时候，是考虑把一部分逻辑放在mongo中调用js直接执行的。测试脚本是

function getGameInfo(gameid) {
   if (gameid == undefined) {
       return false;
   }

   game = db.games.findOne({ gameid : gameid });

   if (game) {
      return game.toArray();
   }

   return false;
}

然后在php中执行，php的脚本为

$client = new MongoClient("mongodb://localhost:27017");
$db = $client->selectDB("test");
$code = "function getGameInfo(gameid) {
   if (gameid == undefined) {
       return false;
   }
   game = db.games.findOne({ gameid : gameid });
   if (game) {
      return game.toArray();
   }
   return false;
}";

$db->execute($code, array(10));
$client->close();

测试下来的结果只有35reqs/sec，而且mongo还报了连接数过多。首先mongodb的链接，在php中默认就是长链接，也就是说链接数过多，因为前面的数据执行了没有断开链接。但是我明明关闭链接了。

我Google了一下，在mongo中select是non-block，insert和update是collection级锁，而运行js脚本是全局锁，同时在mongo2.6.4下js是spidermonkey。主要原因找到了，因为全局锁，就必须等待前面一个脚本运行完成返回结果才行。同时现在Mongo已经升级到了3.0，它的JS引擎也从spidermonkey变成了V8，但同时在3.0，execute/eval函数了已经deprecated。

在Mongo 3.0.0下测试情况

MongoDB已经正式发布了3.0，根据官方的测试提高接近4倍的性能，我以1000个并发+1分钟请求进行测试，其结果确实让人满意不少。

1. mongo数据读取操作，结果是2320 reqs/sec。

2. mongo数据插入操作，结果是1840 reqs/sec。

3. mongo数据更新操作，结果是1950 reqs/sec。

探求PHP-FPM最佳运行模式

Posted by on 2015/03/21 No comments

我们安装php，在配置PHP-FPM的时候一般搜到的配置，大多数都是一样的，推荐你使用’dynamic’进程管理（process manager，在配置中简称位pm）模式来运行。虽然这没什么问题，但是本文将会探究最佳运行模式。

为什么要选择’ondemand’来代替’dynamic’来做为进程管理器

在大多数的配置指南中，都是这样配置的，然后你会直接复制粘贴放在你的配置文件中。

Read more »