千万级记录的Discuz论坛导致MySQL CPU 100%的优化笔记


日期: 2007-07-02 00:04 | 联系我
关注我: Telegram, Twitter

  注:本文最后更新于:2007-11-17

  2007年3月,我写过一篇文章《解决一个 MySQL 服务器进程 CPU 占用 100%的技术笔记》( https://www.xiaohui.com/weekly/20070307.htm ),谈到自己在解决一个拥有 60 万条记录的 MySQL 数据库访问时,导致 MySQL CPU 占用 100% 的经过。在解决问题完成优化(optimize)之后,我发现 Discuz 论坛也存在这个问题,当时稍微提了一下:

发现此主机运行了几个 Discuz 的论坛程序, Discuz论坛的好几个表也存在着这个问题。于是顺手一并解决,cpu占用再次降下来了。

  前几天,一位朋友通过这篇文章找到了我,说他就是运行最新的 discuz 版本,MySQL 占用 CPU 100%,导致系统假死,每天都要重启好几次,花了一个多月的时间一直没有解决,希望我帮忙一下。经过检查,他的这个论坛最重要的几个表中,目前 cdb_members 表,有记录 6.2 万;cdb_threads 表,有记录 11万;cdb_posts表,有记录 1740 万;所有数据表的记录加起来,超过 2000 万;数据库的大小超过 1GB。经过半天的调试,总算完成了 discuz 论坛优化,于是将其解决经过记录在这篇文章 https://www.xiaohui.com/dev/server/20070701-discuz-mysql-cpu-100-optimize.htm 中。

  2007年3月我发现 discuz 论坛的数据库结构设计有一些疏忽,有许多查询子句的条件比较,都没有建立 Index 索引。当时我所检查的那个数据表,记录只有几千条,因此对 CPU 负荷不大。现在这个数据库表,上千万的记录检索,可以想象,如果数据表结构设计不规范,没有提供索引,所耗费的时间是一个恐怖的数字。有关 MySQL 建立索引的重要性,可以参见我的这篇文章底部的说明:https://www.xiaohui.com/weekly/20070307.htm

  为了调试方便,我从 dizcus 的官网下载了其最新的 Dizcus! 5.5.0 论坛程序.

  我首先检查了 my.ini 的参数配置,一切正常。进入 MySQL 的命令行,调用 show processlist 语句,查找负荷最重的 SQL 语句,结合 Discuz 论坛的源码,发现有以下语句导致 CPU 上升:

mysql> show processlist;
+-----+------+----------------+---------+---------+------+------------+---------
-----------------------------------------------------------------+
| Id  | User | Host           | db      | Command | Time | State      | Info
                                                                 |
+-----+------+----------------+---------+---------+------+------------+---------
-----------------------------------------------------------------+
| 363 | root | localhost:1393 | history | Query   |    0 | statistics | SELECT C
OUNT(*) FROM cdb_pms WHERE msgfromid=11212 AND folder='outbox' |
+-----+------+----------------+---------+---------+------+------------+---------
  检查 cdb_pms 表的结构:
mysql> show columns from cdb_pms;
+-----------+------------------------+------+-----+---------+----------------+
| Field     | Type                   | Null | Key | Default | Extra          |
+-----------+------------------------+------+-----+---------+----------------+
| pmid      | int(10) unsigned       | NO   | PRI | NULL    | auto_increment |
| msgfrom   | varchar(15)            | NO   |     |         |                |
| msgfromid | mediumint(8) unsigned  | NO   | MUL | 0       |                |
| msgtoid   | mediumint(8) unsigned  | NO   | MUL | 0       |                |
| folder    | enum('inbox','outbox') | NO   |     | inbox   |                |
| new       | tinyint(1)             | NO   |     | 0       |                |
| subject   | varchar(75)            | NO   |     |         |                |
| dateline  | int(10) unsigned       | NO   |     | 0       |                |
| message   | text                   | NO   |     |         |                |
| delstatus | tinyint(1) unsigned    | NO   |     | 0       |                |
+-----------+------------------------+------+-----+---------+----------------+
10 rows in set (0.00 sec)
  这条语句: WHERE msgfromid=11212 AND folder='outbox',我们看到,在 cdb_pms 表中,msgfromid 字段已经建立了索引,但是,folder 字段并没有。目前这个表已经有记录 7823 条。显然,这会对查询造成一定影响。于是为其建立索引:
mysql> ALTER TABLE `cdb_pms` ADD INDEX ( `folder` );
Query OK, 7823 rows affected (1.05 sec)
Records: 7823  Duplicates: 0  Warnings: 0
  继续检查:
mysql> show processlist;
+------+------+----------------+---------+---------+------+------------+--------
--------------------------------------------------------------------------------
--------------+
| Id   | User | Host           | db      | Command | Time | State      | Info

              |
+------+------+----------------+---------+---------+------+------------+--------
--------------------------------------------------------------------------------
--------------+
              |
| 1583 | root | localhost:2616 | history | Query   |    0 | statistics | SELECT
t.tid, t.closed, f.*, ff.*  , f.fid AS fid
                        FROM cdb_threads t
                        INNER JOIN cdb_forums f |
+------+------+----------------+---------+---------+------+------------+--------
--------------------------------------------------------------------------------
--------------+
1 rows in set (0.00 sec)
  这条 SQL 语句是针对最重要的数据表 cdb_threads 进行操作的,由于 show processlist 没有将这条 SQL 语句全部显示完全,经对比 Discuz 论坛的源码,此SQL语句的原型位于 common.inc.php 的 Line 283,内容如下:
$query = $db->query("SELECT t.tid, t.closed,".(defined('SQL_ADD_THREAD') ?
    SQL_ADD_THREAD : '')." f.*, ff.* $accessadd1 $modadd1, f.fid AS fid
    FROM {$tablepre}threads t
    INNER JOIN {$tablepre}forums f ON f.fid=t.fid
    LEFT JOIN {$tablepre}forumfields ff ON ff.fid=f.fid $accessadd2 $modadd2
    WHERE t.tid='$tid'".($auditstatuson ? '' : " AND t.displayorder>=0")." LIMIT 1");
  经检查,数据表 cdb_threads, 并没有针对 displayorder 字段建立索引。在 discuz 论坛中,displayorder字段多次参与了 Where 子句的比较。于是为其建立索引:
mysql> ALTER TABLE `cdb_threads` ADD INDEX ( `displayorder` );
Query OK, 110330 rows affected (2.36 sec)
Records: 110330  Duplicates: 0  Warnings: 0
  此时 cpu 已经轻微下降了一部分。

  继续检查,发现 下面这条 discuz 的 SQL 语句,也导致负荷增加,这条语句位于 rss.php 程序中的第 142 行。

    $query = $db->query("SELECT t.tid, t.readperm, t.price, t.author, t.dateline, t.subject, p.message
    FROM {$tablepre}threads t
    LEFT JOIN {$tablepre}posts p ON p.tid=t.tid AND p.first=1
    WHERE t.fid='$fid' AND t.displayorder>=0
    ORDER BY t.dateline DESC LIMIT $num");
  在这个 Order by 子句中,用到了 cdb_threads 表中的 dataline 字段。这个字段是用来存储 unixtime 的时间戳,在整个论坛程序中,大部分时候数据的排序也是基于这个字段,竟然没有建立索引。于是加上:
mysql> ALTER TABLE `cdb_threads` ADD INDEX ( `dateline` );
Query OK, 110330 rows affected (12.27 sec)
Records: 110330  Duplicates: 0  Warnings: 0
  查找占用 CPU 高负茶的 SQL 语句,是一件麻烦而又枯燥的事,需要一条一条排除、分析。后面的工作,都是依此类推,经过检查,共查出有八处地方,需要增加索引,如果你也碰到了 discuz 5.5.0 论坛导致 cpu 占用 100% 的情况,可以直接将下列语句复制过去,在 mysql 的命令行下执行即可:
ALTER TABLE `cdb_pms` ADD INDEX ( `folder` );
ALTER TABLE `cdb_threads` ADD INDEX ( `displayorder` );
ALTER TABLE `cdb_threads` ADD INDEX ( `dateline` );
ALTER TABLE `cdb_threads` ADD INDEX ( `closed` );
ALTER TABLE `cdb_threadsmod` ADD INDEX ( `dateline` );
ALTER TABLE `cdb_sessions` ADD INDEX ( `invisible` );
ALTER TABLE `cdb_forums` ADD INDEX ( `type` );
ALTER TABLE `cdb_forums` ADD INDEX ( `displayorder` );
  注意:“cdb_” 是 discuz 论坛的默认数据表前缀。如果你的表名前缀不是 “cdb_”,则应该改成你对应的表名。例如:my_threads, my_pms 等等。

  完成这些结构的优化之后,整个系统的 CPU 负荷在 10%~20%左右震荡,问题解决。

  我很奇怪,设计数据库结构,是一个数据库开发人员的基本功,discuz 论坛好歹也是一个发展了有六七年的论坛了,为何数据库结构设计得如此糟糕?我想也许有如下三个原因:

  • 数据库开发人员设计时本身的疏忽
  • 故意留下的缺陷,当普通论坛没有上数量级的记录时,不会感觉到这个问题,当数据量增大(例如千万级),此问题突现,以便针对用户提供个性服务收取服务费.呵呵,估且以最大的恶意来猜测此事,玩笑而已,不必当真。:) 
  • 另一个可能就是用户的论坛是从低版本升级而来,程序升了级,但数据结构也许没有做相应的更新

附1: 补充笔记 2007-07-09

  今天查看网站日志的 reffer, 发现在 discuz 的官方论坛上,有人就此文引起了一些争论: http://www.discuz.net/thread-673887-1-1.html。discuz 的管理员和管理员有如下言论:

引用自 cnteacher:

恰恰相反,discuz 的优化措施和数据库的索引是按照大规模论坛设计的。

TO 一楼:数据库结构的设计都是按照程序应用来进行的,使用任何非Discuz! 标准版本以外的代码和程序,或者变更标准数据结构,均可能遇到不可预知的各种问题。

引用自 童虎:

你们可以看看xxxxx, xxxx之类的比较大型的网站,这种网站使用dz论坛都没有问题,说明dz标准程序是没有问题,出现楼主说的情况,多半属于服务器或者安装一些插件造成的

  显然将问题推给插件的原因是不正确的.举个简单的例子:在最新的 discuz 5.5.0 forumdisplay.php 第183 行,有如下语句:

$query = $db->query("SELECT uid, groupid, username, invisible,
  lastactivity, action FROM {$tablepre}sessions 
  WHERE $guestwhere fid='$fid' AND invisible=0");
  这里的 invisible 并没有建立索引。本文中有评论认为 session 表是内存表, 速度会很快。理论是如此。不过我在 show processlist 中,观察到上面这条语句占用了大量 CPU, 所以也将其一并加上了 index。cdb_threads 中的 closed 等字段, 也多次参与 where 运算, 也没有建立索引。这些运算的语句, 是 discuz 自己的程序中的。

附2: 补充笔记 2007-11-11

  自从这篇笔记发表以来,在我的这篇文章的评论、以及我的联系消息中,就经常收到许多下面两种类型的评论和邮件:一、许多技术人员批评我胡说八道、Dizcus 论坛不需要做优化或者不能乱建索引的;二、许多使用Dizcus 的站长找我“冰天雪地裸体跪求”解决他们的 CPU 占用 100% 的问题。

  一、关于 MySQL 数据库优化技术上的争论,我的观点再次声明如下:

  1. 技术上的争论是可以放开了讨论的。而我的水平也确实只是半瓶水,对数据库的理论知识也只懂这么点,牛牛们的批评,我虚心接心,非常感谢。但是,评论里的批评不要上升到人身攻击,否则,我的地盘我作主,直接删除。

  2. 数据库的优化,要涉及到的方方面面很多。关说理论是没有用的,得靠事实说话。一个千万级数据库的实例优化说明不了问题,两个千万级的数据库优化也许还说明不了问题,但我相信,三个、四个、五个总是可以说明问题的,--截止到 2007.11.09,我已经帮助朋友优化过五个记录数超过 1000 万的 discuz 论坛了。我想事实胜于雄辩:优化之前,cpu 都是 100%;优化之后,cpu 降到 30%~40% 左右。没错,做 ADD INDEX 会增加数据库 INSERT/UPDATE 时的开销,但别忘了论坛最主要的操作,是 SELECT 查询。

  二、关于找我帮忙解决数据库优化的评论和邮件,答复如下:

  1. 数据库的优化,不同的版本有不同的实际情况,优化一个 database,短则三两小时,慢则两三天。我的精力有限,不可能一一帮到。
  2. 对于没有收入的个人网站,我可以在月末的空余时间帮忙。请事先与我联系好。
  3. 对于有收入的网站,请带价格与我联系,或者直接安排美女请我吃饭,否则免谈。:) 请不要来信问“优化我们这个论坛你要多少费用?”这样没营养的话,请直接说“帮我们优化 XXXX 网站或论坛, XXXX RMB 可以不?”,我觉得合适就会回复你。大家都很忙。
  4. 请通过 https://www.xiaohui.com/support/ 邮件与我联系。不要在评论里留个 QQ 号然后要我加你,我不会时时看评论。

附3: 补充笔记 2007-11-17: 关于装有首页四格插件的 dz 论坛导致 MySQL 占用 大量CPU 的分析

  今天手机巴士的站长( http://bbs.sj84.com )找到我,他的基于 Discuz 的论坛,也存在 CPU 占用 100% 的问题,服务器从 Win 2003 换到 CentOS,内存 2G, CPU 1.86G, 数据:cdb_threads 4 万,cdb_posts 96 万,cdb_members 35 万,已经按我上面文章所说的优化过索引。按说这个配置足够运行论坛了,但问题一直得不到解决。

  经过调试,将慢查询的结果 dump 到 /usr/local/mysql/var/localhost-slow.log,运行 /usr/local/mysql/bin/mysqldumpslow /usr/local/mysql/var/localhost-slow.log 查看,结合 show processlist 命令,发现慢查询集中在下列语句:

SELECT t.*, f.name FROM cdb_threads t, cdb_forums f WHERE 
t.fid<>'S' 
AND f.fid=t.fid 
AND f.fid NOT IN (N,N,N,N) 
AND t.closed NOT LIKE 'S' 
AND t.replies !=N 
AND t.displayorder>=N 
ORDER BY t.views DESC LIMIT N, N
  然而搜索 Dizcus 论坛的源码,并没有找到这行代码。怀疑是插件的原因。经查,论坛装了首页四格的插件,这行语句位于 include/toplist.php 中: 仔细检查这行代码,发现存在许多性能或语法规范上的问题:

  1. AND t.closed NOT LIKE 'S':t.closed 是数值字段,不应该用 LIKE 'S' 的形式参与比较。 
  2. ORDER BY t.views: t.views 在 dizcus 的原始数据表中,是没有做索引的。
  3. SELECT t.*: 这种写法,是不被推荐的。如果要选择某个表内的所有字段,最好是按实全部写出来,例如:select t.aa, t.bb, t.cc, t.dd, ...
  4. WHERE t.fid <> 'S': t.fid 是数值型字段,不应该写成 字符比较的形式。这个对性能影响不大,是个编程规范的问题。
  5. ....

  toplist.php 的其他三条 sql 语句,都存在这些问题。如果要针对他的 sql 语句去优化 MySQL 结构,会带来不良的后果;如果直接改他的 toplist.php 程序,如果站长以后升级 toplist.php 又怕带来不兼容问题。于是我建议他干脆关闭首页四格插件。

  关闭首页四格插件之后,CPU 降到 18% 左右震荡,表现非常良好。

  如果是我来写首页四格的程序,我不会采用这种方案,我会用定时15分钟或30分钟查询一次数据库,将结果写入 TXT 文件或临时表,然后程序再从中读取,效率会高许多。

  结论:

  1. 如果装了插件的论坛碰到 CPU 高负荷时,建议关掉插件再评估性能。
  2. 慎装第三方插件。没事不要乱插。:)

附4:补充笔记 2008-06-10:这篇文章,重要的是分析过程,而不是进行修正的那段代码

  最近有几位在评论中留言,以及给我 EMAIL,说到将我在文中给出的 那8行 ALTER TABLE 代码,在他的出现 CPU 100% 的 dz 论坛上,用了之后没有效果。

  我的解释如下:这段代码,不能保证在 dz 的所有版本下通用。具体问题,要具体分析。这段代码,是我在 Dizcus! 5.5.0 的版本的基本下进行分析得出的校正结果。其他的版本,不敢保证。

  这篇文章的重点,并不是作为结果的这段代码,而是如何得出这个结果的分析过程。知道了原理,你自己一样可以分析。

附5: 相关文章:

解决一个 MySQL 服务器进程 CPU 占用 100%的技术笔记

标签: CPU 占用 | MySQL | Discuz

 文章评论

第 1 楼  发表于 2007-07-01 13:24 | hcy1122 的所有评论
支持你,小辉!
我们要继续努力
你现在在哪呢?好久没有你写关于自己的随笔了
回复于 2007-07-02 02:06:
在长沙.:)

第 2 楼  发表于 2007-07-02 10:02 | 游客 的所有评论
索引不是越多越好,建立了索引之后,插入更新速度就是非常慢,只是select能比较快,这两者之间要有一个均衡点

第 3 楼  发表于 2007-07-02 10:33 | pzhai 的所有评论
估计discuz!越来越看重中小论坛的市场了吧 ,再说本来mysql对海量数据就不太友好,发展瓶颈吧

第 4 楼  发表于 2007-07-09 12:07 | vagabond 的所有评论
写不得不错啊,大哥现在从事什么工作
程序员出来都了什么工作

第 5 楼  发表于 2007-07-10 10:05 | 继续革命 的所有评论
$query = $db->query("SELECT uid, groupid, username, invisible,
lastactivity, action FROM {$tablepre}sessions
WHERE $guestwhere fid='$fid' AND invisible=0");


session 表为内存表,且定长,且频繁写入,且行数较少,在不建立的索引的情况下速度亦十分之快,建立过多的索引,反而会降低写入和更新的效率。楼主的网站如果在线人数达到1w,你再看是什么效果?
回复于 2007-07-10 23:06:
多谢指正. 抱歉, 我没有注意到 session 表是内存表. 我在 show processlist 观察到这条语句占用 cpu 比较频繁, 加上 index 之后, 效果有改善. 当然, 有更多的例子, 例如 cdb_threads 的 closed 字段, dataline 字段等.

一个事实是: 在添加了这些 INDEX 之后, 目标主机的 CPU 由100% 降到了 10~20%. 另外声明一下, 文中所说的主机不是我的, 我只是帮朋友处理一下.:)

第 6 楼  发表于 2007-07-12 12:46 | mad_frog 的所有评论
discuz的这些所谓的优化,有些是不错的比如dateline的问题,但是你也应该知道如此(上千万级)数量的数据,做不做这样的索引优化,是有实际条件的,数据更新的频繁度导致了他们不敢这么做索引,这是论坛呀,不是文章管理系统。更新的占多数。

第 7 楼  发表于 2007-08-14 18:35 | Rocky_Li 的所有评论
小辉加油!我看好你!

第 8 楼  发表于 2007-09-06 17:37 | rq 的所有评论
小辉,我认为discuz没有这么多所谓的索引问题
优化千万级数据量的数据库最好是在硬件上下功夫,例如加大内存,使用SCSI磁盘阵列,或者直接使用多服务器负载均衡。

另外说说索引:
大多文中提到没有建立的索引其实都在复合索引中,是和查询语句相匹配的
例如:cdb_pms表中有msgfromid索引(msgfromid+folder+dateline),就对应WHERE msgfromid=11212 AND folder='outbox' ORDER BY dateline DESC这个查询,在多条件的查询中,复合索引命中率会比较高,效率要比单独建立msgfromid,folder,dateline三个索引效果好,并且节省资源。

同样cdb_thread的displayorder,closed也不必单独再建立索引,因为在文中提到的查询条件中tid已经是聚集+唯一索引,数据库查询优化器不会因为后面的条件受影响的:)

discuz在索引的设置上我认为是合理的。

索引加速了读取速度,但是也降低了写入和更新的速度,我认为索引要用到频繁读取的地方,例如帖子列表/帖子内容这样的地方。在小辉提到的2kw级别的bbs,在线人数/发帖回帖量都是一个比较大的规模,所以使用索引的平衡点更加重要。

100%资源占用造成的问题我想是因为mod使用不当,例如今日发帖排行、今日新帖、今日热帖一类的功能,这些查询才是罪魁祸首,小辉可以试试去掉所有插件后CPU还是不是这么高。
回复于 2007-09-07 11:34:
多谢批评指正. 复合索引这块我了解.

我后来查看了一下, 造成这个现象, 有两个原因:

1. 用户升级论坛程序之后, 没有升级数据表的结构. 新近的程序, 采用的数据表结构也不一样, 索引也不一样. 用户没有升级这块, 所以造成查询耗时. 这个原因, 是由于我在查看用户实际的数据表结构与 discuz 最新安装程序的 install SQL 时发现的.

2. discuz 本身有部分没有考虑到索引的问题. 这个我在查看最新的 discuz 论坛源码以及 install SQL 源码时, 得到的验证.

但总的来说, 以第一条原因居多. 所以我在文中对 discuz 的指责, 确实有些过于偏激. 在此愿意表示道歉.

索引的滥加确实会造成写入和更新的速度. 但我觉得这篇文章里提到的更改方式, 应该是正确的. 毕竟有一个看得见的 2kw 记录实际解决效果在这里.

第 9 楼  发表于 2007-10-11 08:30 | iamxyh 的所有评论
支持小辉的观点,不管理论怎么好,要看实际效果嘛.

第 10 楼  发表于 2007-11-10 10:23 | shenlag 的所有评论
小辉的这两篇文章都认真的学习了!对MYSQL很不懂!
我这边也是这样的问题,MYSQL占用服务器CPU很大!!POSTS表数据是20万!搞的论坛上到处都有人抱怨速度太慢!很郁闷!

看到下边的几个回复,也不敢擅自改了!我该怎么办?还请小辉能帮下忙!留个QQ好吗?或是直接加我:38514999,希望小辉能在百忙中帮下我的忙!很着急
回复于 2007-11-10 23:52:
你先确认是一下,是不是 MYSQL 导致的 CPU 占 100%. 具体可以进入任务管理器,查看 mysqld-nt.exe 或 mysql.exe 这个进程占用 CPU 的情况. 如果确实是它,你再找我。否则我也不能担保解决问题。

第 11 楼  发表于 2007-11-10 23:25 | 秋秋 的所有评论
现在是晚上11点,看到你的主页,你的一些照片和你的自传经历,感觉很敬佩你……
当然,进入你主页的原因是从dz那边看到有朋友推介你的一篇文章:千万级记录的Discuz论坛导致MySQL CPU 100%的优化笔记
我看了之后,觉得你说的很对,虽然我不知道你在说什么,但我知道你应该能帮助到我……
呃……我的论坛,现在好像很慢,不知道是不是mysql的原因
如果你用空的话,能加我一下么,指导一下,感激不尽……
我的qq:156994
非常感谢,祝你的程序员之路越走越远,你的理想也早日实现!
o(∩_∩)o...
回复于 2007-11-10 23:48:
你先照我的文章看对照看一下。另外,查看一下任务管理器,你的 MYSQLD-NT.EXE 的程序,占用CPU是否极高。如果不是,则不是 MYSQL 的原因了。

第 12 楼  发表于 2007-11-11 00:28 | 陆林 的所有评论
dizcus 的论坛网络上有这么多人用,有问题他们自己开发者难道不会解决?数据都是有缓存的,关索引屁事啊。

第 13 楼  发表于 2007-11-11 00:34 | 时空论坛 的所有评论
刚才逛 dizcus 官网,发现有人在争论小辉的这篇文章,从那边点过来的。呵呵,原来这里也这么热闹。

第12楼的,我的网站也用是的 dizcus 的论坛,数据记录有 1300千万条,月初找到小辉,正好他有空,一个多小时就帮我解决了。事实胜于雄辩,有些东西,需要海量数据是验证的。一般的小数据量也许说明不了问题。

第 14 楼  发表于 2007-11-12 17:18 | cn256 的所有评论
你好,我想问下,除了DZ出现此问题外,我的站主要是SS出现MYSQl占CPU 100%的问题,有没有SS的解决办法?谢谢。
回复于 2007-11-13 13:48:
SS 是什么?

第 15 楼  发表于 2007-11-12 22:02 | cn256 的所有评论
SS就是SupeSite/X-Space,在DZ官方论坛有专栏的。
数据库也是用MYSQL,我的站经常因这样被DOWN,很是郁闷,希望能得到你的帮助,谢谢!
祝你工作顺利,身体健康,全家幸福!
回复于 2007-11-13 13:49:
如果确定是 MYSQL 占用的额度高,你可以进入本站的 个人消息中心( www.xiaohui.com/msg/ )与我联系。我周六可以帮你看看。

第 16 楼  发表于 2008-01-17 20:21 | 秋秋 的所有评论
你好,小辉
我看了你关于w3wp占用百分百的问题
解决办法,是让执行那些语句
我是想问,执行,是在PHPMYADMIN里执行,还是dz论坛后台执行啊,迫切的需要解决,谢谢你
我qq“156994 我的MYSQLD-NT.EXE程序占用百分之3左右 谢谢
回复于 2008-01-17 21:28:
你可以在 MySQL 的命令行 或 phpmyadmin 下执行。

第 17 楼  发表于 2008-01-18 13:36 | 秋秋 的所有评论
谢谢小辉的回答,我没有装phpmyadmin 也不会安装,在mysql的命令行下执行,我也听不懂,不过,我问下简单的,就是,dz后台有数据库升级。可以填写命令,然后提交,请问,这个可以么?
再次感谢小辉~
回复于 2008-01-18 19:35:
我没有用过DZ最新版本中支持后台数据库升级的模块。如果它可以执行 SQL 命令,按理说是可以的。
但我不能给你打包票,需要你自己测试一下。并且,为了数据安全,做之前最好将数据库做备份。

第 18 楼  发表于 2008-01-20 19:01 | 秋秋 的所有评论
谢谢小辉,可是,我不太敢试,你什么时候有空,能帮帮我么,小辉,拜托了,我的qq:626793276

第 19 楼  发表于 2008-02-22 02:08 | bambo 的所有评论
以前就看过你的前一篇文章,也在收藏栏里收藏了,今天在DZ看到链接又来看了.
也有人用DZ出现这样的问题,我都会推荐让他来看你的博客,支持你一下.

第 20 楼  发表于 2008-02-24 02:01 | 027bbs 的所有评论
我新换的服务器也出现启动数据库CPU就占用100%的情况,有时间帮忙看下吗?一定感谢
QQ:200802718

第 21 楼  发表于 2008-03-27 09:56 | xyz 的所有评论
我的现象是w3wp.exe大概每隔20分钟突然占用内存升高到几百m,导致内存耗尽应用程序池自动回收,这时网站无法访问,等几分钟回收后又会正常。

第 22 楼  发表于 2008-03-28 07:32 | billee 的所有评论
我也有同的问题,但我不会改
可否帮忙下?也是Mysql+PHP的
在线才百来个人就占用100%的CPU资源
QQ:3074303 商量一下,呵呵

第 23 楼  发表于 2008-04-03 09:11 | 6677875 的所有评论
非常支持你,我的论坛也有问题是否有时间帮我看一下!付费也可以

第 24 楼  发表于 2008-04-25 13:27 | bizzx 的所有评论
discuz 1500000个用户时,用户列表翻页数度极其慢,有办法解决吗?支持楼主一下
回复于 2008-04-25 16:06:
我没有研究过这个问题。如果你有慢查询的日志记录,问题肯定是可以能分析出来并解决的。
如果无法解决,那就应该属于人品问题了。

第 25 楼  发表于 2008-05-02 02:54 | 建站铺 的所有评论
学习之中

第 26 楼  发表于 2008-05-10 09:34 | 精致生活 的所有评论
DZ5.5的站,运行一年,近几天发现posts表的record竟有38891条,而网站贴子38800条左右,请问一下小辉这属正常吗?谢谢!
回复于 2008-05-10 09:37:
这种情况, 有点数据冗余,是正常的。造成情况,一般因为删除主题时,论坛程序只删除了 主题数据(thread),而忘了删除 posts 中的数据。不会影响论坛的正常运行。

第 27 楼  发表于 2008-05-31 22:51 | Ray 的所有评论
你好,最近我也遇到相关问题,请问DZ6.0还需要你谈及的

Quote:

ALTER TABLE `cdb_pms` ADD INDEX ( `folder` );
ALTER TABLE `cdb_threads` ADD INDEX ( `displayorder` );
ALTER TABLE `cdb_threads` ADD INDEX ( `dateline` );
ALTER TABLE `cdb_threads` ADD INDEX ( `closed` );
ALTER TABLE `cdb_threadsmod` ADD INDEX ( `dateline` );
ALTER TABLE `cdb_sessions` ADD INDEX ( `invisible` );
ALTER TABLE `cdb_forums` ADD INDEX ( `type` );
ALTER TABLE `cdb_forums` ADD INDEX ( `displayorder` );


第 28 楼  发表于 2008-06-10 12:40 | cocockle 的所有评论
你好,我现在也出现此类问题@
动不动就出现s u情况!
我现在的是6.1
请问
Quote:


ALTER TABLE `cdb_pms` ADD INDEX ( `folder` );
ALTER TABLE `cdb_threads` ADD INDEX ( `displayorder` );
ALTER TABLE `cdb_threads` ADD INDEX ( `dateline` );
ALTER TABLE `cdb_threads` ADD INDEX ( `closed` );
ALTER TABLE `cdb_threadsmod` ADD INDEX ( `dateline` );
ALTER TABLE `cdb_sessions` ADD INDEX ( `invisible` );
ALTER TABLE `cdb_forums` ADD INDEX ( `type` );
ALTER TABLE `cdb_forums` ADD INDEX ( `displayorder` );

能通用吗!
或者帮我处理一下,我的QQ:59805299
回复于 2008-06-10 13:16:
不能保证通用。具体问题,要具体分析。这段代码,是以 Dizcus! 5.5.0 的版本进行的校正。其他的版本,不敢保证。

这篇文章的重点,并不是作为结果的这段代码的,而是如何得出这个结果的分析过程。知道了原理,你自己一样可以分析。

第 29 楼  发表于 2008-07-15 09:43 | sudu8 的所有评论
一台服务器上有数个MYSQL数据库 现在MYSQL有时候会占很高CPU 请问如何能查出是哪个数据库占的CPU?感谢指教
回复于 2008-07-15 11:06:
在 MYSQL SHELL 下执行 show processlist;
或 在 my.ini 中, 配置 log-slow-queries= xxxxx.log 然后再分析.

第 30 楼  发表于 2008-07-24 01:05 | ff 的所有评论
第一次见到这么做索引的...建议作者再去学习一下Mysql如何调用索引.

一个SQL查询MySQL只会从一个索引查询,最基本的道理都不懂么?

这么搞索引,会让IO负载无限增大的

第 31 楼  发表于 2008-09-02 09:46 | 支持 的所有评论
支持你!

第 32 楼  发表于 2008-10-06 18:59 | henry 的所有评论
请教楼主,我安装discuz6.1时-服务器环境(apache2.0+php5.26+Zend Optimizer+mysql5.0),数据库在本机,论坛安装后速度挺快0.0几秒可显示页面,不过数据库远程时,论坛的访问速度慢很多,要4秒以上.
请问楼主有没有分布式部署的一些教程和解决方案,多谢了.
回复于 2008-10-06 20:44:
最好布署在同一机房比较好,速度应该没这么慢。抱歉的是,我分布式部署对这块没有详细了解。你可以了解一下这些知识点看看 MySQL 的主从复制 MySQL-Proxy 以及 MySQL 5.1 分区

第 33 楼  发表于 2008-10-07 10:28 | henry 的所有评论
谢谢楼主的回答,支持你!

第 34 楼  发表于 2008-11-11 16:35 | 风云在起 的所有评论
楼主,您好, 请教问题,Discuz 对 mysql 数据库释放的代码 是怎样处理的呢?我看了DZ代码 找了好久,都没看到哪里用到 close 函数来关闭数据库连接 望指教
回复于 2008-11-11 20:30:
这个我没注意过. 手上没DZ的源码. 你自己再细看看.

第 35 楼  发表于 2008-12-15 08:34 | 海量数据处理 的所有评论
辉兄。。。 能不写个上面Mysql语句的反向安装

我不小心按错数据库了。。
回复于 2008-12-15 11:09:
没太听懂你的意思。装错数据库了,可以再移出来就是了啊。

第 36 楼  发表于 2008-12-16 10:16 | 海量数据处理 的所有评论
不是啊,辉兄,我对Mysql的理解还处于婴儿时期,看了你的文章,就运行了
ALTER TABLE `cdb_pms` ADD INDEX ( `folder` );
...
...
...
可是我运行的数据库不是安装discuz论坛的那个数据库,,, 但我又不会手动删除操作Mysql, 所以裸体跪求反安装,是不是把ADD改成delete就行了?
ALTER TABLE `cdb_pms` delete INDEX ( `folder` );
回复于 2008-12-23 17:07:
还是没懂你的意思。不敢给你意见。:) 
你若是要删除 INDEX, 用 DROP,不是 DELETE

第 37 楼  发表于 2008-12-23 15:46 | 笑容 的所有评论
建议把加减法改到10以内,大了不会算。
另外表扬下你的耐心,这么耐心去哄他们,真厉害哈。

评论来自 www.mikaa.cn 一个千万级的黄页网站,正在捣鼓优化问题呢。呵呵
回复于 2008-12-23 17:02:
呵呵,这个加法应该很好算的, 我设计的是 (1 ~ 9 ) + ( 10 ~ 19) = ?
这个范围,应该不需要借助计算器,我女儿都会算了。:)

第 38 楼  发表于 2008-12-27 16:39 | test 的所有评论
授人以鱼,不如授人以渔。

能看多些实际操作文章更好。

目前只是通过增加INDEX来加快查询速度,不知道还有没有更多其它的方法。
例如,使用WHERE语句时要注意什么。
LIKE如何写才规范。
LEFT JOIN 语句 多表联动查询,要注意什么。
内存表的深入应用。。。。。等等。。。。

第 39 楼  发表于 2009-02-07 16:00 | tatacom 的所有评论
80W主题的论坛, 用户访问翻页占CPU很厉害, 请问有没有什么好的解决办法?

慢查询日志里很多这样的

# Query_time: 6 Lock_time: 0 Rows_sent: 38 Rows_examined: 33892
SELECT t.* FROM cdb_threads t
WHERE t.fid='58' AND t.displayorder IN (0, 1)
ORDER BY t.displayorder DESC, t.dateline DESC
LIMIT 101, 38;

# Query_time: 6 Lock_time: 0 Rows_sent: 38 Rows_examined: 51837
SELECT t.* FROM cdb_threads t
WHERE t.fid='25' AND t.displayorder IN (0, 1)
ORDER BY t.displayorder DESC, t.dateline DESC
LIMIT 25637, 38;

第 40 楼  发表于 2009-02-13 16:37 | 王子 的所有评论
不错的东西哦,谢谢分享

第 41 楼  发表于 2009-04-09 22:34 | 灵格王子 的所有评论
我的 discuz 论坛也是遇到了 CPU 100% 的问题,在 discuz 的官网里发贴反映了两个多月,给康盛也打了电话无数,一直没有解决。我搜遍了整个网络,本来不抱希望地找到了小辉。没想到他很快就帮我找到了问题症结并解决,我要给他辛苦费也不收。
在此特别表示感谢!

第 42 楼  发表于 2009-05-18 23:52 | Yancy 的所有评论
show processlist看不全的时候可以用show full processlist

第 43 楼  发表于 2010-01-24 23:06 | snowfeng 的所有评论
晕,怎么是乱码?上文

第 44 楼  发表于 2010-01-24 23:09 | snowfeng 的所有评论
小辉,灵格王子,我也遇到你的问题了,我的dz数据库超过1G,在线人数3000以上。最近服务器的cpu一直保持在百分九十以上,dz论坛访问就非常困难了,也影响了我的uchome,当我把dz论坛关闭的时候,uchome却一直正常,cpu的使用率也下来了,说明dz论坛的表可能有些问题。请问,该如何解决?能帮帮我吗?最近一直很彷徨,哎。

第 45 楼  发表于 2010-01-24 23:11 | snowfeng 的所有评论
灵格王子,请联系我,我遇到与你一样的问题。我的QQ:1394376123,希望小辉保留一下,如果小辉有时间帮我诊断一下,那就太好了。在此感谢!

第 46 楼  发表于 2012-06-02 10:59 | doveying 的所有评论
辉哥你好,不知道你还有没有在管理这个blog,我用的是discuz X2.5的用你的数据库语句,是没有该表,而且关闭phpmyadmin后,w3wp的占用没有下降,我怀疑问题是出在discuz上,因为安装过不少插件,现在把插件全部关闭了,但w3wp的占用,依旧没有下降,重启了iis之后,它的占用很低,内存也低,一旦久了,或者上线人数多了,就会飙高,,mysqld的占用始终都在5%一下,所以我很迷惘。如果你有空,请联系下我好么?qq:2579341843
谢谢
回复于 2012-06-02 16:40:
你好。我久没有接触DZ了。X2.5的数据结构更不熟悉。不过,mysql 占用 5%,这压力并不严重啊。以前严重的都是100%高居不下。你若有心查找,可以按我笔记中的要点,先记录慢查询,看看是哪里的问题。

第 47 楼  发表于 2023-07-25 19:22 | RJ 的所有评论
很不错的文章,老哥现在还做程序员吗
回复于 2023-08-11 00:00:
是的,还在写代码:)

共有评论 47 条, 显示 47 条。

当前页面是本站的 百度 MIP 版本。
欲查看完整版本和发表评论请点击:完整版 »

 

程序员小辉 建站于 1997
Copyright © XiaoHui.com; 保留所有权利。