当前位置：首页 > 资讯 > 技术文档

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

时间：2022-05-10 20:06 编辑：来源：阅读：
扫一扫，手机访问

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

发现此主机运行了几个 Discuz 的论坛程序， Discuz论坛的好几个表也存在着这个问题。于是顺手一并解决，cpu占用再次降下来了。　　前几天，一位朋友通过这篇文章找到了我，说他就是运行最新的 discuz 版本，MySQL 占用 CPU 100%，导致系统假死，每天都要重启好几次，花了一个多月的时间一直没有解决，希望我帮忙一下。经过检查，他的这个论坛最重要的几个表中，目前 cdb_members 表，有记录 6.2 万；cdb_threads 表，有记录 11万；cdb_posts表，有记录 1740 万；所有数据表的记录加起来，超过 2000 万；数据库的大小超过 1GB。经过半天的调试，总算完成了 discuz 论坛优化，于是将其解决经过记录在这篇文章中。　　2007年3月我发现 discuz 论坛的数据库结构设计有一些疏忽，有许多查询子句的条件比较，都没有建立 Index 索引。当时我所检查的那个数据表，记录只有几千条，因此对 CPU 负荷不大。现在这个数据库表，上千万的记录检索，可以想象，如果数据表结构设计不规范，没有提供索引，所耗费的时间是一个恐怖的数字。有关 MySQL 建立索引的重要性，可以参见我的这篇文章底部的说明　　为了调试方便，我从 dizcus 的官网下载了其最新的 Dizcus! 5.5.0 论坛程序．　　我首先检查了 my.ini 的参数配置，一切正常。进入 MySQL 的命令行，调用 show processlist 语句，查找负荷最重的 SQL 语句，结合 Discuz 论坛的源码，发现有以下语句导致 CPU 上升：

[url=http://www.discuz.net/thread-673887-1-1.html]http://www.discuz.net/thread-673887-1-1.html[/url]。discuz 的管理员和管理员有如下言论： [quote] [b]引用自 cnteacher[/b]: 恰恰相反，discuz 的优化措施和数据库的索引是按照大规模论坛设计的。 TO 一楼：数据库结构的设计都是按照程序应用来进行的，使用任何非Discuz! 标准版本以外的代码和程序，或者变更标准数据结构，均可能遇到不可预知的各种问题。 [b]引用自童虎[/b]: 你们可以看看xxxxx, xxxx之类的比较大型的网站，这种网站使用dz论坛都没有问题，说明dz标准程序是没有问题，出现楼主说的情况，多半属于服务器或者安装一些插件造成的 [/quote]　　显然将问题推给插件的原因是不正确的．举个简单的例子：在最新的 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 自己的程序中的。 [h1]附2: 补充笔记 2007-11-11[/h1]　　自从这篇笔记发表以来，在我的这篇文章的评论、以及我的联系消息中，就经常收到许多下面两种类型的评论和邮件：一、许多技术人员批评我胡说八道、Dizcus 论坛不需要做优化或者不能乱建索引的；二、许多使用Dizcus 的站长找我“冰天雪地裸体跪求”解决他们的 CPU 占用 100% 的问题。　　一、关于 [b]MySQL 数据库优化技术[/b]上的争论，我的观点再次声明如下： [list=1] [*]技术上的争论是可以放开了讨论的。而我的水平也确实只是半瓶水，对数据库的理论知识也只懂这么点，牛牛们的批评，我虚心接心，非常感谢。但是，评论里的批评不要上升到人身攻击，否则，我的地盘我作主，直接删除。 [/*][*]数据库的优化，要涉及到的方方面面很多。关说理论是没有用的，得靠事实说话。一个千万级数据库的实例优化说明不了问题，两个千万级的数据库优化也许还说明不了问题，但我相信，三个、四个、五个总是可以说明问题的，－－截止到 2007.11.09，我已经帮助朋友优化过五个记录数超过 1000 万的 discuz 论坛了。我想事实胜于雄辩：优化之前，cpu 都是 100%；优化之后，cpu 降到 30%~40% 左右。没错，做 ADD INDEX　会增加数据库 INSERT/UPDATE 时的开销，但别忘了论坛最主要的操作，是 SELECT 查询。 [/*][/list] [url=http://www.xiaohui.com/support/]http://www.xiaohui.com/support/[/url] 与我联系。不要在评论里留个 QQ 号然后要我加你，我不会时时盯着评论看。 [/list] [h1]附3: 补充笔记 2007-11-17: 关于装有首页四格插件的 dz 论坛导致 MySQL 占用大量CPU 的分析[/h1]　　今天手机巴士的站长( 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 中: 仔细检查这行代码，发现存在许多性能或语法规范上的问题： [list=1] [*][b]AND t.closed NOT LIKE 'S'[/b]:t.closed 是数值字段，不应该用 LIKE 'S' 的形式参与比较。　 [/*][*][b]ORDER BY t.views:[/b] t.views 在 dizcus 的原始数据表中，是没有做索引的。 [/*][*][b]SELECT t.*[/b]: 这种写法，是不被推荐的。如果要选择某个表内的所有字段，最好是按实全部写出来，例如：select t.aa, t.bb, t.cc, t.dd, ... [/*][*][b]WHERE　t.fid <> 'S'[/b]: t.fid 是数值型字段，不应该写成字符比较的形式。这个对性能影响不大，是个编程规范的问题。 [/*][*].... [/*][/list] 　　toplist.php 的其他三条 sql 语句，都存在这些问题。如果要针对他的 sql 语句去优化 MySQL 结构，会带来不良的后果；如果直接改他的 toplist.php 程序，如果站长以后升级　toplist.php 又怕带来不兼容问题。于是我建议他干脆关闭首页四格插件。　　关闭首页四格插件之后，CPU 降到 18% 左右震荡，表现非常良好。　　如果是我来写首页四格的程序，我不会采用这种方案，我会用定时15分钟或30分钟查询一次数据库，将结果写入 TXT 文件或临时表，然后程序再从中读取，效率会高许多。　　结论： [list=1] [*]如果装了插件的论坛碰到　CPU 高负荷时，建议关掉插件再评估性能。 [/*][*]慎装第三方插件。没事不要乱插。:) [/*][/list] [h1]附4：补充笔记 2008-06-10：这篇文章，重要的是分析过程，而不是进行修正的那段代码[/h1]　　最近有几位在评论中留言，以及给我 EMAIL，说到将我在文中给出的那8行 ALTER TABLE 代码，在他的出现 CPU 100% 的 dz 论坛上，用了之后没有效果。　　我的解释如下：这段代码，不能保证在 dz 的所有版本下通用。具体问题，要具体分析。这段代码，是我在 Dizcus! 5.5.0 的版本的基本下进行分析得出的校正结果。其他的版本，不敢保证。　　这篇文章的重点，并不是作为结果的这段代码，[b]而是如何得出这个结果的分析过程。知道了原理，你自己一样可以分析。[/b]

全部评论(0)

上一篇：MySQL存储过程相互调用并获得错误码示例
下一篇：如何测试字符串的长度？

资讯排行榜
更多>>

联系客服

客服电话：
400-000-3129

微信版

扫一扫进微信版

返回顶部