本文不定时更新!
A: MySQL 执行 SHOW FULL PROCESSLIST
Q: 查看连接数和慢查询,适用于 MySQL 数据库无法连接 1040
A: iftop -i eth0
Q: 查看占用带宽的IP(命令:iftop -i eth0 -F ip/24
),添加到安全组、防火墙、宝塔的黑名单中。
命令 grep -l "x.x.x.x" /www/wwwlogs/*.log
可以在 wwwlogs 目录下的所有 .log 文件中查找指定的恶意 IP。
A: goaccess -f xxx.log
Q: 实时分析网站日志,查看请求最多的IP
A: net.xoyozo.weblog 日志分析工具
Q: 自制的 Web 日志分析工具,可按多种方式排序,纠出可疑访问
A: 重启 web 服务器
Q: 有时候能解决 CPU 和内存消耗的问题,如果一会儿又升高,则需要找另外的原因
Q: 500 服务器内部错误
502 Bad Gateway
504 Gateway Time-out
A: 查看 php 日志,可能的路径:
/usr/local/php/var/log/php-fpm.log
/www/server/php/[版本]/var/log/php-fpm.log
Q: RDS MySQL IOPS 使用率高的原因和处理
A: 根据时间点查看慢查询
Q: Discuz! 论坛界面错乱、表情不显示、模块缺失、登录失败、发帖失败等等
A: 进入管理中心 - 工具 - 更新缓存,能解决大部分问题
Q: Discuz! 浏览帖子提示“没有找到帖子”
A: 进入数据库,修复表 pre_forum_post 或分表
Q: CPU 100% 或内存 100%,负载100+
A: 原因有很多,以下是一些建议:
Windows 在任务管理器中查看进程
当前是否有正常的大流量访问(譬如民生类论坛的某个帖子突然火了)特别是重启无效的情况
对比网站日志大小可大致确定哪个网站被大量恶意请求。
观察:命令 top
排查:通过关闭网站来确定是某网站的问题,通过关闭功能确定是某功能的问题,如果 nginx 崩溃请参下条
案例:通过修改 mobcent 文件夹名确定是安米的文件被疯狂请求导致的,更新插件和 mobcent 包解决问题。
如果都是正常访问,top 看到很多 php-fpm,而且个个占用 CPU 还不小,那么根据服务器硬件配置来修改 php 的并发量,如宝塔面板在 php 设置 - 性能调整 页,300 并发方案的推荐配置是:
max_children:300
start_servers:30
min_spare_servers:30
max_spare_servers:180
另外,memcached 或 redis 的配置也可以进行相应的修改。
另一个案例是 kswapd0 进程占满 CPU,原因是内存不足导致 swap 分区与内存频繁交换数据。同样调整 php 的设置即可。
也可以通过 iftop 来查询占用带宽较多的 IP 并封禁(出方向),如果 CPU 能降下来,那这个 IP 就是罪魁祸首。
Q: 阿里云 ECS 的 CPU 突然达到 100%,并持续到次日 0:00 左右
A: 可能 ECS 是 t5 规格,受 CPU 积分制度限制,积分耗尽时 CPU 不工作。解决方法是更换其它规格产品或升配。
Q: ASP.NET 所在服务器 CPU 突然达到 50% 或 100%,并持续
A: 首先确定哪个网站,再依次排查网站各功能。可能是 HttpWebRequest 请求远程数据时长时间未返回结果导致的程序阻塞。
Q: nginx 服务停止
A: 查看 nginx 日志
WDCP 路径:/www/wdlinux/nginx-1.0.15/logs/error.log
Q: 公网出带宽 100%,其它指标正常
A: Windows 在任务管理器-性能-资源监视器-网络 查看占用带宽的进程PID,然后在任务管理器-详细信息中的找到对应的用户(如果为每个网站分别创建了用户,就能知道是哪个网站占用了带宽);如果是被 PID 为 4 的 System 占用大部分带宽,也可以尝试重启 IIS 来解决。
CentOS 使用 nethogs 查看占用带宽的进程PID和USER,如果为每个网站分别创建了用户,就能知道是哪个网站占用了带宽,否则只能一个个关闭网站来判断,不知道大家有没有好的方法?当然还可以直接用 iftop 命令查看占用带宽的 IP。另外,查看每个网站在那个时间段的日志文件的大小也能大概看出是哪个网站被采集了。
A: Linux 显示每个用户会话的登入和登出信息
utmpdump /var/log/wtmp
参考:http://www.tulaoshi.com/n/20160331/2050641.html
Q: RDS 的 CPU 100%
A: 如果是突然持续占满(同时伴随 ECS 资源使用率下降,页面出现 502),很大可能是受攻击(或社交网站推送突发事件等),查看“慢查询”,添加相关索引;如果是 Discuz! 论坛,可尝试修复优化表 pre_common_session。
如果是数日缓步上升,或新项目上线,考虑 SQL 慢查询,思路:MySQL / SQL Server。
MySQL:SHOW FULL PROCESSLIST
SQL Server:sp_who
Q: php 网站的服务器,内存在数天内缓慢上升
A: 大概是 php-fpm 占用过多,或进程数太多
更改 php 的配置(如 max_spare_servers),执行:service php-fpm reload
Q: 进程 cloudfs 占用内存过多
A: 参:https://xoyozo.net/Blog/Details/cloudfs-cache
Q: RDS 磁盘占用过大
A: 参:https://xoyozo.net/Blog/Details/how-to-use-rds
Q: ECS 受到 DDoS 攻击怎么办?
A: 参:https://xoyozo.net/Blog/Details/aliyun-ddos-without-bgp
Q: 如果 ECS 和 RDS 各项指标都没有异常,但网页打开慢或打不开502,TTFB 时间很长,是什么原因?(ECS 的 CPU 100%,RDS 的连接数上升,也可参考此条)
A: 数据库有坏表,尝试优化/修复表(慢 SQL 日志中锁等待时间较长的表?),或主备切换。show full processlist 时看到许多
DELETE FROM pre_common_session WHERE sid='******' OR lastactivity<****** OR (uid='0' AND ip1='*' AND ip2='*' AND ip3='*' AND ip4='*' AND lastactivity>******)
Q: Discuz! 创始人(站长)密码被改
A: 数据库找到 pre_ucenter_members 表,复制其它的已知登录密码的账号,复制其 password 和 salt 两个字段的值到创始人账号中,创始人账号即可用该密码登录了。
论坛使用阿里云的 ECS + RDS + OSS 搭建,最近经常隔三差五出现 RDS 的 CPU 和连接数突然满负荷的情况,导致数据库无法连接。这种情况一般会认为是受到了攻击,因为如果是访问量大或者是哪里有慢查询,应该是资源消耗逐步上升直至崩溃的,沿着这个思路去查 Web 日志封 IP,但效果不大,关闭功能、卸载插件也没用。
开启阿里云后台的 SQL 审计,能看到 SQL 查询日志,但是很难找有问题的 SQL。
最终在重启 RDS 后执行以下语句列出所有正在执行或阻塞的语句:
show full processlist
在结果列中,Command 为 Query 是正在执行查询操作的语句,发现几乎所有的 SQL 都是:
SELECT * FROM pre_forum_thread WHERE tid>0 AND fid IN('42','95','247','41','567','62','149','229','37','230','93','190','284','75','38','568') AND `fid`<>'546' AND replies > 0 AND displayorder>=0 ORDER BY lastpost DESC LIMIT 10
再加上之前出现的情况是,论坛帖子列表和详情页面能正常打开时,论坛首页也不一定能打开,所以基本定位到是“首页四格”的数据库查询导致的。
进入论坛后台首页四格设置,对比了版块 id 后确认了这个 bug。
单独执行该语句大约耗时 5s(主题帖 200 万),设置的缓存时间 10 分钟。
processlist 中看到这些语句的 state 都是 Creating sort index,尝试去掉 ORDER BY 后执行果然只需要 16ms。
5s 内的访客都是从数据库读取的,能处理完就正常,否则累积就导致 RDS 崩溃,每 10 分钟都会重现一次风险。
当然这个问题可以通过添加索引来解决。
对于大型站点,庞大的主题和帖子数据,分表放到一个主题表和一个帖子表中,已经成为影响性能的一个因素。因此,急需进行分表操作来避免 MySQL 对于大数据表的频繁操作。
1、后台分表
Disucz! X2 后台重新调整了分表的机制,使得分表效率和后期站点性能得到提升。具体分表设置在 后台 -> 站长 -> 主题分表(帖子分表)。
1)主题分表
主题分表分为两种类型,一种为主表,一种为存档表。主表只有一个,存档表可以有多个。我们进行分表操作,首先进行创建存档表的操作,然后进行主题移动,将指定条件的主题移动到存档表中。
a、创建存档表
打开 source/admincp/admincp_threadsplit.php 文件,找到创建存档表的条件分支
- elseif($operation == 'addnewtable')
复制代码
首先获取当前最大的主题表 id ,然后根据 forum_thread 的建表语句,生成新的存档表(id + 1),最后更新缓存。
b、主题移动
存档表建好后,下一步就是将主题移动到这个存档表中。在选择主题的时候,可以根据提供的搜索条件,特别是“更多选项”中的搜索条件,来转移符合条件的主题。这里主要是一个搜索的过程,转移数据的过程使用 REPLACE INTO … SELECT...FROM... 语句,比较简单。
2)帖子分表
帖子分表也是要分成两步,第一步先创建帖子分表,第二步转移数据。
打开 source/admincp/admincp_postsplit.php 文件,找到帖子分表的条件分支
- elseif($operation == 'split')
复制代码
如果是对主表进行分表操作,主表必须要大于400M,见下面的条件判断
- if($status && ((!$tableid && $status['Data_length'] > 400 * 1048576) || ($tableid && $status['Data_length'])))
复制代码
在站长提交分表表单后,程序会先根据 getmaxposttableid 函数获取当前帖子表最大的 id ,然后根据已有的帖子表结构,创建新分表,并更新缓存等信息。创建成功后,开始转移数据的操作。找到条件分支
- elseif($operation == 'movepost')
复制代码
,开始转移数据的操作。当从主表中转移数据时,是根据主题表中最后回复时间正序排列的主题 tid 来获取帖子数据的。
- $query = DB::query("SELECT tid FROM ".DB::table($table)." WHERE posttableid='0' AND displayorder>='0' ORDER BY lastpost LIMIT 0, 1000");
复制代码
然后,利用 movedate 函数进行转移数据。
当从从表中转移数据时,是根据给定帖子表的 id,获取此表中first=1的帖子所属 tid,
- $query = DB::query("SELECT tid FROM ".DB::table(getposttable($fromtableid))." WHERE `first`='1' LIMIT 0, 1000")
复制代码
然后利用 movedate 函数进行转移数据。
在 movedate 函数中,根据获取到的 tid ,将属于此 tid 的帖子,利用 INSERT INTO … SELECT … FROM ...来转移数据。在此过程中,更新主题表中 posttableid 这个字段,来标识帖子的存储表。
2、主题列表页分表读取
在主题列表页,只能看到主题主表中的主题。存档表中的主题都在存档区。
在这部分的代码(source/module/forum/forum_forumdisplay.php)中,所有涉及到的主题表都以 $threadtable 这个变量代替,$threadtable 这个变量的获取,又是根据用户是否查看存档区的标识 archiveid 来判定。
- $threadtable = $_G['gp_archiveid'] && in_array($_G['gp_archiveid'], $threadtableids) ? "forum_thread_{$_G['gp_archiveid']}" : 'forum_thread';
复制代码
当用户选择非存档内容时,archiveid = 0 或者不存在,这时,直接从 forum_thread 主表来读取主题列表。当用户选择存档内容时,archiveid = 1(1 表示存档表的 id,如果查看 id 为 2 的存档表,archiveid = 2),程序会根据 archiveid 来判断从哪个存档表中去获取主题列表。
3、帖子内容页分表读取
当用户浏览帖子内容页时,程序首先利用 loadforum 函数来获取当前的主题信息。在 loadforum 函数中,
- $_G['thread'] = get_thread_by_tid($tid, '*', $addcondiction, $archiveid);
复制代码
根据提供的 tid,get_thread_by_tid 函数到主表和存档表中分表去查找,直到找到对应的主题信息。
在 source/module/forum/forum_viewthread.php 文件中,根据
- $thread = & $_G['forum_thread'];
复制代码
- $threadtable = $thread['threadtable'];
- $posttableid = $thread['posttableid'];
- $posttable = $thread['posttable'];
复制代码
这两句来判定该主题应该去哪个帖子表中去获取帖子内容列表。
4、发新主题
发表新主题时,直接往主题主表中插入数据,对应的 posttableid = 0。然后,当插入帖子数据时,通过 insertpost 函数将数据插入帖子表中。
在 insertpost 函数中,会先去判断所属主题的 posttableid 值,得到目标帖子表,然后再往该帖子表中插入帖子数据。
5、发新回复
只有在主表的主题才能回复,因此,直接根据传递的tid去获取目标帖子表,然后插入数据。这个跟发新主题时,插入帖子内容过程相同。
6、编辑帖子
同样,只有在主表中的主题的帖子才能被编辑,因此,主题都在 forum_thread 表中。需要获取的是该主题的帖子在哪个帖子表中。打开 source/include/post/post_editpost.php 文件,找到
- $posttable = getposttablebytid($_G['tid']);
复制代码
程序在开始,通过这条语句来获取目标帖子表。在 getposttablebytid 函数中,程序根据 tid ,逐个主题表进行查找,找到对应的主题信息,获取目标帖子表,然后指向后续的编辑帖子操作。
8、取消存档
存在存档区的主题,如果想取消存档,可以通过页面底部的“取消存档”来执行。
打开 source/include/topicadmin/topicadmin_restore.php 文件,可以看到取消存档,实际上仅是将放在存档表中的主题移动到了主表中。同样,存档表的获取还是通过 archiveid 这个参数来决定的。
- $threadtable = $archiveid ? "forum_thread_$archiveid" : 'forum_thread';
复制代码
从这可以看出,存档的概念仅限于主题,帖子无所谓存档的概念。
wxy0510:经过用户表优化后,论坛不活跃用户将被转至存档表。这将意味着论坛在常规调用、查询都不会遍历这些存档表的数据。这也大大提高服务器工作效率,减少服务器负载。当然处于存档表的用户在执行一次登录操作后,数据会重新转入主表。
xoyozo:这个登录是指论坛本身的用户登录,如果用第三方客户端 App 登录一般是不起作用的(除非 App 考虑到了这个情况)
common_member 是主表,common_member_archive 是存档表,这两个表的用户数相加即为 UC 用户表 ucenter_members 中的用户总和。
准备:
先把超时时间改成 300 秒,参 http://www.cnblogs.com/jackluo/p/3366612.html
了解一下分表基本原理:http://www.discuz.net/thread-2132691-1-1.html
主题分表:
可以任意创建主题存档表(forum_thread_X)
使用“主题移动”功能,筛选符合条件的主题,移动到主题存档表
新发表的主题仍然存于原始表(forum_thread)
移动到存档表中的主题,会在主题所在的版块下建立一个存档区,通过存档区可浏览存档表中的主题。
存档表中的主题,只供浏览,不可回复、评分,不能进行管理操作,但可以删除和移动到非存档区。
帖子分表:
帖子没有存档的概念
可以任意创建帖子分表(分表时创建新表或选择已存在分表)
一次分表操作可移动100MB的整数倍数据
根据主题表中最后回复时间正序排列的主题(first=1)tid 来获取帖子数据的
并将该主题的所有帖子移到目标表中
更新主题表中 posttableid 这个字段,来标识帖子的存储表
关闭论坛
关闭论坛监控
关闭数据库自动备份
主题先不分
第一个 100MB 用了 75 分钟,后来发现问题,数据库恢复了一下
然后1G用了1个半小时,估计恢复的时候顺便“优化”了
转移后打开帖子提示“没有找到帖子”,或者优化后打开帖子提示“没有找到帖子”,只要在数据库里“修复”一下就行了。(在Navicat“对象”中选中所有表,右键分析)