Chinaunix

标题: 致命问题,致命打击 ,大虾进来看下,在线等......... [打印本页]

作者: sickcat2004    时间: 2006-04-27 10:20
标题: 致命问题,致命打击 ,大虾进来看下,在线等.........
测试机器和服务器都是 rhel3 au4
mysql : 4.1.18 编译安装
php4.44 编译安装

在测试机器上我的程序一直都好好的
但是在服务器上出现
on file /***/***/classes.php
on line 52
eno:1040
emsg:Too many connections

我的/etc/my.cnf

26 [mysqld]
     27 port            = 3306
     28 socket          = /tmp/mysql.sock
     29 skip-locking
     30 key_buffer = 16M
     31 max_allowed_packet = 50M
     32 table_cache = 64
     33 sort_buffer_size = 512K
     34 net_buffer_length = 8K
     35 read_buffer_size = 256K
     36 read_rnd_buffer_size = 512K
     37 myisam_sort_buffer_size = 8M
     38 max_connections = 1000


我的classes.php 中相关成员函数
<?
/*--------------------------------------------------
|                                数据驱动类
*--------------------------------------------------*/
class db_driver
{
  var $options = array(
          "db_dbname" => "",                          //数据库名
        "db_username" => "****",                //数据库用户名
        "db_passwd" => "******",                //数据库密码
        "db_host"   => "*******:3306",                 //服务器
        "persistent" => 1,                        //持久化连接
        "debug"        => 1,                                 //调试标志
       
  );
  var $conn;                 //数据库连接
  var $stmt;                  //数据库语句声明标志
  var $eno;                //错误编号
  var $emsg;                 //错误信息
  /*
  function db_driver(&$options)
  {
          $this->__construct($options);
  }
*/
  function db_driver(&$options)
  {
             if(is_array($options))
        {
                $this->set_options($options);
                $this->connect();
                $this->select_db();
        }
  }
  function set_options(&$options)
  {
          if(is_array($options))
        foreach($options as $key => $var){
                $this->options[$key] = $var;
                $options[$key] = $key;
        }
  }
  function connect()
  {
          if($this->options["db_dbname"]){
                if($this->options["persistent"]){
                        $this->conn = @mysql_pconnect($this->options['db_host'],$this->options["db_username"], $this->options["db_passwd"]);
                }else{
                        $this->conn = mysql_connect($this->option['db_host'],$this->options["db_username"],  $this->options["db_passwd"]);
                }
        }
        //print_r($this->conn);
        //die();
        if(!$this->conn) $this->set_error(__LINE__);
        return $this->conn;
  }

现在我不知道是程序还是服务器配置的问题
在测试机器上没有出现以上错误,初步估计是mysql 的问题吧,大虾们看一下,非常感谢!!
作者: ipaddr    时间: 2006-04-27 10:42
MYSQL连接数过多,与PHP无关.修改一下MYSQL的配置,
作者: sickcat2004    时间: 2006-04-27 10:47
原帖由 ipaddr 于 2006-4-27 10:42 发表
MYSQL连接数过多,与PHP无关.修改一下MYSQL的配置,

老大,我已经加入这句啦,还要如何配置啊

max_connections = 1000
作者: ipaddr    时间: 2006-04-27 10:54
加入这句,还会说连接数过多吗?

你主机上有多少人在用MYSQL?

建议试试不用PCONNECT看看.
作者: 北京野狼    时间: 2006-04-27 10:54
别用mysql_pconnect, 没什么用处
作者: sickcat2004    时间: 2006-04-27 10:56
原帖由 北京野狼 于 2006-4-27 10:54 发表
别用mysql_pconnect, 没什么用处

是mysql_pconnetct 的问题么????
作者: ipaddr    时间: 2006-04-27 10:56
原帖由 北京野狼 于 2006-4-27 10:54 发表
别用mysql_pconnect, 没什么用处



为啥说这PCONNECT没用处?

我测度过,性能提升很明显.
作者: 北京野狼    时间: 2006-04-27 11:06
标题: 数据库永久连接
  1. 数据库永久连接
  2. 永久的数据库连接是指在您的脚本结束运行时不关闭的连接。当收到一个永久连接的请求时。PHP 将检查是否已经存在一个(前面已经开启的)相同的永久连接。如果存在,将直接使用这个连接;如果不存在,则建立一个新的连接。所谓“相同”的连接是指用相同的用户名和密码到相同主机的连接。

  3. 对 WEB 服务器的工作和分布负载没有完全理解的读者可能会错误地理解永久连接的作用。特别的,永久连接不会在相同的连接上为您提供建立“用户会话”的能力,也不提供有效建立事务的能力。实际上,从严格意义上来讲,永久连接不会给您提供任何非永久连接无法提供的特殊功能。

  4. 为什么?

  5. 这和 WEB 服务器工作的方式有关。您的 WEB 服务器可以用三种方法来利用 PHP 生成 WEB 页面。

  6. 第一种方法是将 PHP 用作一个“外壳”。以这种方法运行,PHP 会为向您的 WEB 服务器提出的每个 PHP 页面请求生成并结束一个 PHP 解释器线程。由于该线程会随每个请求的结束而结束,因此任何在这个线程中利用的任何资源(例如指向 SQL 数据库服务器的连接)都会随线程的结束而关闭。在这种情况下,您使用永久连接不会获得任何地改变――因为它们根本不是永久的。

  7. 第二,也是最常用的方法,是把 PHP 用作多过程 WEB 服务器的一个模块,这种方法目前只适用于 Apache。对于一个多过程的服务器,其典型特征是有一个父过程和一组子过程协调运行,其中实际生成 WEB 页面的是子过程。每当客户端向父过程提出请求时,该请求会被传递给还没有被其它的客户端请求占用的子过程。这也就是说当相同的客户端第二次向服务端提出请求时,它将有可能被一个不同的子过程来处理。在开启了一个永久连接后,所有请求 SQL 服务的后继页面都能够重新使用这个已经建立的 SQL Server 连接。

  8. 最后一种方法是将 PHP 用作多线程 WEB 服务器的一个插件。目前 PHP 4 已经支持 ISAPI、WSAPI 和 NSAPI(在 Windows 环境下),这些使得 PHP 可以被用作诸如 Netscape FastTrack (iPlanet)、Microsoft's Internet Information Server (IIS) 和 O'Reilly's WebSite Pro 等多线程 WEB 服务器的插件。永久连接的行为和前面所描述的多过程模型在本质上是相同的。注意 PHP 3 不支持 SAPI。

  9. 如果永久连接并没有任何附加的功能,那么我们使用它有什么好处?

  10. 答案非常简单――效率。当客户端对您的 SQL 服务器的连接请求非常频繁时,永久连接将更加高效。连接请求频繁的标准取决于很多因素。例如,数据库的种类,数据库服务和 WEB 服务是否在同一台服务器上,SQL 服务器如何加载负载等。但我们至少知道,当连接请求很频繁时,永久连接将显著的提高效率。它使得每个子过程在其生命周期中只做一次连接操作,而非每次在处理一个页面时都要向 SQL 服务器提出连接请求。这也就是说,每个子过程将对服务器建立各自独立的永久连接。例如,如果您有 20 个不同的子过程运行某脚本建立了永久的 SQL 服务器永久连接,那么实际上您向该 SQL 服务器建立了 20 个不同的永久连接,每个过程占有一个。

  11. 注意,如果永久连接的子过程数目超过了您设定的数据库连接数限制,系统将会产生一些缺陷。如果您的数据库的同时连接数限制为 16,而在繁忙会话的情况下,有 17 个线程试图连接,那么有一个线程将无法连接。如果这个时候,在您的脚本中出现了使得连接无法关闭的错误(例如无限循环),则该数据库的 16 个连接将迅速的受到影响。请查阅您使用的数据库的文档,以获取关于如何处理已放弃的及闲置的连接的方法。
复制代码

[ 本帖最后由 北京野狼 于 2006-4-27 11:09 编辑 ]
作者: 北京野狼    时间: 2006-04-27 11:10
警告

  1. 在使用永久连接时还有一些特别的问题需要注意。例如在永久连接中使用数据表锁时,如果脚本不管什么原因无法释放该数据表锁,其随后使用相同连接的脚本将会被永久的阻塞,使得您需要重新启动 httpd 服务或者数据库服务。另外,在使用事务处理时,如果脚本在事务阻塞产生前结束,则该阻塞也会影响到使用相同连接的下一个脚本。不管在什么情况下,您都可以通过使用 register_shutdown_function() 函数来注册一个简单的清理函数来打开数据表锁,或者滚回事务。或者更好的处理方法,是不在使用数据表锁或者事务处理的脚本中使用永久连接,这可以从根本上解决这个问题(当然您也可以在其它地方使用永久连接)。
复制代码



以下是一点重要的总结。永久连接是为通常连接建立一对一的分布而设计的。这意味着您必须能够保证在将永久连接替换为非永久连接时,您脚本的行为不会改变。使用永久连接将(非常)有可能改变您脚本的效率,但不改变其行为!
作者: ipaddr    时间: 2006-04-27 11:17
建立数据库连接的开销很大,使 用PCONNECT是能明显提升性能的.
作者: 北京野狼    时间: 2006-04-27 11:24
原帖由 ipaddr 于 2006-4-27 11:17 发表
建立数据库连接的开销很大,使 用PCONNECT是能明显提升性能的.

  1. [b]对 WEB 服务器的工作和分布负载没有完全理解的读者可能会错误地理解永久连接的作用。特别的,永久连接不会在相同的连接上为您提供建立“用户会话”的能力,也不提供有效建立事务的能力。实际上,从严格意义上来讲,永久连接不会给您提供任何非永久连接无法提供的特殊功能。 [/b]
复制代码

作者: sickcat2004    时间: 2006-04-27 11:27
两位喜欢钻研的老大,我的问题好像跟pconnetc 很connetc 搞不上联系吧!!
mysql 最大能多少在线啊,估计是1000还不够 吧
作者: ipaddr    时间: 2006-04-27 11:28
原帖由 北京野狼 于 2006-4-27 11:24 发表


[code]对 WEB 服务器的工作和分布负载没有完全理解的读者可能会错误地理解永久连接的作用。特别的,永久连接不会在相同的连接上为您提供建立“用户会话”的能力,也不提供有效建立事务的能力。实际上,从严 ...



我没说PCONNECT能扩展功能呀,

我只是说PCONNCECT能提升性能.没说功能会扩充.
作者: ipaddr    时间: 2006-04-27 11:29
原帖由 sickcat2004 于 2006-4-27 11:27 发表
两位喜欢钻研的老大,我的问题好像跟pconnetc 很connetc 搞不上联系吧!!
mysql 最大能多少在线啊,估计是1000还不够 吧


你不要用pconnect看看,
作者: 北京野狼    时间: 2006-04-27 11:30
原帖由 sickcat2004 于 2006-4-27 11:27 发表
两位喜欢钻研的老大,我的问题好像跟pconnetc 很connetc 搞不上联系吧!!
mysql 最大能多少在线啊,估计是1000还不够 吧


也许和pconnet有关系, 这种所谓永久链接除了耗资源意义不大。

我不大相信你的网站能并发1000个。 标准的CONNECT函数php使用完毕会close.
作者: sickcat2004    时间: 2006-04-27 11:30
两位大哥我把 max_connections =1000 改成max_connections=5000 就好啦
一个小网站竟然有这么的多连接数,想不通阿
作者: 北京野狼    时间: 2006-04-27 11:31
原帖由 ipaddr 于 2006-4-27 11:28 发表



我没说PCONNECT能扩展功能呀,

我只是说PCONNCECT能提升性能.没说功能会扩充.



我也没提扩展啊。

能够提升什么性能 ?
作者: 夜猫子    时间: 2006-04-27 11:40
用SHOW [FULL] PROCESSLIST看看队列里是不是有很多卡住的sql
再记录一下哪些查询时间过长的sql,大概记得是在my.cnf里设置long_query_time,在mysql manula找找The Slow Query Log看
我怀疑是你的sql效率问题导致,昨天才处理了这样一个case,不过那个是postgresql,也就是巨慢,还没达到拒绝连接的地步
作者: sickcat2004    时间: 2006-04-27 11:41
原帖由 北京野狼 于 2006-4-27 11:30 发表


也许和pconnet有关系, 这种所谓永久链接除了耗资源意义不大。

我不大相信你的网站能并发1000个。 标准的CONNECT函数php使用完毕会close.

下午我用connect 再试试,
说老实话我自己也不太相信那 :icon_cry:
作者: sickcat2004    时间: 2006-04-27 11:44
原帖由 夜猫子 于 2006-4-27 11:40 发表
用SHOW [FULL] PROCESSLIST看看队列里是不是有很多卡住的sql
再记录一下哪些查询时间过长的sql,大概记得是在my.cnf里设置long_query_time,在mysql manula找找The Slow Query Log看
我怀疑是你的sql效率问题导 ...

非常感谢老大的帮助,我猜也是有点这个问题,但是奇怪的是,测试机器上一点事情都没有,我怀疑是服务器上原来的程序也占用了很多query 并发
作者: 北京野狼    时间: 2006-04-27 11:51
有卡住的sql也有可能,

但是 Too many connections .说明有1000个并发被卡在后面。不太现实
作者: 夜猫子    时间: 2006-04-27 12:07
一旦队列开始卡住,卡1000个不是不能想象的,mysql这方面的记录不太好,总之是个可能吧,难说是主板上有虫子也说不定,楼主可以到机房瞧瞧,哈哈
作者: james.liu    时间: 2006-04-27 12:11
正好让"夜猫子"发挥了。。。呵呵

我倾向于夜猫子的高见
作者: sickcat2004    时间: 2006-04-27 12:54
原帖由 james.liu 于 2006-4-27 12:11 发表
正好让"夜猫子"发挥了。。。呵呵

我倾向于夜猫子的高见

下午我把测试数据搞上来让高手们分析下
作者: glider126    时间: 2006-04-27 13:02
提示: 作者被禁止或删除 内容自动屏蔽
作者: ipaddr    时间: 2006-04-27 13:06
原帖由 北京野狼 于 2006-4-27 11:31 发表



我也没提扩展啊。

能够提升什么性能 ?


用PHP打开数据库,并做查询,最后关闭,分别用PCONNECT,和CONNECT比较一下,跑一千个循环,比较一下就清楚了.
作者: ipaddr    时间: 2006-04-27 13:08
如果只是一个小网站使用这个数据库,那我也赞同夜猫子的观点,是有SQL卡住了.

很有可能是数据库设计不当,或查询使 用不当造成的.
作者: 北京野狼    时间: 2006-04-27 13:09
原帖由 ipaddr 于 2006-4-27 13:06 发表


用PHP打开数据库,并做查询,最后关闭,分别用PCONNECT,和CONNECT比较一下,跑一千个循环,比较一下就清楚了.


一千个循环是一个php程序里面做1000次,还是循环执行1000个php程序?
作者: ipaddr    时间: 2006-04-27 13:11
一个PHP里面循环1000次,

每次都打开,查询,关闭.

要是能摸拟成1000个并发连接,就更好了.
作者: 北京野狼    时间: 2006-04-27 13:12
原帖由 ipaddr 于 2006-4-27 13:11 发表
一个PHP里面循环1000次,

每次都打开,查询,关闭.

要是能摸拟成1000个并发连接,就更好了.


哦,问题是你为什么要在一个php 程序里面不停的连接数据库呢?

一般程序在开始连接一次就可以, 有什么php程序需要不停的重复connect.
作者: sickcat2004    时间: 2006-04-27 13:15
原帖由 ipaddr 于 2006-4-27 13:08 发表
如果只是一个小网站使用这个数据库,那我也赞同夜猫子的观点,是有SQL卡住了.

很有可能是数据库设计不当,或查询使 用不当造成的.

是这样的:原来的bbs 有3000多注册用户,平均在线200人左右
新的bbs 别人不知道目录测试访问中
作者: ipaddr    时间: 2006-04-27 13:18
原帖由 北京野狼 于 2006-4-27 13:12 发表


哦,问题是你为什么要在一个php 程序里面不停的连接数据库呢?

一般程序在开始连接一次就可以, 有什么php程序需要不停的重复connect.



大哥,这是测试呀,模拟1000次数据库连接,PCONNECT,和CONNECT的性格差距呀.
作者: sickcat2004    时间: 2006-04-27 13:18
几个大哥大帮看下小菜鸟弱弱问那个问题,我的session会话是保存在数据库里面的,然后又硬盘缓存了一次,但是新生成的文件权限不够不能被读取导致session失效 ,有什么法子能让代码生成的文件直接有读或者写的权限 呢,谢谢了!
作者: ipaddr    时间: 2006-04-27 13:19
原帖由 sickcat2004 于 2006-4-27 13:15 发表

是这样的:原来的bbs 有3000多注册用户,平均在线200人左右
新的bbs 别人不知道目录测试访问中



这个MYSQL服务器,只有这个新的BBS在用吗?有没有其它的程序在连这个服务器呢?

连接太多,是指MYSQL服务器的连接太多,而不是某个数据库,
作者: sickcat2004    时间: 2006-04-27 13:25
原帖由 ipaddr 于 2006-4-27 13:19 发表



这个MYSQL服务器,只有这个新的BBS在用吗?有没有其它的程序在连这个服务器呢?

连接太多,是指MYSQL服务器的连接太多,而不是某个数据库,

旧的在用,新的没有对外开放,原来的程序不是我开发的,有一个bbs,一个guestbook,然后公司的4个编辑都在用,
旧bbs有3000多注册用户,估计在线200人左右
作者: 北京野狼    时间: 2006-04-27 13:27
原帖由 ipaddr 于 2006-4-27 13:18 发表



大哥,这是测试呀,模拟1000次数据库连接,PCONNECT,和CONNECT的性格差距呀.


你怎么换不过来逻辑呢。 不用测试,我也知道这样PCONNECT,效率高。

但是你什么程序有机会利用PCONNECT 。 除非你用php做后台的东西。
作者: ipaddr    时间: 2006-04-27 13:31
原帖由 北京野狼 于 2006-4-27 13:27 发表


你怎么换不过来逻辑呢。 不用测试,我也知道这样PCONNECT,效率高。

但是你什么程序有机会利用PCONNECT 。 除非你用php做后台的东西。


请问你有机会用CONNECT吗?有机会用这个,就可以考虑,是否采用PCONNECT,

PCONNECT会提高点性能,这是事实,没必要去争这个问题吧?
作者: ipaddr    时间: 2006-04-27 13:32
原帖由 sickcat2004 于 2006-4-27 13:25 发表

旧的在用,新的没有对外开放,原来的程序不是我开发的,有一个bbs,一个guestbook,然后公司的4个编辑都在用,
旧bbs有3000多注册用户,估计在线200人左右


那可能是访问量比较大,导致数据库连接过多了,可以增多点连接,或优化程序,或者一个数据库,用一个服务器跑.
作者: 北京野狼    时间: 2006-04-27 13:33
原帖由 ipaddr 于 2006-4-27 13:31 发表


请问你有机会用CONNECT吗?有机会用这个,就可以考虑,是否采用PCONNECT,

PCONNECT会提高点性能,这是事实,没必要去争这个问题吧?


有机会用CONNECT, 没必要考虑PCONNECT
PCONNECT会提高点性能,不是事实。

我从未写过一个程序里面两次以上CONNECT的程序,不需要PCONNECT.  到底提高性能在那里?
作者: ipaddr    时间: 2006-04-27 13:33
原帖由 sickcat2004 于 2006-4-27 13:18 发表
几个大哥大帮看下小菜鸟弱弱问那个问题,我的session会话是保存在数据库里面的,然后又硬盘缓存了一次,但是新生成的文件权限不够不能被读取导致session失效 ,有什么法子能让代码生成的文件直接有读或者写的权限 ...



SESSION不是存放在/TMP吗/?

如果不是,你修改一个SESSION目 录的权限,chown apache.apache /sessiondir
chmod 0777 /sessiondir
作者: ipaddr    时间: 2006-04-27 13:35
原帖由 北京野狼 于 2006-4-27 13:33 发表


有机会用CONNECT, 没必要考虑PCONNECT
PCONNECT会提高点性能,不是事实。

我从未写过一个程序里面两次以上CONNECT的程序,不需要PCONNECT.  到底提高性能在那里?


大哥,你脑袋真是转不过弯呢.

一个程序里用一个CONNECT,如果这个程序,被访问1000次,请问是不是连接了1000次数据库?如果用PCONNECT,是不是会提高性能?


同一个程序,谁会有几个CONNET呀/?
作者: 北京野狼    时间: 2006-04-27 13:40
原帖由 ipaddr 于 2006-4-27 13:35 发表


大哥,你脑袋真是转不过弯呢.

一个程序里用一个CONNECT,如果这个程序,被访问1000次,请问是不是连接了1000次数据库?如果用PCONNECT,是不是会提高性能?


同一个程序,谁会有几个CONNET呀/?


我问过你是 一千个循环是一个php程序里面做1000次,还是循环执行1000个php程序?

如果程序被访问1000次 PCONNECT 未必是你想像的
作者: 北京野狼    时间: 2006-04-27 13:41
  1. 将 PHP 用作一个“外壳”。以这种方法运行,PHP 会为向您的 WEB 服务器提出的每个 PHP 页面请求生成并结束一个 PHP 解释器线程。由于该线程会随每个请求的结束而结束,因此任何在这个线程中利用的任何资源(例如指向 SQL 数据库服务器的连接)都会随线程的结束而关闭。在这种情况下,您使用永久连接不会获得任何地改变――因为它们根本不是永久的。
复制代码

作者: 北京野狼    时间: 2006-04-27 13:42
  1. 也是最常用的方法,是把 PHP 用作多过程 WEB 服务器的一个模块,这种方法目前只适用于 Apache。对于一个多过程的服务器,其典型特征是有一个父过程和一组子过程协调运行,其中实际生成 WEB 页面的是子过程。每当客户端向父过程提出请求时,该请求会被传递给还没有被其它的客户端请求占用的子过程。这也就是说当相同的客户端第二次向服务端提出请求时,它将有可能被一个不同的子过程来处理。在开启了一个永久连接后,所有请求 SQL 服务的后继页面都能够重新使用这个已经建立的 SQL Server 连接。
复制代码

作者: 北京野狼    时间: 2006-04-27 13:42
Pconnect也要看你是怎样使用php,和apache
作者: ipaddr    时间: 2006-04-27 13:42
原帖由 北京野狼 于 2006-4-27 13:40 发表


我问过你是 一千个循环是一个php程序里面做1000次,还是循环执行1000个php程序?

如果程序被访问1000次 PCONNECT 未必是你想像的



测试是在一个程序里循环1000 次,目的是模拟一个程序,被访问1000次.效果差不多.


这问题不需要再争论,你的意思是,PCONNECT不值得使 用,是吧?????

我的意思是,PCONNECT可以提高性能,一般情况下,可以用PCONNECT代替CONNECT.
作者: ipaddr    时间: 2006-04-27 13:44
原帖由 北京野狼 于 2006-4-27 13:42 发表
Pconnect也要看你是怎样使用php,和apache



你怎么爱钻牛角尖呢,

我问问你,用跑PHP的时候,还用IIS跑?

我们只讨论一般情况下,不是所有情况,不是绝对.!!!!!!
作者: 北京野狼    时间: 2006-04-27 13:44
原帖由 ipaddr 于 2006-4-27 13:42 发表



测试是在一个程序里循环1000 次,目的是模拟一个程序,被访问1000次.效果差不多.


两种测试方法,效果天差地别。  1个线程或者进程,和1000个线程
作者: 北京野狼    时间: 2006-04-27 13:45
原帖由 ipaddr 于 2006-4-27 13:44 发表



你怎么爱钻牛角尖呢,

我问问你,用跑PHP的时候,还用IIS跑?

我们只讨论一般情况下,不是所有情况,不是绝对.!!!!!!


和IIS毫无关系,apache也不见得有用处。 你不理解PCONNECT的真正的作用
作者: 北京野狼    时间: 2006-04-27 13:47
好了又一个说我 爱钻牛角尖的。  就到这里吧,
不过你如果有兴趣还是再看看资料、
作者: ipaddr    时间: 2006-04-27 13:47
原帖由 北京野狼 于 2006-4-27 13:44 发表


两种测试方法,效果天差地别。  1个线程或者进程,和1000个线程



唉,你这人,真是的.

PCONNECT是持久连接,一个线程跑1000次,和1000个线程跑一次,效果是相同的,PCONNECT的作用就是让这两个效果相同,明白吗?因为是持久连接,这个线程退出后,连接还是保持,下一个线程仍可使 用.
作者: ipaddr    时间: 2006-04-27 13:48
原帖由 北京野狼 于 2006-4-27 13:45 发表


和IIS毫无关系,apache也不见得有用处。 你不理解PCONNECT的真正的作用



我都说 了,不是绝对,是通常情况下,PCONNECT,性能会有提升.
作者: sickcat2004    时间: 2006-04-27 13:49
友谊第一,讨论第二
两位大哥都是我要十分感谢的对象
作者: 北京野狼    时间: 2006-04-27 13:49
一个线程跑1000次,和1000个线程跑一次,效果是差远了。
作者: ipaddr    时间: 2006-04-27 13:49
原帖由 sickcat2004 于 2006-4-27 13:49 发表
友谊第一,讨论第二
两位大哥都是我要十分感谢的对象





作者: ipaddr    时间: 2006-04-27 13:51
原帖由 北京野狼 于 2006-4-27 13:49 发表
一个线程跑1000次,和1000个线程跑一次,效果是差远了。



那你是真不理解什么叫PCONNECT了,

PCONNECT的作用,就在线程退出后,连接继续保持,
作者: 北京野狼    时间: 2006-04-27 13:54
原帖由 ipaddr 于 2006-4-27 13:51 发表



那你是真不理解什么叫PCONNECT了,

PCONNECT的作用,就在线程退出后,连接继续保持,


好了,就算你不了解线程见关系? 一个线程循环1000次至少不是并发吧。


PHP 会为向您的 WEB 服务器提出的每个 PHP 页面请求生成并结束一个 PHP 解释器线程。由于该线程会随每个请求的结束而结束,因此任何在这个线程中利用的任何资源(例如指向 SQL 数据库服务器的连接)都会随线程的结束而关闭。在这种情况下,您使用永久连接不会获得任何地改变――因为它们根本不是永久的。
作者: ipaddr    时间: 2006-04-27 13:57
原帖由 北京野狼 于 2006-4-27 13:54 发表


好了,就算你不了解线程见关系? 一个线程循环1000次至少不是并发吧。


PHP 会为向您的 WEB 服务器提出的每个 PHP 页面请求生成并结束一个 PHP 解释器线程。由于该线程会随每个请求的结束而结束,因此 ...

PHP 会为向您的 WEB 服务器提出的每个 PHP 页面请求生成并结束一个 PHP 解释器线程。由于该线程会随每个请求的结束而结束,因此任何在这个线程中利用的任何资源(例如指向 SQL 数据库服务器的连接)都会随线程的结束而关闭。在这种情况下,您使用永久连接不会获得任何地改变――因为它们根本不是永久的。


这是你所说的特殊情况,

这里说了,PCONNECT不是永久连接,而是等于CONNECT,而且,一般PHP和APACHE的结合方式,也不是这种吧?这是特殊情况.

我的意思是,真正的PCONNECT比CONNECT来说,是有性能优势.
作者: sickcat2004    时间: 2006-04-27 13:59
原帖由 ipaddr 于 2006-4-27 13:57 发表


这是你所说的特殊情况,

这里说了,PCONNECT不是永久连接,而是等于CONNECT,而且,一般PHP和APACHE的结合方式,也不是这种吧?这是特殊情况.

我的意思是,真正的PCONNECT比CONNECT来说,是有性能优势.

哈哈,两位大哥的观点看来并不是完全矛盾的啊
作者: 艾斯尼勒    时间: 2006-04-27 14:00
既然到这里了,问个pconnect的疑问,为什么到处都不建议使用pconnect?会带来什么坏处?比如lz的问题为什么可能是pconnect导致的?

ipaddr老兄,一个程序循环一千次连接关闭 和 循环一千次pconnect还是有区别的,不如用1000次include试试?还是require?我忘记用哪个了,也许可以发现区别。
作者: 北京野狼    时间: 2006-04-27 14:01
原帖由 ipaddr 于 2006-4-27 13:57 发表


这是你所说的特殊情况,

这里说了,PCONNECT不是永久连接,而是等于CONNECT,而且,一般PHP和APACHE的结合方式,也不是这种吧?这是特殊情况.

我的意思是,真正的PCONNECT比CONNECT来说,是有性能优势.


性能优势是有的,但要看环境。这段php 手册上的话, 我都给你发三次了, 是你没仔细看。

算了,总有人说我钻牛角。 你还是好好看看手册。

任何在这个线程中利用的任何资源(例如指向 SQL 数据库服务器的连接)都会随线程的结束而关闭
作者: moonking1025    时间: 2006-04-27 14:05
标题: 呵呵,你应该先看看连接数字呀
max_connections = 1000
这个不成,你设定这个,如果遇到攻击或者DNS反解析的时候,也会超过的
你先在能进入mysql>环境时,看看都有那些连接,如果有不认是的IP,就是你这个服务器遇到攻击了
你在启动mysql的时候添加 --skip-name-resolve 这个参数,如果还有问题,在说
作者: 夜猫子    时间: 2006-04-27 14:06
我用pconntion吃过亏的,感觉不是想象那么好,当时的情况也是造成了大量的队列堵塞,连接数用完,当时是mysql,后来放弃mysql用pgsql,但也没用过pconntion了。
似乎有不少人在这里出过问题,后来没深究这个原因,conntion也用得挺好的
我认为在表设计以及sql效率上下工夫获得的好处更多
作者: moonking1025    时间: 2006-04-27 14:12
标题: 这个是有可能的
原帖由 夜猫子 于 2006-4-27 12:07 发表
一旦队列开始卡住,卡1000个不是不能想象的,mysql这方面的记录不太好,总之是个可能吧,难说是主板上有虫子也说不定,楼主可以到机房瞧瞧,哈哈


这个是有可能的,不是主机的问题,可以说是一个老问题了,就是域名反解析,如果解析不了,那么这个IP的连接数字会越来越高,直到饱和连接。
你用SHOW PROCESSLIST 可以看到,基本就是几个IP,或者就是一个IP连接过来,就能把连接数字沾满。
作者: sickcat2004    时间: 2006-04-27 14:14
原帖由 moonking1025 于 2006-4-27 14:05 发表
max_connections = 1000
这个不成,你设定这个,如果遇到攻击或者DNS反解析的时候,也会超过的
你先在能进入mysql>环境时,看看都有那些连接,如果有不认是的IP,就是你这个服务器遇到攻击了
你在启动mysq ...

nnd 我机器什么权限都没有,就剩在论坛发贴啦 ,系统管理员又不懂linux ,主管和系统管理员又是穿一条裤子的,本来我早在两个星期前就可以做这些测试的啦,就是因为公司权限的问题搞得一拖再拖 ,我也搞聪明啦,别人叫干 就干,不叫干 我也不会去干 ,我也没有向 经理报告 ,有些郁闷 ,俗话说巧媳妇难能无米之吹啊,不知道有经验的大大们 遇到类似的问题是如何解决的
作者: 北京野狼    时间: 2006-04-27 14:18
原帖由 moonking1025 于 2006-4-27 14:12 发表


这个是有可能的,不是主机的问题,可以说是一个老问题了,就是域名反解析,如果解析不了,那么这个IP的连接数字会越来越高,直到饱和连接。
你用SHOW PROCESSLIST 可以看到,基本就是几个IP,或者就是一个IP ...


基本上不会有这样的事情。 难道你的mysql在公网上和所有人连接?

数据库应该在内网吧, 也就web服务器需要连接吧 ?和 域名反解析有什么关系?


牛角尖,又钻牛角尖。
作者: moonking1025    时间: 2006-04-27 14:20
标题: 怎么?你没有重启MYSQL的权限?
不会吧,你要没有重启权限,那就没办法了。公司不会这么搞吧,在说重启一下,几秒的事情呀,现在如果连接数字到最大了,别人也用不了了??
作者: sickcat2004    时间: 2006-04-27 14:24
原帖由 moonking1025 于 2006-4-27 14:20 发表
不会吧,你要没有重启权限,那就没办法了。公司不会这么搞吧,在说重启一下,几秒的事情呀,现在如果连接数字到最大了,别人也用不了了??

公司不会这样搞,但是部门主管和系统管理员喜欢这样搞 ,我申请个权限要3天才能批下来,汗,我过会才能用,现在我改成5000战时 顶得住 就是不知道能撑到多久
作者: moonking1025    时间: 2006-04-27 14:24
标题: 怎么说这个问题呢
是这样,一般内网开发,管理员很少设置服务器的域名反解析,但mysql回去检查,你用--skip-name-resolve 这个参数可以把这个检查去掉,基本上就没问题了,如果你要我详细给你解释这个问题,呵呵,那是逼我去读mysql的源码了
作者: 北京野狼    时间: 2006-04-27 14:26
决无可能,和域名反解析毫无关系。

反解析谁呢?
作者: moonking1025    时间: 2006-04-27 14:26
原帖由 sickcat2004 于 2006-4-27 14:24 发表

公司不会这样搞,但是部门主管和系统管理员喜欢这样搞 ,我申请个权限要3天才能批下来,汗,我过会才能用,现在我改成5000战时 顶得住 就是不知道能撑到多久


呵呵,那就设置一下环境变量吧,你用SHOW PROCESSLIST 看看,都是那些连接连过来的。
我目前也没有其他办法
作者: sickcat2004    时间: 2006-04-27 14:28
原帖由 moonking1025 于 2006-4-27 14:24 发表
是这样,一般内网开发,管理员很少设置服务器的域名反解析,但mysql回去检查,你用--skip-name-resolve 这个参数可以把这个检查去掉,基本上就没问题了,如果你要我详细给你解释这个问题,呵呵,那是逼我去读mysq ...

moonking兄 ,帮我看下
http://bbs.chinaunix.net/viewthr ... &extra=page%3D1
这贴 ,和本贴同时发的,怎么一个天上,一个地下啊,不理解啊,不理解
作者: moonking1025    时间: 2006-04-27 14:29
原帖由 北京野狼 于 2006-4-27 14:26 发表
决无可能,和域名反解析毫无关系。

反解析谁呢?


出现这个问题,肯定是需要其他服务器,连接这台数据库服务器,不会是本地使用,既然有远程连接,你说反解谁呢?呵呵
作者: 北京野狼    时间: 2006-04-27 14:33
原帖由 moonking1025 于 2006-4-27 14:29 发表


出现这个问题,肯定是需要其他服务器,连接这台数据库服务器,不会是本地使用,既然有远程连接,你说反解谁呢?呵呵


你不是说在内网吗?  你们数据库居然可以远程连接,牛。知道 IP 都可以直接把你们数据库搞死。
作者: moonking1025    时间: 2006-04-27 14:36
标题: 呵呵,本地和内网是不一样的
本地指的是本机,一般是localhost,就是局域网内部,只要是其他服务器,对于mysql来说,也是远程访问。呵呵,狼兄,咱们两个就打住一下吧
作者: 北京野狼    时间: 2006-04-27 14:40
把其他内网的服务器加到/etc/hosts就可以
作者: sickcat2004    时间: 2006-04-27 14:48
原帖由 moonking1025 于 2006-4-27 14:29 发表


出现这个问题,肯定是需要其他服务器,连接这台数据库服务器,不会是本地使用,既然有远程连接,你说反解谁呢?呵呵

两位大大,是远程服务器,是可以远程连接,但是是限制了ip 的,呵呵,两位老大务须多女
作者: 北京野狼    时间: 2006-04-27 14:55
原帖由 sickcat2004 于 2006-4-27 14:48 发表

两位大大,是远程服务器,是可以远程连接,但是是限制了ip 的,呵呵,两位老大务须多女


我和你都理解错了, 人家是内网的服务器。

真正的互联网上这么做,限制IP没用处的。 因为你的端口是开放的。 一样可以搞破坏
作者: james.liu    时间: 2006-04-27 15:08
要想取得权限也8难,,估计方式是否被接受。

难得看到这么个帖子,,请继续。。。我肚子疼(刚才看帖笑得)
作者: ge126    时间: 2006-04-27 16:06
pconnect()
用一次挂一次,现在都换成connect close了。
作者: crazysoul    时间: 2006-04-27 16:08
不管楼主问题,针对mysql_pconnect()讨论:

使用MYSQL连接:
一般我们在PHP中连接MYSQL时,每打开一个连接后都会保留这个"连接标识符"到一个变量,以后每有数据查询时都是反复使用这个连接标识符连跟MYSQL通讯.
所以在一个脚本执行完之前,使用普通连接和持久连接是没什么区别的(因为都是用同一个连接).

普通连接的生命周期:
一般来说,一个PHP脚本从第一行到执行最后一个字符,把完整的内容输出到用户浏览器上后就完成了它的生命周期(一个PHP进程).
每对一个页面访问一次,就相当于触发了一个PHP进程.如果这个PHP没使用持久连接,则每被访问一次都要向MYSQL申请一次新连接.

持久连接的好处:
首先,当连接的时候本函数将先尝试寻找一个在同一个主机上用同样的用户名和密码已经打开的(持久)连接,如果找到,则返回此连接标识而不打开新连接。

其次,当脚本执行完毕后到 SQL 服务器的连接不会被关闭,此连接将保持打开以备以后使用(mysql_close() 不会关闭由 mysql_pconnect() 建立的连接)。


意思是说,同一个页面(或者使用相同访问MYSQL参数的PHP页面)多次被访问时,使用的都是同一个MYSQL连接标识.

持久连接的坏处:
在使用永久连接时还有一些特别的问题需要注意。例如在永久连接中使用数据表锁时,如果脚本不管什么原因无法释放该数据表锁,其随后使用相同连接的脚本将会被永久的阻塞,使得您需要重新启动 httpd 服务或者数据库服务。另外,在使用事务处理时,如果脚本在事务阻塞产生前结束,则该阻塞也会影响到使用相同连接的下一个脚本。


就是说,即使某个脚本进入了死循环,只要不是对MYSQL操作,都不会影响另外一个进程的访问;而反之,一旦是什么原因导致了这个连接对MYSQL死锁,那使用这个连接来访问的脚本都有问题了(如果这时使用的是非持久连接的,就会新开一个连接,而不会被之前的死锁影响)

我的结论:
所以,一般来说,使用持久连接应该比较高效的,因为免去了打开新连接所需的握手及验证(这是我的猜想,原理应该跟SESSION建立差不多),但就要注意数据库死锁问题,因为mysql_close() 也关不了持久连接,只能重启服务(上面的注释写的很明白了).

但发现有些人实际使用说持久连接总是有问题,那可能是PHP对这个实现的有BUG,但这个设置的思想是不错的.
作者: sickcat2004    时间: 2006-04-27 20:58
标题: 大大来看我的测试数据
show processlist;

+-----+---------+------------------+-----------+---------+-------+-------+------------------+
| Id  | User    | Host             | db        | Command | Time  | State | Info             |
+-----+---------+------------------+-----------+---------+-------+-------+------------------+
|   1 | a_master_replece | localhost        | bbs       | Sleep   |   460 |       | NULL             |
|   2 | a_master_replece | localhost        | web       | Sleep   |  1693 |       | NULL             |
|   3 | a_master_replece | localhost        | web       | Sleep   | 10978 |       | NULL             |
|   4 | a_master_replece | localhost        | web       | Sleep   | 11567 |       | NULL             |
|   5 | a_master_replece | localhost        | web       | Sleep   |   469 |       | NULL             |
|   7 | a_master_replece | localhost        | web       | Sleep   | 13396 |       | NULL             |
|   8 | a_master_replece | localhost        | web       | Sleep   |  1049 |       | NULL             |
|   9 | a_master_replece | localhost        | web       | Sleep   |  1390 |       | NULL             |
|  10 | a_master_replece | localhost        | web       | Sleep   |  2244 |       | NULL             |
|  11 | a_master_replece | localhost        | web       | Sleep   | 19291 |       | NULL             |
|  12 | a_master_replece | localhost        | bbs       | Sleep   |  2399 |       | NULL             |
|  13 | a_master_replece | localhost        | web       | Sleep   | 16766 |       | NULL             |
|  14 | a_master_replece | localhost        | bbs       | Sleep   |  9868 |       | NULL             |
|  15 | a_master_replece | localhost        | bbs       | Sleep   |  2848 |       | NULL             |
|  16 | a_master_replece | localhost        | bbs       | Sleep   |  1782 |       | NULL             |
|  17 | a_master_replece | localhost        | web       | Sleep   | 14778 |       | NULL             |
|  18 | a_master_replece | localhost        | web       | Sleep   |  1351 |       | NULL             |
|  19 | a_master_replece | localhost        | web       | Sleep   | 12823 |       | NULL             |
|  20 | a_master_replece | localhost        | web       | Sleep   |  1445 |       | NULL             |
|  21 | a_master_replece | localhost        | web       | Sleep   | 11303 |       | NULL             |
|  22 | a_master_replece | localhost        | web       | Sleep   | 19137 |       | NULL             |
|  23 | a_master_replece | localhost        | bbs       | Sleep   |  1179 |       | NULL             |
|  24 | a_master_replece | localhost        | bbs       | Sleep   |  3694 |       | NULL             |
|  26 | a_master_replece | localhost        | bbs       | Sleep   |   516 |       | NULL             |
|  27 | a_master_replece | localhost        | bbs       | Sleep   |  8357 |       | NULL             |
|  28 | a_master_replece | localhost        | bbs       | Sleep   |  1783 |       | NULL             |
|  29 | a_master_replece | localhost        | bbs       | Sleep   |   975 |       | NULL             |
29 | a_master_replece | localhost        | bbs       | Sleep   |   975 |       | NULL             |
|  30 | a_master_replece | localhost        | web       | Sleep   |  1266 |       | NULL             |
|  31 | a_master_replece | localhost        | web       | Sleep   | 11751 |       | NULL             |
|  32 | a_master_replece | localhost        | web       | Sleep   |  2197 |       | NULL             |
|  33 | a_master_replece | localhost        | web       | Sleep   |  1390 |       | NULL             |
|  34 | a_master_replece | localhost        | web       | Sleep   | 13430 |       | NULL             |
|  35 | a_master_replece | localhost        | web       | Sleep   |  4172 |       | NULL             |
|  36 | a_master_replece | localhost        | web       | Sleep   | 17921 |       | NULL             |
|  37 | a_master_replece | localhost        | bbs       | Sleep   |  4297 |       | NULL             |
|  38 | a_master_replece | localhost        | bbs       | Sleep   |  1107 |       | NULL             |
|  39 | a_master_replece | localhost        | bbs       | Sleep   |  1227 |       | NULL             |
|  40 | a_master_replece | localhost        | bbs       | Sleep   |   211 |       | NULL             |
|  41 | a_master_replece | localhost        | bbs       | Sleep   |   427 |       | NULL             |
|  44 | a_master_replece | localhost        | web       | Sleep   | 17175 |       | NULL             |
|  46 | a_master_replece | localhost        | web       | Sleep   |  1949 |       | NULL             |
|  47 | a_master_replece | localhost        | web       | Sleep   | 16765 |       | NULL             |
|  49 | a_master_replece | localhost        | web       | Sleep   | 19345 |       | NULL             |
|  51 | a_master_replece | localhost        | web       | Sleep   | 19289 |       | NULL             |
|  52 | a_master_replece | localhost        | web       | Sleep   | 14793 |       | NULL             |
|  54 | a_master_replece | localhost        | bbs       | Sleep   |   761 |       | NULL             |
|  55 | a_master_replece | localhost        | bbs       | Sleep   |   482 |       | NULL             |
|  56 | a_master_replece | localhost        | web       | Sleep   | 11487 |       | NULL             |
|  57 | a_master_replece | localhost        | web       | Sleep   |  1775 |       | NULL             |
|  58 | a_master_replece | localhost        | web       | Sleep   | 13076 |       | NULL             |
|  59 | a_master_replece | localhost        | web       | Sleep   | 11744 |       | NULL             |
|  60 | a_master_replece | localhost        | web       | Sleep   | 14691 |       | NULL             |
|  61 | a_master_replece | localhost        | web       | Sleep   | 15012 |       | NULL             |
|  62 | a_master_replece | localhost        | web       | Sleep   | 11947 |       | NULL             |
|  63 | a_master_replece | localhost        | web       | Sleep   |  1399 |       | NULL             |
|  64 | a_master_replece | localhost        | web       | Sleep   | 16684 |       | NULL             |
|  65 | a_master_replece | localhost        | web       | Sleep   |  1962 |       | NULL             |
67 | a_master_replece | localhost        | web       | Sleep   | 13156 |       | NULL             |
|  68 | a_master_replece | localhost        | bbs       | Sleep   |  2863 |       | NULL             |
|  69 | a_master_replece | localhost        | bbs       | Sleep   |  1182 |       | NULL             |
|  70 | a_master_replece | localhost        | web       | Sleep   |  1709 |       | NULL             |
|  71 | a_master_replece | localhost        | bbs       | Sleep   |  8131 |       | NULL             |
|  72 | a_master_replece | localhost        | bbs       | Sleep   |   266 |       | NULL             |
|  73 | a_master_replece | localhost        | bbs       | Sleep   |  5100 |       | NULL             |
|  74 | a_master_replece | localhost        | bbs       | Sleep   |  2845 |       | NULL             |
|  75 | a_master_replece | localhost        | bbs       | Sleep   |  1276 |       | NULL             |
|  76 | a_master_replece | localhost        | bbs       | Sleep   |  2499 |       | NULL             |
|  77 | a_master_replece | localhost        | bbs       | Sleep   |  8551 |       | NULL             |
|  78 | a_master_replece | localhost        | bbs       | Sleep   |  2462 |       | NULL             |
|  79 | a_master_replece | localhost        | bbs       | Sleep   |  4210 |       | NULL             |
|  81 | a_master_replece | localhost        | web       | Sleep   |  1445 |       | NULL             |
|  82 | a_master_replece | localhost        | web       | Sleep   |  1266 |       | NULL             |
|  83 | a_master_replece | localhost        | web       | Sleep   |   473 |       | NULL             |
|  84 | a_master_replece | localhost        | web       | Sleep   |  1750 |       | NULL             |
|  85 | a_master_replece | localhost        | web       | Sleep   |  1950 |       | NULL             |
|  86 | a_master_replece | localhost        | bbs       | Sleep   |   542 |       | NULL             |
|  87 | a_master_replece | localhost        | bbs       | Sleep   |  4367 |       | NULL             |
|  89 | a_master_replece | localhost        | bbs       | Sleep   |  3649 |       | NULL             |
|  90 | a_master_replece | localhost        | bbs       | Sleep   |   404 |       | NULL             |
|  91 | a_master_replece | localhost        | bbs       | Sleep   |  4180 |       | NULL             |
|  92 | a_master_replece | localhost        | bbs       | Sleep   |   706 |       | NULL             |
|  93 | a_master_replece | localhost        | bbs       | Sleep   |   399 |       | NULL             |
|  95 | a_master_replece | localhost        | bbs       | Sleep   |   873 |       | NULL             |
|  96 | a_master_replece | localhost        | bbs       | Sleep   |  4316 |       | NULL             |
|  98 | a_master_replece | localhost        | bbs       | Sleep   |   428 |       | NULL             |
|  99 | a_master_replece | localhost        | bbs       | Sleep   |  1832 |       | NULL             |
以下省略
198 | a_master_replece | localhost        | web       | Sleep   |  2197 |       | NULL             |
| 201 | root    | 59.40.0.119:1786 | guestbook | Sleep   |  1424 |       | NULL             |
| 202 | root    | 59.40.0.119:1796 | init_data | Sleep   |  1341 |       | NULL             |
| 203 | a_master_replece | localhost        | web       | Sleep   |  1399 |       | NULL             |
| 204 | a_master_replece | localhost        | web       | Sleep   |  1351 |       | NULL            
| 205 | root    | 59.40.0.119:1214 | web       | Sleep   |  1297 |       | NULL             |
159 rows in set (0.00 sec)

mysql> pager grep -v Sleep
PAGER set to 'grep -v Sleep'
mysql> show processlist;
+-----+---------+------------------+-----------+---------+-------+-------+------------------+
| Id  | User    | Host             | db        | Command | Time  | State | Info             |
+-----+---------+------------------+-----------+---------+-------+-------+------------------+
| 219 | root    | localhost        | NULL      | Query   |     0 | NULL  | show processlist |
+-----+---------+------------------+-----------+---------+-------+-------+------------------+
163 rows in set (0.01 sec)
作者: 北京野狼    时间: 2006-04-28 09:53
都是sleep. 还是去掉pconnect试试
作者: rngr    时间: 2006-04-28 15:47
争论得可够激烈的.

LZ的问题应该是很简单的.

反解析的毛病是存在的.

解决办法是非常简单的.  编辑/etc/hosts,  把127.0.0.1  localhost放到第一行, 如果没有就插入.

但是LZ的权限是不够的.
作者: sickcat2004    时间: 2006-04-28 17:55
临时权限操作一把
cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       test    localhost.localdomain   localhost

说明不是反解析的问题


mysql -u**** -p******
mysql>show processlist;
-----+------+---------------------+------+---------+------+-------+------------------+
| Id  | User | Host                | db   | Command | Time | State | Info             |
+-----+------+---------------------+------+---------+------+-------+------------------+
| 134 | **** | 59.40.168.242:47421 | web  | Sleep   | 6935 |       | NULL             |
| 162 | **** | 59.40.168.242:45998 | web  | Sleep   | 3544 |       | NULL             |
| 175 |**** | localhost           | NULL | Query   |    0 | NULL  | show processlist |
+-----+------+---------------------+------+---------+------+-------+------------------+
3 rows in set (0.00 sec)

mysql> Pager grep -v Sleep
PAGER set to 'grep -v Sleep'
mysql> show processlist;
+-----+------+---------------------+------+---------+------+-------+------------------+
| Id  | User | Host                | db   | Command | Time | State | Info             |
+-----+------+---------------------+------+---------+------+-------+------------------+
| 175 | root | localhost           | NULL | Query   |    0 | NULL  | show processlist |
+-----+------+---------------------+------+---------+------+-------+------------------+
3 rows in set (0.00 sec)


注意以上数据是我屏蔽掉以前的bbs的操作结果,说明偶的代码没有问题吧! ,还是用的是pconnet,呵呵

有时间换connect 测试一把,就有个对比啦




欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2