1、 Discuz!论坛需要PHP和MYSQL的支持,因此,应确保系统具备支持此种环境。
2、 Discuz!论坛最新版本的免费软件可以到此处下载http://www.discuz.com/index.php?category=4
第 二 步: 上传
使用 FTP 软件登录到主机所在空间,建立一个单独的目录,或选择合适的位置,确保存放在此位置的文件能够被 web 请求所访问到,并且该目录中具有执行 PHP 代码的权限。将Discuz! 文件包的 ./upload 目录中的全部文件和目录结构上传到服务器(注意是上传 upload 目录中的文件和目录,而不是上传包含 upload 目录本身的目录和结构)。Discuz! 要求使用 FTP 软件上传 php 文件时,使用二进制(BINARY)方式进行,否则将无法正常使用。
第 三 步: 安装
1、 在系统中建立mysql数据库,设置好用户名和密码。
2、 在前两步工作完成之后,进入地址:http://您的域名/论坛目录/install.php,之后按照Discuz!论坛的系统安装引导,逐步进行安装,需要注意的是,安装数据库时,必须指定数据库服务器的名称(默认为本地localhost,如果Discuz!论坛和数据库服务器不在同一台机器,需要填写数据库服务器的IP或者数据库服务器的名称;之后填写数据 库名称、用户名、密码,选择使用的语言版本;简体中文请选择GB2312;然后指定管理员名称和密码;安装完成。
3、 使用管理员登录系统进行配置。
第 四 步:测试
打开前台,检测配置是否生效,模板显示是否正常,如果不正常,则进行相应的调整。
注意事项:
1、 如果要在原有Discuz!论坛上进行升级,请下载升级文件并按照升级说明进行安装。
2、 升级时请先备份原有站点的数据库和网页文件。
3、 模板文件可以自由更换和设计,可以登录到www.discuz.net上下载最新的模板。
我们先来看第一个阶段,MySQL慢的诊断思路,一般我们会从三个方向来做:
第一个方向是MySQL内部的观测
第二个方向是外部资源的观测
第三个方向是外部需求的改造
1.1 MySQL 内部观测
我们来看MySQL内部的观测,常用的观测手段是这样的,从上往下看,第一部分是Processlist,看一下哪个SQL压力不太正常,第二步是explain,解释一下它的执行计划,第三步我们要做Profilling,如果这个SQL能再执行一次的话, 就做一个Profilling,然后高级的DBA会直接动用performance_schema ,MySQL 5.7 以后直接动用sys_schema,sys_schema是一个视图,里面有便捷的各类信息,帮助大家来诊断性能。再高级一点,我们会动用innodb_metrics进行一个对引擎的诊断。
除了这些手段以外,大家还提出了一些乱七八糟的手段,我就不列在这了,这些是常规的一个MySQL的内部的状态观测的思路。除了这些以外,MySQL还陆陆续续提供了一些暴露自己状态的方案,但是这些方案并没有在实践中形成套路,原因是学习成本比较高。
1.2 外部资源观测
外部资源观测这部分,我引用了一篇文章,这篇文章的二维码我贴在上面了。这篇文章是国外的一个神写的,标题是:60秒的快速巡检,我们来看一下它在60秒之内对服务器到底做了一个什么样的巡检。一共十条命令,这是前五条,我们一条一条来看。
1.uptime,uptime告诉我们这个机器活了多久,以及它的平均的负载是多少。
2.dmesg -T | tail,告诉我们系统日志里边有没有什么报错。
3.vmstat 1,告诉我们虚拟内存的状态,页的换进换出有没有问题,swap有没有使用。
4. mpstat -P ALL,告诉我们CPU压力在各个核上是不是均匀的。
5.pidstat 1,告诉我们各个进程的对资源的占用大概是什么样子。
我们来看一下后五条:
首先是iostat-xz 1,查看IO的问题,然后是free-m内存使用率,之后两个sar,按设备网卡设备的维度,看一下网络的消耗状态,以及总体看TCP的使用率和错误率是多少。最后一条命令top,看一下大概的进程和线程的问题。
这个就是对于外部资源的诊断,这十条命令揭示了应该去诊断哪些外部资源。
1.3 外部需求改造
第三个诊断思路是外部的需求改造,我在这里引用了一篇文档,这篇文档是MySQL的官方文档中的一章,这一章叫Examples of Common Queries,文档中介绍了常规的SQL怎么写, 给出了一些例子。文章的链接二维码在slide上。
我们来看一下它其中提到的一个例子。
它做的事情是从一个表里边去选取,这张表有三列,article、dealer、price,选取每个作者的最贵的商品列在结果集中,这是它的最原始的SQL,非常符合业务的写法,但是它是个关联子查询。
关联子查询成本是很贵的,所以上面的文档会教你快速地把它转成一个非关联子查询,大家可以看到中间的子查询和外边的查询之间是没有关联性的。
第三步,会教大家直接把子查询拿掉,然后转成这样一个SQL,这个就叫业务改造,前后三个SQL的成本都不一样,把关联子查询拆掉的成本,拆掉以后SQL会跑得非常好,但这个SQL已经不能良好表义了,只有在诊断到SQL成本比较高的情况下才建议大家使用这种方式。
为什么它能够把一个关联子查询拆掉呢?
这背后的原理是关系代数,所有的SQL都可以被表达成等价的关系代数式,关系代数式之间有等价关系,这个等价关系通过变换可以把关联子查询拆掉。
上面的这篇文档是一个大学的教材,它从头教了关于代数和SQL之间的关系。然后一步步推导怎么去简化这句SQL。
第一,MySQL本身提供了很多命令来观察MySQL自身的各类状态,大家从上往下检一般能检到SQL的问题或者服务器的问题。
第二,从服务器的角度,我们从巡检的脚本角度入手,服务器的资源就这几种,观测手法也就那么几种,我们把服务器的资源全部都观察一圈就可以了。
第三,如果实在搞不定,需求方一定要按照数据库容易接受的方式去写SQL,这个成本会下降的非常快,这个是常规的MySQL慢的诊断思路。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)