博客 (21)

用过 FlashFXP 的朋友可能会它强大的功能赞不绝口，但不免费啊，用破解版对咱们的账号安全也存在一定风险。所以平常用得最多的是免费开源的 FileZilla。

今天我把觉得 FileZilla 最应该支持的“计划任务”和“站点对传”两个功能在官方论坛进行了咨询。据 FileZilla 官方回复，暂时没有支持“计划任务”的时间表，而且由于不兼容 SFTP 的原因，服务器对服务器的直接传输也无法实现。（他可能误解了我说的“站点对传”的意思了吧）

初码 - 博客园     初码静态模板

浏览示例前，将以下域名的重定向加入到 hosts 中可以加快页面的打开速度：

127.0.0.1	fonts.googleapis.com
127.0.0.1	ajax.googleapis.com
127.0.0.1	player.vimeo.com
127.0.0.1	www.vimeo.com

本文不定时更新！

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 两个字段的值到创始人账号中，创始人账号即可用该密码登录了。

Q： 通过 iftop 观察到，Discuz! 网站从 RDS 数据库到 ECS 网站服务器私网流量非常大，远大于公网流量

A： 可能是缓存出问题了，尝试卸载重装 Redis 来解决。

Q： 宝塔面板中安装的 Redis 经常自动停止

A： 尝试卸载重装 Redis 来解决。

Q： 马甲客户端出现“您的网络有些问题”

A： 原因有许多，其中一个就是新建了一个数据表，然后 /source/class/table/ 下面丢失了对应的文件，具体可以找官方排查原因。

Q： 排查服务器安全需要检查哪些日志？

A： Web日志、登录日志（/var/log/secure）等。

论坛使用阿里云的 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 分钟都会重现一次风险。

当然这个问题可以通过添加索引来解决。

今天在逛汽车之家论坛时偶然发现，当选中帖子内容时，部分文字被空缺出来，没有被选中，一开始以为是把部分文字使用图片来代替了，审查元素发现是常见文字使用伪元素来输出，比如“大”字：

<span class="hs_kw10_mainuD"></span>

.hs_kw10_mainuD 样式：

.hs_kw10_mainuD::before {
    content: "大";
}

这样肉眼根本无法察觉，因为不管字体大小、颜色等等都与普通文字一样，这是区别于用图片代替的最大优势，其次还能减少请求数，减少带宽消耗等。

wxy0510：经过用户表优化后，论坛不活跃用户将被转至存档表。这将意味着论坛在常规调用、查询都不会遍历这些存档表的数据。这也大大提高服务器工作效率，减少服务器负载。当然处于存档表的用户在执行一次登录操作后，数据会重新转入主表。

xoyozo：这个登录是指论坛本身的用户登录，如果用第三方客户端 App 登录一般是不起作用的（除非 App 考虑到了这个情况）

common_member 是主表，common_member_archive 是存档表，这两个表的用户数相加即为 UC 用户表 ucenter_members 中的用户总和。

PW 的 pw_bbs_threads 存主题， pw_bbs_posts 存回复
DZ 的 pre_forum_thread 存主题，pre_forum_post 存主题+回复
论坛当初是从 PW 转到 DZ 的，转换程序把主题往帖子表（pre_forum_post）上插了一份，所以现在发现旧帖的主题的 pid 比它的回复的 pid 还要大的情况。

准备：

先把超时时间改成 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“对象”中选中所有表，右键分析）

以某论坛配置 memcache 只允许本机 IP 访问 11211 端口为例：

一句一句执行：

service iptables status // 查询当前防火墙状态

iptables -A INPUT -s 127.0.0.1/24 -p tcp --dport 11211 -j ACCEPT // 允许本地回环

iptables -A INPUT -s X.X.X.X/24 -p tcp --dport 11211 -j ACCEPT // 允许本机内网IP

iptables -A INPUT -s X.X.X.X/24 -p tcp --dport 11211 -j ACCEPT // 允许本机公网IP

iptables -A INPUT -p tcp --dport 11211 -j DROP // 禁止其它IP

service iptables status // 查询当前防火墙状态

service iptables save // 保存规则

今天终于把大量占用论坛服务器带宽的元凶找到了！

我们的论坛使用阿里云的 ECS+RDS+OSS+CDN 架构，最近发现 ECS 的带宽怎么都不够用了，也没有什么突发事件呀，再说附件都在 OSS 上。观察了云监控控制台，发现半夜里的流量也不减呀，白天更是触顶下不来，坛友们真是不辞辛劳为 PV 作贡献啊。

我对 CentOS 还是不够熟悉的，查阅了一些资料后，终于找到方向入手了。

重点肯定是日志文件了，但是面对每天几个 G 的大块头，还真是无法下手，一条一条看估计胡子都白花花了。

那么，首先安装 GoAccess 这个好东西（yum install goaccess）

然后进入网站日志目录，用 GoAccess 来分析一下（goaccess -f xxxxxx.log -a），具体用法参官网

选择日志格式，nginx 默认为 NCSA Combined Log Format，空格选中，回车确认

稍等片刻就可以看到主界面了，统计信息丰富多彩，统计结果一目了然，看截图，如果你分析的日志文件是当前正在使用中的，它还会每秒刷新主界面，让你看到实时统计

大致分为几块内容：

按 1 定位到“按天访问量”

按 2 定位到“最多次被请求的 URL”

按 3 定位到“最多次被请求的静态文件”

按 4 定位到“最多次被请求的 404”

按 5 定位到“最多次请求的用户 IP”

按 6 定位到“用户的操作系统”

按 7 定位到“用户的浏览器”

按 8 定位到“按小时的统计”

按以上数字键后，再按回车可以查看具体或更多的信息，按 s 可以更换排序，按 q 返回或退出

那么我先找 5 最多次请求的用户 IP，排前面的全部是从 60.191.127.4 到 60.191.127.26 的 IP，每个 IP 都是几 G 级的带宽占用。

负责任的，你必须保证这些 IP 不是政府或大企业的对公 IP，而且得拿这些 IP 直接去日志文件里搜到底请求了哪些 URL。经查证，它们只请求版块的帖子列表页，没有请求任何图片、脚本、样式等，还有，UserAgent 中没有带 Spider 之类的关键字，证明不是搜索引擎的蜘蛛，那么就可以果断认为它“不是人”

啥都不说了，找到 nginx 的 conf 配置文件，在 server 中添加 deny 60.191.127.0/24;

检查配置：nginx -t

使配置生效：nginx -s reload

呵呵，马上就能在阿里云监控里看到过山车式的折线了。 

另外，备注下查看各IP的连接数的命令：

netstat -an|grep :80| awk '{print $5}'| cut -d':' -f1| sort |uniq -c