»
首页
>
服务器维护与开发笔记
千万级记录的
Discuz
论坛导致
MySQLCPU100%
的优化笔记
日期
:2007070200:04|
联系我
|FollowmeonTwitter:@iXiaoHui
注:本文最后更新于:
20071117
2007
年
3
月,我写过一篇文章《解决一个
MySQL
服务器进程
CPU
占用
100%
的技术笔记》
(http://www.xiaohui.com/weekly/20070307.htm)
,谈到自己在解决一个拥有
60
万条记录的
MySQL
数据库访问时,导致
MySQLCPU
占
用
100%
的经过。在解决问题完成优化
(optimize)
之后,我发现
Discuz
论坛也存在这个问题,当时稍微提了一下:
发现此主机运行了几个
Discuz
的论坛程序,
Discuz
论坛的好几个表也存在着这个问题。于是顺手一并解决,
cpu
占用再次降
下来了。
前几天,一位朋友通过这篇文章找到了我,说他就是运行最新的
discuz
版本,
MySQL
占用
CPU100%
,导致系统假死,每天都要重启好
几次,花了一个多月的时间一直没有解决,希望我帮忙一下。经过检查,他的这个论坛最重要的几个表中,目前
cdb_members
表,有记录
6.2
万;
cdb_threads
表,有记录
11
万;
cdb_posts
表,有记录
1740
万;所有数据表的记录加起来,超过
2000
万;数据库的大小超过
1GB
。
经过半天的调试,总算完成了
discuz
论坛优化,于是将其解决经过记录在这篇文章
http://www.xiaohui.com/dev/server/20070701
discuzmysqlcpu100optimize.htm
中。
2007
年
3
月我发现
discuz
论坛的数据库结构设计有一些疏忽,有许多查询子句的条件比较,都没有建立
Index
索引。当时我所检查的那
个数据表,记录只有几千条,因此对
CPU
负荷不大。现在这个数据库表,上千万的记录检索,可以想象,如果数据表结构设计不规范,没有提
供索引,所耗费的时间是一个恐怖的数字。有关
MySQL
建立索引的重要性,可以参见我的这篇文章底部的说明:
http://www.xiaohui.com/weekly/20070307.htm
为了调试方便,我从
dizcus
的官网下载了其最新的
Dizcus!5.5.0
论坛程序.
我首先检查了
my.ini
的参数配置,一切正常。进入
MySQL
的命令行,调用
showprocesslist
语句,查找负荷最重的
SQL
语句,结合
Discuz
论坛的源码,发现有以下语句导致
CPU
上升:
mysql>showprocesslist;
++++++++
+
|Id|User|Host|db|Command|Time|State|Info
|
++++++++
+
|363|root|localhost:1393|history|Query|0|statistics|SELECTC
OUNT(*)FROMcdb_pmsWHEREmsgfromid=11212ANDfolder='outbox'|
++++++++
检查
cdb_pms
表的结构:
mysql>showcolumnsfromcdb_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||
+++++++
10rowsinset(0.00sec)
这条语句
:WHEREmsgfromid=11212ANDfolder='outbox'
,我们看到,在
cdb_pms
表中,
msgfromid
字段已经建立了索引,但是,
folder
字段并没有。目前这个表已经有记录
7823
条。显然,这会对查询造成一定影响。于是为其建立索引:
mysql>ALTERTABLE`cdb_pms`ADDINDEX(`folder`);
QueryOK,7823rowsaffected(1.05sec)
Records:7823Duplicates:0Warnings:0
继续检查:
mysql>showprocesslist;
++++++++
+
|Id|User|Host|db|Command|Time|State|Info
|
++++++++
+
|
|1583|root|localhost:2616|history|Query|0|statistics|SELECT
t.tid,t.closed,f.*,ff.*,f.fidASfid
FROMcdb_threadst
INNERJOINcdb_forumsf|
++++++++
+
1rowsinset(0.00sec)
这条
SQL
语句是针对最重要的数据表
cdb_threads
进行操作的,由于
showprocesslist
没有将这条
SQL
语句全部显示完全,经对比
Discuz
论坛的源码,此
SQL
语句的原型位于
common.inc.php
的
Line283
,内容如下:
$query=$db>query("SELECTt.tid,t.closed,".(defined('SQL_ADD_THREAD')?
SQL_ADD_THREAD:'')."f.*,ff.*$accessadd1$modadd1,f.fidASfid
FROM{$tablepre}threadst
INNERJOIN{$tablepre}forumsfONf.fid=t.fid
LEFTJOIN{$tablepre}forumfieldsffONff.fid=f.fid$accessadd2$modadd2
WHEREt.tid='$tid'".($auditstatuson?'':"ANDt.displayorder>=0")."LIMIT1");
经检查,数据表
cdb_threads,
并没有针对
displayorder
字段建立索引。在
discuz
论坛中,
displayorder
字段多次参与了
Where
子句的比
较。于是为其建立索引:
mysql>ALTERTABLE`cdb_threads`ADDINDEX(`displayorder`);
QueryOK,110330rowsaffected(2.36sec)
Records:110330Duplicates:0Warnings:0
此时
cpu
已经轻微下降了一部分。
继续检查,发现 下面这条
discuz
的
SQL
语句,也导致负荷增加,这条语句位于
rss.php
程序中的第
142
行。
$query=$db>query("SELECTt.tid,t.readperm,t.price,t.author,t.dateline,t.subject,p.message
FROM{$tablepre}threadst
LEFTJOIN{$tablepre}postspONp.tid=t.tidANDp.first=1
WHEREt.fid='$fid'ANDt.displayorder>=0
ORDERBYt.datelineDESCLIMIT$num");
在这个
Orderby
子句中,用到了
cdb_threads
表中的
dataline
字段。这个字段是用来存储
unixtime
的时间戳,在整个论坛程序中,大部
分时候数据的排序也是基于这个字段,竟然没有建立索引。于是加上:
mysql>ALTERTABLE`cdb_threads`ADDINDEX(`dateline`);
QueryOK,110330rowsaffected(12.27sec)
Records:110330Duplicates:0Warnings:0
查找占用
CPU
高负茶的
SQL
语句,是一件麻烦而又枯燥的事,需要一条一条排除、分析。后面的工作,都是依此类推,经过检查,共查出
有八处地方,需要增加索引,如果你也碰到了
discuz5.5.0
论坛导致
cpu
占用
100%
的情况,可以直接将下列语句复制过去,在
mysql
的命
令行下执行即可:
ALTERTABLE`cdb_pms`ADDINDEX(`folder`);
ALTERTABLE`cdb_threads`ADDINDEX(`displayorder`);
ALTERTABLE`cdb_threads`ADDINDEX(`dateline`);
ALTERTABLE`cdb_threads`ADDINDEX(`closed`);
ALTERTABLE`cdb_threadsmod`ADDINDEX(`dateline`);
ALTERTABLE`cdb_sessions`ADDINDEX(`invisible`);
ALTERTABLE`cdb_forums`ADDINDEX(`type`);
ALTERTABLE`cdb_forums`ADDINDEX(`displayorder`);
注意:“
cdb_”
是
discuz
论坛的默认数据表前缀。如果你的表名前缀不是 “
cdb_”
,则应该改成你对应的表名。例如:
my_threads,my_pms
等等。
完成这些结构的优化之后,整个系统的
CPU
负荷在
10%~20%
左右震荡,问题解决。
我很奇怪,设计数据库结构,是一个数据库开发人员的基本功,
discuz
论坛好歹也是一个发展了有六七年的论坛了,为何数据库结构设计
得如此糟糕?我想也许有如下三个原因:
l
数据库开发人员设计时本身的疏忽
l
故意留下的缺陷,当普通论坛没有上数量级的记录时,不会感觉到这个问题,当数据量增大(例如千万级),此问题突现,以便针对用户
提供个性服务收取服务费.呵呵,估且以最大的恶意来猜测此事,玩笑而已,不必当真。
:)
l
另一个可能就是用户的论坛是从低版本升级而来,程序升了级,但数据结构也许没有做相应的更新
附
1:
补充笔记
20070709
今天查看网站日志的
reffer,
发现在
discuz
的官方论坛上,有人就此文引起了一些争论
:http://www.discuz.net/thread67388711.html
。
discuz
的管理员和管理员有如下言论:
引用自
cnteacher:
恰恰相反,
discuz
的优化措施和数据库的索引是按照大规模论坛设计的。
TO
一楼:数据库结构的设计都是按照程序应用来进行的,使用任何非
Discuz!
标准版本以外的代码和程序,或者变更标准数
据结构,均可能遇到不可预知的各种问题。
引用自 童虎
:
你们可以看看
xxxxx,xxxx
之类的比较大型的网站,这种网站使用
dz
论坛都没有问题,说明
dz
标准程序是没有问题,出现楼主
说的情况,多半属于服务器或者安装一些插件造成的
显然将问题推给插件的原因是不正确的.举个简单的例子:在最新的
discuz5.5.0forumdisplay.php
第
183
行,有如下语句:
$query=$db>query("SELECTuid,groupid,username,invisible,
lastactivity,actionFROM{$tablepre}sessions
WHERE$guestwherefid='$fid'ANDinvisible=0");
这里的
invisible
并没有建立索引。本文中有评论认为
session
表是内存表
,
速度会很快。理论是如此。不过我在
showprocesslist
中,观
察到上面这条语句占用了大量
CPU
, 所以也将其一并加上了
index
。
cdb_threads
中的
closed
等字段
,
也多次参与
where
运算
,
也没有建立
索引。这些运算的语句
,
是
discuz
自己的程序中的。
附
2:
补充笔记
20071111
自从这篇笔记发表以来,在我的这篇文章的评论、以及我的联系消息中,就经常收到许多下面两种类型的评论和邮件:一、许多技术人员批
评我胡说八道、
Dizcus
论坛不需要做优化或者不能乱建索引的;二、许多使用
Dizcus
的站长找我“冰天雪地裸体跪求”解决他们的
CPU
占用
100%
的问题。
一、关于
MySQL
数据库优化技术上的争论,我的观点再次声明如下:
1.
技术上的争论是可以放开了讨论的。而我的水平也确实只是半瓶水,对数据库的理论知识也只懂这么点,牛牛们的批评,我虚心接心,
非常感谢。但是,评论里的批评不要上升到人身攻击,否则,我的地盘我作主,直接删除。
2.
数据库的优化,要涉及到的方方面面很多。关说理论是没有用的,得靠事实说话。一个千万级数据库的实例优化说明不了问题,两个千
万级的数据库优化也许还说明不了问题,但我相信,三个、四个、五个总是可以说明问题的,--截止到
2007.11.09
,我已经帮助朋友
优化过五个记录数超过
1000
万的
discuz
论坛了。我想事实胜于雄辩:优化之前,
cpu
都是
100%
;优化之后,
cpu
降到
30%~40%
左
右。没错,做
ADDINDEX
会增加数据库
INSERT/UPDATE
时的开销,但别忘了论坛最主要的操作,是
SELECT
查询。
二、关于找我帮忙解决数据库优化的评论和邮件,答复如下
:
1.
数据库的优化,不同的版本有不同的实际情况,优化一个
database
,短则三两小时,慢则半天一天。请大家理解这个中年老男人养家
的压力,我的精力有限,不可能一一帮到。
2.
对于没有收入的个人网站,我可以在周六周日的空余时间内帮忙。请事先与我联系好。
3.
对于有收入的网站,嗯嗯,自觉点,请带价格与我联系,或者直接安排美女请我吃饭,否则免谈。
:)
请不要来信问“优化我们这个论坛
你要多少费用?”这样没营养的话,而是直接说“帮我们优化
XXXX
论坛,
XXXXRMB
可以不?”,我觉得合适就做。大家都很
忙,我的时间很值钱,你要我自己报价,我怕吓着你。
4.
请通过
http://www.xiaohui.com/support/
与我联系。不要在评论里留个
QQ
号然后要我加你,我不会时时盯着评论看。
附
3:
补充笔记
20071117:
关于装有首页四格插件的
dz
论坛导致
MySQL
占用 大量
CPU
的分析
今天手机巴士的站长
(http://bbs.sj84.com)
找到我,他的基于
Discuz
的论坛,也存在
CPU
占用
100%
的问题,服务器从
Win2003
换到
CentOS
,内存
2G,CPU1.86G,
数据:
cdb_threads4
万,
cdb_posts96
万,
cdb_members35
万,已经按我上面文章所说的优化过索引。
按说这个配置足够运行论坛了,但问题一直得不到解决。
经过调试,将慢查询的结果
dump
到
/usr/local/mysql/var/localhostslow.log
,运
行
/usr/local/mysql/bin/mysqldumpslow/usr/local/mysql/var/localhostslow.log
查看,结合
showprocesslist
命令,发现慢查询集中在
下列语句
:
SELECTt.*,f.nameFROMcdb_threadst,cdb_forumsfWHERE
t.fid<>'S'
ANDf.fid=t.fid
ANDf.fidNOTIN(N,N,N,N)
ANDt.closedNOTLIKE'S'
ANDt.replies!=N
ANDt.displayorder>=N
ORDERBYt.viewsDESCLIMITN,N
然而搜索
Dizcus
论坛的源码,并没有找到这行代码。怀疑是插件的原因。经查,论坛装了首页四格的插件,这行语句位于
include/toplist.php
中
:
仔细检查这行代码,发现存在许多性能或语法规范上的问题:
1. ANDt.closedNOTLIKE'S':t.closed
是数值字段,不应该用
LIKE'S'
的形式参与比较。
2. ORDERBYt.views:t.views
在
dizcus
的原始数据表中,是没有做索引的。
3. SELECTt.*:
这种写法,是不被推荐的。如果要选择某个表内的所有字段,最好是按实全部写出来,例如:
selectt.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
:补充笔记
20080610
:这篇文章,重要的是分析过程,而不是进行修正的那段代码
最近有几位在评论中留言,以及给我
EMAIL
,说到将我在文中给出的 那
8
行
ALTERTABLE
代码,在他的出现
CPU100%
的
dz
论坛上,
用了之后没有效果。
我的解释如下:这段代码,不能保证在
dz
的所有版本下通用。具体问题,要具体分析。这段代码,是我在
Dizcus!5.5.0
的版本的基本下进
行分析得出的校正结果。其他的版本,不敢保证。
这篇文章的重点,并不是作为结果的这段代码,而是如何得出这个结果的分析过程。知道了原理,你自己一样可以分析。
附
5:
相关文章:
解决一个
MySQL
服务器进程
CPU
占用
100%
的技术笔记
第
1
楼
hcy1122
发表于
2007070113:24|hcy1122
的所有评论
支持你,小辉!
我们要继续努力
你现在在哪呢?好久没有你写关于自己的随笔了
XiaoHui
回复于
2007070202:06:
在长沙.:)
第
2
楼
游客 发表于
2007070210:02|
游客的所有评论
索引不是越多越好,建立了索引之后,插入更新速度就是非常慢,只是
select
能比较快,这两者之间要有一个均衡点
第
3
楼
pzhai
发表于
2007070210:33|pzhai
的所有评论
估计
discuz!
越来越看重中小论坛的市场了吧 ,再说本来
mysql
对海量数据就不太友好,发展瓶颈吧
第
4
楼
vagabond
发表于
2007070912:07|vagabond
的所有评论
写不得不错啊,大哥现在从事什么工作
程序员出来都了什么工作
第
5
楼
继续革命 发表于
2007071010:05|
继续革命的所有评论
$query=$db>query("SELECTuid,groupid,username,invisible,
lastactivity,actionFROM{$tablepre}sessions
WHERE$guestwherefid='$fid'ANDinvisible=0");
session
表为内存表,且定长,且频繁写入,且行数较少,在不建立的索引的情况下速度亦十分之快,建立过多的索引,反而会降低写入和更新
的效率。楼主的网站如果在线人数达到
1w
,你再看是什么效果?
XiaoHui
回复于
2007071023:06:
多谢指正
.
抱歉
,
我没有注意到
session
表是内存表
.
我在
showprocesslist
观察到这条语句占用
cpu
比较频繁
,
加上
index
之后
,
效果有改
善
.
当然
,
有更多的例子
,
例如
cdb_threads
的
closed
字段
,dataline
字段等
.
一个事实是
:
在添加了这些
INDEX
之后
,
目标主机的
CPU
由
100%
降到了
10~20%.
另外声明一下
,
文中所说的主机不是我的
,
我只是帮朋友
处理一下
.:)
第
6
楼
mad_frog
发表于
2007071212:46|mad_frog
的所有评论
discuz
的这些所谓的优化,有些是不错的比如
dateline
的问题,但是你也应该知道如此(上千万级)数量的数据,做不做这样的索引优化,是有
实际条件的,数据更新的频繁度导致了他们不敢这么做索引,这是论坛呀,不是文章管理系统。更新的占多数。
第
7
楼
Rocky_Li
发表于
2007081418:35|Rocky_Li
的所有评论
小辉加油!我看好你!
第
8
楼
rq
发表于
2007090617:37|rq
的所有评论
小辉,我认为
discuz
没有这么多所谓的索引问题
优化千万级数据量的数据库最好是在硬件上下功夫,例如加大内存,使用
SCSI
磁盘阵列,或者直接使用多服务器负载均衡。
另外说说索引:
大多文中提到没有建立的索引其实都在复合索引中,是和查询语句相匹配的
例如:
cdb_pms
表中有
msgfromid
索引(
msgfromid+folder+dateline
),就对应
WHEREmsgfromid=11212ANDfolder='outbox'ORDERBY
datelineDESC
这个查询,在多条件的查询中,复合索引命中率会比较高,效率要比单独建立
msgfromid,folder,dateline
三个索引效果好,并
且节省资源。
同样
cdb_thread
的
displayorder,closed
也不必单独再建立索引,因为在文中提到的查询条件中
tid
已经是聚集
+
唯一索引,数据库查询优化器
不会因为后面的条件受影响的:)
discuz
在索引的设置上我认为是合理的。
索引加速了读取速度,但是也降低了写入和更新的速度,我认为索引要用到频繁读取的地方,例如帖子列表
/
帖子内容这样的地方。在小辉提到
的
2kw
级别的
bbs
,在线人数
/
发帖回帖量都是一个比较大的规模,所以使用索引的平衡点更加重要。
100%
资源占用造成的问题我想是因为
mod
使用不当,例如今日发帖排行、今日新帖、今日热帖一类的功能,这些查询才是罪魁祸首,小辉可以
试试去掉所有插件后
CPU
还是不是这么高。
XiaoHui
回复于
2007090711:34:
多谢批评指正
.
复合索引这块我了解
.
我后来查看了一下
,
造成这个现象
,
有两个原因
:
1.
用户升级论坛程序之后
,
没有升级数据表的结构
.
新近的程序
,
采用的数据表结构也不一样
,
索引也不一样
.
用户没有升级这块
,
所以造成查询
耗时
.
这个原因
,
是由于我在查看用户实际的数据表结构与
discuz
最新安装程序的
installSQL
时发现的
.
2.discuz
本身有部分没有考虑到索引的问题
.
这个我在查看最新的
discuz
论坛源码以及
installSQL
源码时
,
得到的验证
.
但总的来说
,
以第一条原因居多
.
所以我在文中对
discuz
的指责
,
确实有些过于偏激
.
在此愿意表示道歉
.
索引的滥加确实会造成写入和更新的速度
.
但我觉得这篇文章里提到的更改方式
,
应该是正确的
.
毕竟有一个看得见的
2kw
记录实际解决效果
在这里
.
第
9
楼
iamxyh
发表于
2007101108:30|iamxyh
的所有评论
支持小辉的观点
,
不管理论怎么好
,
要看实际效果嘛
.
第
10
楼
shenlag
发表于
2007111010:23|shenlag
的所有评论
小辉的这两篇文章都认真的学习了!对
MYSQL
很不懂!
我这边也是这样的问题,
MYSQL
占用服务器
CPU
很大!!
POSTS
表数据是
20
万!搞的论坛上到处都有人抱怨速度太慢!很郁闷!
看到下边的几个回复,也不敢擅自改了!我该怎么办?还请小辉能帮下忙!留个
QQ
好吗?或是直接加我:
38514999
,希望小辉能在百忙中帮
下我的忙!很着急
XiaoHui
回复于
2007111023:52:
你先确认是一下,是不是
MYSQL
导致的
CPU
占
100%.
具体可以进入任务管理器,查看
mysqldnt.exe
或
mysql.exe
这个进程占用
CPU
的情况
.
如果确实是它,你再找我。否则我也不能担保解决问题。
第
11
楼
秋秋 发表于
2007111023:25|
秋秋的所有评论
现在是晚上
11
点,看到你的主页,你的一些照片和你的自传经历,感觉很敬佩你……
当然,进入你主页的原因是从
dz
那边看到有朋友推介你的一篇文章:千万级记录的
Discuz
论坛导致
MySQLCPU100%
的优化笔记
我看了之后,觉得你说的很对,虽然我不知道你在说什么,但我知道你应该能帮助到我……
呃……我的论坛,现在好像很慢,不知道是不是
mysql
的原因
如果你用空的话,能加我一下么,指导一下,感激不尽……
我的
qq:156994
非常感谢,祝你的程序员之路越走越远,你的理想也早日实现!
o(
∩
_
∩
)o...
XiaoHui
回复于
2007111023:48:
你先照我的文章看对照看一下。另外,查看一下任务管理器,你的
MYSQLDNT.EXE
的程序,占用
CPU
是否极高。如果不是,则不是
MYSQL
的原因了。
第
12
楼
陆林 发表于
2007111100:28|
陆林的所有评论
dizcus
的论坛网络上有这么多人用,有问题他们自己开发者难道不会解决?数据都是有缓存的,关索引屁事啊。
第
13
楼
时空论坛 发表于
2007111100:34|
时空论坛的所有评论
刚才逛
dizcus
官网,发现有人在争论小辉的这篇文章,从那边点过来的。呵呵,原来这里也这么热闹。
第12楼的,我的网站也用是的
dizcus
的论坛,数据记录有
1300
千万条,月初找到小辉,正好他有空,一个多小时就帮我解决了。事实胜于雄
辩,有些东西,需要海量数据是验证的。一般的小数据量也许说明不了问题。
第
14
楼
cn256
发表于
2007111217:18|cn256
的所有评论
你好,我想问下,除了
DZ
出现此问题外,我的站主要是
SS
出现
MYSQl
占
CPU100%
的问题,有没有
SS
的解决办法?谢谢。
XiaoHui
回复于
2007111313:48:
SS
是什么?
第
15
楼
cn256
发表于
2007111222:02|cn256
的所有评论
SS
就是
SupeSite/XSpace
,在
DZ
官方论坛有专栏的。
数据库也是用
MYSQL
,我的站经常因这样被
DOWN
,很是郁闷,希望能得到你的帮助,谢谢!
祝你工作顺利,身体健康,全家幸福!
XiaoHui
回复于
2007111313:49:
如果确定是
MYSQL
占用的额度高,你可以进入本站的 个人消息中心
(www.xiaohui.com/msg/)
与我联系。我周六可以帮你看看。
第
16
楼
秋秋 发表于
2008011720:21|
秋秋的所有评论
你好,小辉
我看了你关于
w3wp
占用百分百的问题
解决办法,是让执行那些语句
我是想问,执行,是在
PHPMYADMIN
里执行,还是
dz
论坛后台执行啊,迫切的需要解决,谢谢你
我
qq“156994
我的
MYSQLDNT.EXE
程序占用百分之
3
左右 谢谢
XiaoHui
回复于
2008011721:28:
你可以在
MySQL
的命令行 或
phpmyadmin
下执行。
第
17
楼
秋秋 发表于
2008011813:36|
秋秋的所有评论
谢谢小辉的回答,我没有装
phpmyadmin
也不会安装,在
mysql
的命令行下执行,我也听不懂,不过,我问下简单的,就是,
dz
后台有数据库升
级。可以填写命令,然后提交,请问,这个可以么?
再次感谢小辉
~
XiaoHui
回复于
2008011819:35:
我没有用过
DZ
最新版本中支持后台数据库升级的模块。如果它可以执行
SQL
命令,按理说是可以的。
但我不能给你打包票,需要你自己测试一下。并且,为了数据安全,做之前最好将数据库做备份。
第
18
楼
秋秋 发表于
2008012019:01|
秋秋的所有评论
谢谢小辉,可是,我不太敢试,你什么时候有空,能帮帮我么,小辉,拜托了,我的
qq:626793276
第
19
楼
bambo
发表于
2008022202:08|bambo
的所有评论
以前就看过你的前一篇文章
,
也在收藏栏里收藏了
,
今天在
DZ
看到链接又来看了
.
也有人用
DZ
出现这样的问题
,
我都会推荐让他来看你的博客
,
支持你一下
.
第
20
楼
027bbs
发表于
2008022402:01|027bbs
的所有评论
我新换的服务器也出现启动数据库
CPU
就占用
100%
的情况
,
有时间帮忙看下吗
?
一定感谢
QQ:200802718
第
21
楼
xyz
发表于
2008032709:56|xyz
的所有评论
我的现象是
w3wp.exe
大概每隔
20
分钟突然占用内存升高到几百
m
,导致内存耗尽应用程序池自动回收,这时网站无法访问,等几分钟回收后
又会正常。
第
22
楼
billee
发表于
2008032807:32|billee
的所有评论
我也有同的问题,但我不会改
可否帮忙下?也是
Mysql+PHP
的
在线才百来个人就占用
100%
的
CPU
资源
QQ
:
3074303
商量一下,呵呵
第
23
楼
6677875
发表于
2008040309:11|6677875
的所有评论
非常支持你,我的论坛也有问题是否有时间帮我看一下!付费也可以
第
24
楼
bizzx
发表于
2008042513:27|bizzx
的所有评论
discuz1500000
个用户时,用户列表翻页数度极其慢,有办法解决吗?支持楼主一下
XiaoHui
回复于
2008042516:06:
我没有研究过这个问题。如果你有慢查询的日志记录,问题肯定是可以能分析出来并解决的。
如果无法解决,那就应该属于人品问题了。
第
25
楼
建站铺 发表于
2008050202:54|
建站铺的所有评论
学习之中
第
26
楼
精致生活 发表于
2008051009:34|
精致生活的所有评论
DZ5.5
的站,运行一年,近几天发现
posts
表的
record
竟有
38891
条,而网站贴子
38800
条左右,请问一下小辉这属正常吗?谢谢!
XiaoHui
回复于
2008051009:37:
这种情况
,
有点数据冗余,是正常的。造成情况,一般因为删除主题时,论坛程序只删除了 主题数据(
thread)
,而忘了删除
posts
中的数据。不
会影响论坛的正常运行。
第
27
楼
Ray
发表于
2008053122:51|Ray
的所有评论
你好
,
最近我也遇到相关问题
,
请问
DZ6.0
还需要你谈及的
Quote:
ALTERTABLE`cdb_pms`ADDINDEX(`folder`);
ALTERTABLE`cdb_threads`ADDINDEX(`displayorder`);
ALTERTABLE`cdb_threads`ADDINDEX(`dateline`);
ALTERTABLE`cdb_threads`ADDINDEX(`closed`);
ALTERTABLE`cdb_threadsmod`ADDINDEX(`dateline`);
ALTERTABLE`cdb_sessions`ADDINDEX(`invisible`);
ALTERTABLE`cdb_forums`ADDINDEX(`type`);
ALTERTABLE`cdb_forums`ADDINDEX(`displayorder`);
第
28
楼
cocockle
发表于
2008061012:40|cocockle
的所有评论
你好
,
我现在也出现此类问题
@
动不动就出现
su
情况
!
我现在的是
6.1
请问
Quote:
ALTERTABLE`cdb_pms`ADDINDEX(`folder`);
ALTERTABLE`cdb_threads`ADDINDEX(`displayorder`);
ALTERTABLE`cdb_threads`ADDINDEX(`dateline`);
ALTERTABLE`cdb_threads`ADDINDEX(`closed`);
ALTERTABLE`cdb_threadsmod`ADDINDEX(`dateline`);
ALTERTABLE`cdb_sessions`ADDINDEX(`invisible`);
ALTERTABLE`cdb_forums`ADDINDEX(`type`);
ALTERTABLE`cdb_forums`ADDINDEX(`displayorder`);
能通用吗
!
或者帮我处理一下
,
我的
QQ:59805299
XiaoHui
回复于
2008061013:16:
不能保证通用。具体问题,要具体分析。这段代码,是以
Dizcus!5.5.0
的版本进行的校正。其他的版本,不敢保证。
这篇文章的重点,并不是作为结果的这段代码的,而是如何得出这个结果的分析过程。知道了原理,你自己一样可以分析。
第
29
楼
sudu8
发表于
2008071509:43|sudu8
的所有评论
一台服务器上有数个
MYSQL
数据库 现在
MYSQL
有时候会占很高
CPU
请问如何能查出是哪个数据库占的
CPU
?感谢指教
XiaoHui
回复于
2008071511:06:
在
MYSQLSHELL
下执行
showprocesslist;
或 在
my.ini
中, 配置
logslowqueries=xxxxx.log
然后再分析
.
第
30
楼
ff
发表于
2008072401:05|ff
的所有评论
第一次见到这么做索引的
...
建议作者再去学习一下
Mysql
如何调用索引
.
一个
SQL
查询
MySQL
只会从一个索引查询,最基本的道理都不懂么?
这么搞索引,会让
IO
负载无限增大的
第
31
楼
支持 发表于
2008090209:46|
支持的所有评论
支持你!
第
32
楼
henry
发表于
2008100618:59|henry
的所有评论
请教楼主
,
我安装
discuz6.1
时
服务器环境
(apache2.0+php5.26+ZendOptimizer+mysql5.0),
数据库在本机
,
论坛安装后速度挺快
0.0
几秒可显
示页面
,
不过数据库远程时
,
论坛的访问速度慢很多
,
要
4
秒以上
.
请问楼主有没有分布式部署的一些教程和解决方案
,
多谢了
.
XiaoHui
回复于
2008100620:44:
最好布署在同一机房比较好,速度应该没这么慢。抱歉的是,我分布式部署对这块没有详细了解。你可以了解一下这些知识点看看
MySQL
的
主从复制
MySQLProxy
以及
MySQL5.1
分区
第
33
楼
henry
发表于
2008100710:28|henry
的所有评论
谢谢楼主的回答
,
支持你
!
第
34
楼
风云在起 发表于
2008111116:35|
风云在起的所有评论
楼主
,
您好
,
请教问题,
Discuz
对
mysql
数据库释放的代码 是怎样处理的呢
?
我看了
DZ
代码 找了好久
,
都没看到哪里用到
close
函数来关闭数
据库连接 望指教
XiaoHui
回复于
2008111120:30:
这个我没注意过
.
手上没
DZ
的源码
.
你自己再细看看
.
第
35
楼
海量数据处理 发表于
2008121508:34|
海量数据处理的所有评论
辉兄。。。 能不写个上面
Mysql
语句的反向安装
我不小心按错数据库了。。
XiaoHui
回复于
2008121511:09:
没太听懂你的意思。装错数据库了,可以再移出来就是了啊。
第
36
楼
海量数据处理 发表于
2008121610:16|
海量数据处理的所有评论
不是啊,辉兄,我对
Mysql
的理解还处于婴儿时期,看了你的文章,就运行了
ALTERTABLE`cdb_pms`ADDINDEX(`folder`);
...
...
...
可是我运行的数据库不是安装
discuz
论坛的那个数据库
,,,
但我又不会手动删除操作
Mysql,
所以裸体跪求反安装,是不是把
ADD
改成
delete
就
行了
?
ALTERTABLE`cdb_pms`deleteINDEX(`folder`);
XiaoHui
回复于
2008122317:07:
还是没懂你的意思。不敢给你意见。
:)
你若是要删除
INDEX
, 用
DROP
,不是
DELETE
第
37
楼
笑容 发表于
2008122315:46|
笑容的所有评论
建议把加减法改到
10
以内,大了不会算。
另外表扬下你的耐心,这么耐心去哄他们,真厉害哈。
评论来自
www.mikaa.cn
一个千万级的黄页网站,正在捣鼓优化问题呢。呵呵
XiaoHui
回复于
2008122317:02:
呵呵,这个加法应该很好算的, 我设计的是
(1~9)+(10~19)
= ?
这个范围,应该不需要借助计算器,我女儿都会算了。
:)
第
38
楼
test
发表于
2008122716:39|test
的所有评论
授人以鱼,不如授人以渔。
能看多些实际操作文章更好。
目前只是通过增加
INDEX
来加快查询速度,不知道还有没有更多其它的方法。
例如,使用
WHERE
语句时要注意什么。
LIKE
如何写才规范。
LEFTJOIN
语句 多表联动查询,要注意什么。
内存表的深入应用。。。。。等等。。。。
第
39
楼
tatacom
发表于
2009020716:00|tatacom
的所有评论
80W
主题的论坛
,
用户访问翻页占
CPU
很厉害
,
请问有没有什么好的解决办法
?
慢查询日志里很多这样的
#Query_time:6Lock_time:0Rows_sent:38Rows_examined:33892
SELECTt.*FROMcdb_threadst
WHEREt.fid='58'ANDt.displayorderIN(0,1)
ORDERBYt.displayorderDESC,t.datelineDESC
LIMIT101,38;
#Query_time:6Lock_time:0Rows_sent:38Rows_examined:51837
SELECTt.*FROMcdb_threadst
WHEREt.fid='25'ANDt.displayorderIN(0,1)
ORDERBYt.displayorderDESC,t.datelineDESC
LIMIT25637,38;
第
40
楼
王子 发表于
2009021316:37|
王子的所有评论
不错的东西哦,谢谢分享
第
41
楼
灵格王子 发表于
2009040922:34|
灵格王子的所有评论
我的
discuz
论坛也是遇到了
CPU100%
的问题,在
discuz
的官网里发贴反映了两个多月,给康盛也打了电话无数,一直没有解决。我搜遍
了整个网络,本来不抱希望地找到了小辉。没想到他很快就帮我找到了问题症结并解决,我要给他辛苦费也不收。
在此特别表示感谢!
第
42
楼
Yancy
发表于
2009051823:52|Yancy
的所有评论
showprocesslist
看不全的时候可以用
showfullprocesslist
第
43
楼
snowfeng
发表于
2010012423:06|snowfeng
的所有评论
晕,怎么是乱码?上文
第
44
楼
snowfeng
发表于
2010012423:09|snowfeng
的所有评论
小辉,灵格王子,我也遇到你的问题了,我的
dz
数据库超过
1G
,在线人数
3000
以上。最近服务器的
cpu
一直保持在百分九十以上,
dz
论坛访问
就非常困难了,也影响了我的
uchome
,当我把
dz
论坛关闭的时候,
uchome
却一直正常,
cpu
的使用率也下来了,说明
dz
论坛的表可能有些问
题。请问,该如何解决?能帮帮我吗?最近一直很彷徨,哎。
第
45
楼
snowfeng
发表于
2010012423:11|snowfeng
的所有评论
灵格王子,请联系我,我遇到与你一样的问题。我的
QQ
:
1394376123
,希望小辉保留一下,如果小辉有时间帮我诊断一下,那就太好了。在此
感谢
!
共有评论
47
条
,
显示
45
条。
小辉程序员之路 建站于
1997
◇
做一名最好的开发者是我不变的理想……
Copyright(C)19972011XiaoHui.comAllrightsreserved
声明:站内所有原创文字,未经许可,均可转载、复制。
转载时必须以链接形式注明作者和原始出处。
搜索
:
GO»
Tags:Discuz|MySQL|CPU
占用
发表你的评论
如果你想针对此文发表评论
,
请填写下列表单
:
姓名
:
*
必填
Email:
可选
(
不会被公开
)
网站
/Blog:
可选
http://
反垃圾广告
:
为了防止广告机器人自动发贴
,
请计算下列表达式的值
:
4+12= *
必填
评论内容
:
*
必填
你可以使用下列标签修饰文字
:
[b]
文字
[/b]:
加粗文字
[quote]
文字
[/quote]:
引用文字
发表评论
首页 随笔 乐走天涯 猎户星
GoogleEarth
程序资料 程序生活 评论中心
Tag
论坛 其他资源 搜索 消息中心 联系我 关于
RSS
文章评论 发表你的评论
|
评论中心
|
联系我
RSS2.0 |
联系我
|
站内导航
|
隐私声明
|
版权声明
|
订阅邮件
|