问题背景

看过CI框架用法应该会看到，在配置CI框架连接数据库时，默认会开启持久连接，即类似这样的配置$db['test']['pconnect'] = TRUE;，使用MySQL时会调用mysql_pconnect方法实现这一个功能，而oci8扩展恰巧也有类似的方法oci_pconnect:

方法的用处文档上说的很清楚：

oci_pconnect() 创建一个到 Oracle 服务器的持久连接并登录。持久连接会被缓冲并在请求之间重复使用，可以降低每个页面加载的消耗。

那么按道理来说这样的功能应该是会提升处理能力的，但是问题在于，持久连接会增加Oracle的进程数，一旦进程数耗尽，那么新的连接请求可能会被拒绝，反而会使得处理能力下降。

今天遇到了这样的一个问题，当双机各自开启1024个php-fpm进程时，使用sqlplus连接数据库被拒绝，同时各种操作都被拒绝执行。

所用的机器是两台阿里云的8核心16GB ECS服务器，Oracle数据库为11G R2，PHP版本为5.4，CI版本为2.2。

表现

首先是一次压测结束后，发现通过sqlplus连接不上Oracle数据库，即首先sqlplus /nolog之后使用conn命令无法连接成功，发现报错信息为：

居然没有可用的进程了！

那么目前需要做的就是释放这些进程，直接SHUTDOWN IMMEDIATE也该是最简单粗暴也能达到目的的方法，但是目前根本不能按照原先的sqlplus /nolog之后使用conn /as sysdba登录，解决的方式可以直接在shell中使用sqlplus / as sysdba即可完成登录。

分析

增加进程数

登录完成之后进行SHUTDOWN IMMEDIATE以及STARTUP操作，重启之后修改可用进程数：

关于这几个数值的关系，参考了这篇博文，博文中作者提到这三者可以按照如下关系配置：

使用spfile作为scope的参数原因是这几个参数并不能修改后立即生效，需要重启数据库之后才能生效。

修改完成后重启数据库，重新进行压测，ps -ef | grep oracle | wc -l发现进程数果然上来了，但是在压测结束后，发现再次出现了这一问题。那么这一问题并不单纯是进程不足的问题。

测试环境检查

Oracle进程数增加却被完全消耗，这个情况确实让人觉得奇怪。

检查CI的配置时，发现数据库配置文件中使用了pconnect属性，查阅oci_pconnect的文档，注意到如下一句话：

一个典型的 PHP 应用程序对于每个 Apache 子进程（或者 PHP FastCGI/CGI 进程）会有一个打开的持久连接到 Oracle 服务器

那么，目前一共有两台机器，每台机器开启了1024个php-fpm的进程，总计2048个，那么Oracle的进程数仅仅为1000个，自然是不够用的。

持久连接虽然减少了连接的成本，然后却使得没有进程可用，显然问题出在CI的持久连接上。

解决

解决的方式自然是关闭CI的持久连接配置，在设定$db['test']['pconnect'] = FALSE;之后，通过ab进行压力测试，在10000并发的情况下，所用的Oracle进程数长期维持在30个左右，基本上解决了这一问题。

结论

CI在使用持久连接时，可能需要考虑Oracle的可用进程数（设为X）以及php-fpm的个数（设为Y）之间的关系，当X>Y时，个人认为是可以考虑使用持久连接的。

否则，个人认为可以牺牲一部分性能来建立连接，使得Oracle维持有足够的可用进程数。