“/”应用程序中的服务器错误。

---

未能加载文件或程序集“MySql.Data.Entity.EF6, Version=6.10.7.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d”或它的某一个依赖项。找到的程序集清单定义与程序集引用不匹配。 (异常来自 HRESULT:0x80131040)

6.10.7 版本的 MySql.Data.Entity.EF6.dll 文件发布后会自动变成 6.10.6，文件大小一样，只要用 FTP 上传覆盖一下即可。

本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)

本文基于 MySQL 的 InnoDB BTREE 方法的索引进行测试。

以一张包含 2000 万条记录的表做实验：

CREATE TABLE `dt_read`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `time` datetime(0) NOT NULL,
  `a_id` int(11) NOT NULL,
  PRIMARY KEY (`id`) USING BTREE
);

这张表是用于记录文章点击量的，

`id` 为主键，int(11) 自增；

`time` 为非空 datetime，表示文章打开时间，测试数据是从 2017-03-11 至 2018-04-28；

`a_id` 为非空 int(11)，表示文章 ID，在此表中不唯一，测试数据是从 1 至 260218。

体验“全表扫描”

首先来体验一下什么是全表扫描，执行下面语句：

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' LIMIT 10

> 时间: 0.012s

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 7.317s

表中数据是按主键从小到大排列的，当查询条件为 `time` < '2020-1-1' 时，能很快地从表的前端找到 10 条满足条件的数据，所以不再继续判断后面的记录，立刻返回结果，耗时 0.012 秒；但当条件改为 `time` < '2000-1-1' 时，同样逐条判断，直到最后一条也没有找到，这种情况就是所谓的“全表扫描”，耗时 7 秒。

索引对 ORDER BY 的 ASC 和 DESC 的影响

我们给 `time` 建一个索引，同样执行刚才需要全表扫描的语句：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 0.012s

创建 `time` 的索引后，相当于生成了一张按 `time` 字段排列的新表，这时 MySQL 就能够很快地定位并找到符合条件的记录，避免了全表扫描。

试试按 `time` 倒序排：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `time` DESC LIMIT 10

> 时间: 0.013s

结论：索引对 ORDER BY 的顺序（ASC）和倒序（DESC）都是有效的。

索引字段的次序对 WHERE 和 ORDER BY 的影响

删除所有索引，创建一个新的索引，字段依次为 `time`, `a_id`。

分别执行以下查询：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 AND `time` < '2000-1-1' LIMIT 10

> 时间: 0.013s

结论：MySQL 会自动优化 WHERE 条件的次序来匹配最合适的索引。

但在 ORDER BY 中却不是这么回事了：

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `a_id`, `time` LIMIT 10

> 时间: 14.066s

原因也很好理解，对两个字段进行排序，先后次序肯定会影响结果集，因此只能以 SQL 语句指定的字段次序来 ORDER BY，这样，按索引的字段次序进行 ORDER BY 查询无疑是更快的。

索引中的字段必须依次使用

保持上例创建的索引不变，即 `time`, `a_id`。

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 LIMIT 10

> 时间: 6.438s

上句合理利用了索引的字段，而下句跳过了 `time`，直接 WHERE 了 `a_id`，这是不受该索引支持的。

我们可以想象一下这张由索引生成的虚拟表，其实就是一张普通的平面二维表格，按索引指定的字段次序进行了排序，所以全表中仅仅是索引指定的第一个字段是按大小排列的，第二个字段是在第一个字段值相同的区域内按大小排列，后同。所以，跳过索引指定的第一个字段直接对第二个字段进行检索，是无法应用该索引的。这个结论也同样也体现在 ORDER BY 语句中：

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 29.566s

WHERE 和 ORDER BY 混合

保持上例创建的索引不变，即 `time`, `a_id`。

先来执行这两句：

SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 12.29s

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s

仅仅 WHERE 了一个 `time`，对 ORDER BY `a_id` 的效率却有质的提升，是因为 WHERE 中的 `time` 和 ORDER BY 中的 `a_id` 一起找到了索引吗？答案是否定的。

我们把时间改大，让它能马上找到符合条件的数据：

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 22.34s

为什么这个语句就不走索引了呢？

其实，一个简单的 SELECT 查询语句，首先执行 WHERE，然后 ORDER BY，最后是 LIMIT。每一步都独自去找了索引，而非 WHERE 和 ORDER BY 混在一起去找索引。必须保证每一步是快的，最终才是快的。

当 `time` < '2000-1-1' 时，WHERE 用到了索引，所以很快，ORDER BY 却没有用到索引，但为什么也很快呢？因为 WHERE 的结果集非常小（示例中为 0 条）。

当 `time` < '2020-1-1' 时，WHERE 也用到了索引，但其结果集非常大（示例中为所有记录），再 ORDER BY `a_id` 就非常慢了，因为我们没有创建以 `a_id` 开头的索引。

现在把索引改成只有 `time` 一个字段。

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 6.033s

因为索引里有 `

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 ORDER BY `time` LIMIT 10

> 时间: 6.033s

第二句先 WHERE `a_id`，后 ORDER BY `time` 是不能匹配所建的索引的。

索引中的字段越多越好

分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：

本例使用 ORDER BY 而不是 WHERE 来测试是因为，在 WHERE 的多个条件下，如果符合前一条件的筛选结果集过小会导致判断第二条件时数据量不足，无法判断索引是否起作用。

SELECT * FROM `dt_read` ORDER BY `time` LIMIT 10

仅创建索引（`time`）的情况下：

> 时间: 0.013s

仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

仅创建索引（`time`）的情况下：

> 时间: 15.015s

仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.014s

可以看到，在索引字段依次使用的前提下，索引字段数不少于查询字段数才能避免全表扫描。

虽然索引中的字段越多越好，但必须依次使用，否则也是无效索引。

索引对 INSERT / UPDATE / DELETE 的效率影响

分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：

INSERT INTO `dt_read` (`time`, `a_id`) VALUES ('2018-4-28', 260218)

不建索引的情况下：

> 时间: 0.01s

仅创建索引（`time`）的情况下：

> 时间: 0.01s

同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s

UPDATE `dt_read` SET `time` = '2018-4-28' WHERE `id` = 20000000（注：存在该 id 值的记录）

不建索引的情况下：

> 时间: 0.01s

仅创建索引（`time`）的情况下：

> 时间: 0.01s

同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s

虽然在 INSERT / UPDATE / DELETE 时数据库会更新索引，但从实测数据来看，索引对其效率的影响可忽略不计。

一些误区

“in 语法效率很低”?

in 语法也是应用索引的，网传 in 会比一个一个 WHERE OR 要慢得多的说法是不靠谱的。in 主键和 in 索引同理。

另外：

对于字符串类型，LIKE '%abc%' 是不能应用索引的，但 LIKE 'abc%' 可以。更多关于字符串类型的索引，请查阅全文索引（FULLTEXT）。

索引的字段是可以指定长度的，类似字符串索引指定前面若干唯一字符就可以优化效率。

本文系个人实践总结，欢迎批评指正！

软碟通制作 Windows 系统安装盘过程：

1. 下载微软官方提供的 iso 系统镜像文件

2. 如果 U 盘容量缩水，或根本无法正常使用 U 盘，使用老毛桃还原 U 盘空间

3. 打开 UltraISO，打开要写入 U 盘的 iso 文件

4. 在菜单上选择：启动 - 写入硬盘映像...

5. 选择硬盘驱动器，格式化，写入（注意：点击“写入”是按 FAT32 重新格式化的，若要制作 NTFS 文件系统的 U 盘，请先按 NTFS 格式化，然后在此界面上点击“便捷启动”-“便捷写入”）

6. 如果 U 盘足够大，可以在 U 盘里多放几个系统镜像，双击打开另一个 iso，将所有文件和文件夹复制到 U 盘上新建的目录中。这样下次需要安装什么系统时，只要把对应的系统的文件放到 U 盘根目录，其它系统移到二级目录中即可。当然还可以往里面存放一些常用软件。

另外最好常备一个带有 PE 系统的启动盘，在旧电脑上安装旧系统时经常会用到。

如果在分区那步无法删除或创建分区（提示动态卷什么的），在确认放弃磁盘中的文件的前提下，可以使用 Shift + F10 调出命令行，键入 diskpart，列出磁盘（list disk），选择磁盘（select disk 0），清除（clean），注意 U 盘启动盘也会在列表中，勿删！

*出血：为了提高二维码识别度，在生成的二维码四周留出若干码元（建议 4 个）空白。

更多

使用 ThoughtWorks.QRCode 生成二维码

使用 ZXing.Net 生成二维码

经常会看到这样似错非错的提示：

当前上下文中不存在名称"__o"

The name '__o' does not exist in the current context

实际上，我没有定义任何名为 __o 的变量。

发生这种情况的原因可能是使用了类似如下的代码：

<% if(true) { %>
<%= 1 %>
<% } %>
<%= 2 %>

为了在设计界面的 <%= %> 代码块中提供智能感知，ASP.NET（VB 或 C#）会自动生成一个名为“__o”的临时变量，这在页面编译器看到第一个 <%= %> 块时就完成了。但是在这里，<%= %> 块在 if 中出现，所以当关闭 if 后再使用 <%= %> 时，变量超出了定义的范围。

if (true)
{
    object @__o;
    @__o = 1;
}
@__o = 2;

解决方法：在页面的早期添加一个虚表达式。例如：<%= "" %>。这将不会呈现任何内容，并且它将确保在任何潜在的 if（或其他范围界定）语句之前，在 Render 方法中将 __o 声明为顶级。

当然还有一种治标不治本的方法就是隐藏这些错误提示（这并不影响程序正常运行）：

点击错误列表面板左上角的过滤器按钮，CS0103，其中包含错误代码：当前上下文中不存在名称"__o"，这些错误将不再显示，您仍然可以有其他 IntelliSense 错误和警告。

本文基于使用 Navicat 进行数据传输：

配置源数据库和目标数据库：

切换到“高级”。如果是同类型数据库，会有“包含自动递增”选项，但是，从 SQL Server 迁移到 MySQL 则没有：

传输完成后，我们需要对目标数据库作以下调整：

其它我没有使用到的字段类型暂未列出。

MySQL 中将用于外键约束的主键设置为自动递增

当主键用于其它表的外键约束时，我们无法更改该主键：

1833 - Cannot change column 'id': used in a foreign key constraint 'FK_xxx' of table 'xxx'

可以先禁用外键检查再设置自增：

set foreign_key_checks = 0;
ALTER TABLE `<table>` MODIFY COLUMN `id` int(11) NOT NULL AUTO_INCREMENT FIRST;

执行完后，foreign_key_checks 会自动恢复为 1。

上一篇介绍了如何创建用于 https 的 SSL 证书，本文讲述如何将创建好的 SSL 证书配置到 nginx 中。

导入证书

将 .key 文件和 .crt 文件上传到服务器，位置如：/etc/ssl/

配置 .conf

打开网站配置文件 *.conf，一般在 /usr/local/nginx/conf/vhost/

添加监听 443 端口：

listen 443 ssl;

添加 ssl 配置信息：

ssl_certificate /etc/ssl/yourdomain.com.crt;
ssl_certificate_key /etc/ssl/yourdomain.com.key;
ssl_prefer_server_ciphers on;

yourdomain.com.crt 和 yourdomain.com.key 改成真实的文件名

实现 http 自动跳转 https

配置非 443 端口请求跳转 443 端口访问：

if ($server_port !~ 443)
{
    rewrite ^(/.*)$ https://$host$1 permanent;
}

如果要求仅将 GET/HEAD 请求自动跳转（POST 请求自动跳转会丢失表单数据），那么改成：

set $redirect_https 0;
if ($server_port !~ 443)
{
    set $redirect_https 1;
}
if ($request_method ~ ^(GET|HEAD)$)
{
    set $redirect_https "${redirect_https}2";
}
if ($redirect_https = 12)
{
    rewrite ^(/.*)$ https://$host$1 permanent;
}

验证

最后来检查一下配置得对不对：https://www.geocerts.com/ssl_checker

扩展阅读

在 IIS 中部署 SSL

安装 SSL 证书遇到的一些问题

一、概述

    重定向常常和请求转发放在一起讨论（前者是两次不相关的请求，后者是一次请求服务器端转发），然而本文并不讨论两者的区别，而是HTTP 1.0规范和HTTP 1.1规范中关于重定向的区别，以及实际使用中的情况。

    重定向实际使用是一个响应码（301或302或303或307）和一个响应头location，当浏览器收到响应的时候check响应码是3xx，则会取出响应头中location对应的url（重定向中url的编码问题，请参看点击打开链接），然后将该url替换浏览器地址栏并发起另一次HTTP事务。

    关于301、302、303、307的区别，找不到好的文章，因此打算直撸HTTP 1.0规范和HTTP 1.1规范，结合一些实际的案例和tomcat实现，来说清楚这几个状态码的差异。

1. 百度https重定向

    如下图所示，原请求访问的是http://www.baidu.com，然后返回302和location=https://www.baidu.com，从http转到https。不过关于响应行中302状态码的描述存在争议，在下文中会详细讨论。

2. tomcat重定向源码

二、详细

    http 1.0规范中有2个重定向——301和302，在http 1.1规范中存在4个重定向——301、302、303和307，其中302是值得讨论讨论的。

1. http 1.0

301

    301状态码在HTTP 1.0和HTTP 1.1规范中均代表永久重定向，对于资源请求，原来的url和响应头中location的url而言，资源应该对应location中的url。对于post请求的重定向，还是需要用户确认之后才能重定向，并且应该以post方法发出重定向请求。

    关于post请求重定向用户确认的问题，实际上浏览器都没有实现；而且post请求的重定向应该发起post请求，这里浏览器也并不一定遵守，所以说HTTP规范的实现并未严格按照HTTP规范的语义。

    在301中资源对应的路径修改为location的url，在SEO中并未出现问题，但是在302中就出现了302劫持问题，请往下看。

302

    在http 1.0规范中，302表示临时重定向，location中的地址不应该被认为是资源路径，在后续的请求中应该继续使用原地址。

    规范：原请求是post，则不能自动进行重定向；原请求是get，可以自动重定向；

    实现：浏览器和服务器的实现并没有严格遵守HTTP中302的规范，服务器不加遵守的返回302，浏览器即便原请求是post也会自动重定向，导致规范和实现出现了二义性，由此衍生了一些问题，譬如302劫持，因此在HTTP 1.1中将302的规范细化成了303和307，希望以此来消除二义性。

    补充：302劫持——A站通过重定向到B站的资源xxoo，A站实际上什么都没做但是有一个比较友好的域名，web资源xxoo存在B站并由B站提供，但是B站的域名不那么友好，因此对搜索引擎而言，可能会保存A站的地址对应xxoo资源而不是B站，这就意味着B站出了资源版权、带宽、服务器的钱，但是用户通过搜索引擎搜索xxoo资源的时候出来的是A站，A站什么都没做却被索搜引擎广而告之用户，B站做了一切却不被用户知道，价值被A站窃取了。

2. http 1.1

301

    和http 1.0规范中保持一致，注意资源对应的路径应该是location中返回的url，而不再是原请求地址。

302

    在HTTP 1.1中，实际上302是不再推荐使用的，只是为了兼容而作保留。规范中再次重申只有当原请求是GET or HEAD方式的时候才能自动的重定向，为了消除HTTP 1.0中302的二义性，在HTTP 1.1中引入了303和307来细化HTTP 1.0中302的语义。

303

    在HTTP 1.0的时候，302的规范是原请求是post不可以自动重定向，但是服务器和浏览器的实现是运行重定向。

    把HTTP 1.0规范中302的规范和实现拆分开，分别赋予HTTP 1.1中303和307，因此在HTTP 1.1中，303继承了HTTP 1.0中302的实现（即原请求是post，也允许自动进行重定向，结果是无论原请求是get还是post，都可以自动进行重定向），而307则继承了HTTP 1.0中302的规范（即如果原请求是post，则不允许进行自动重定向，结果是post不重定向，get可以自动重定向）。

307

    在http 1.1规范中，307为临时重定向，注意划红线的部分，如果重定向307的原请求不是get或者head方法，那么浏览器一定不能自动的进行重定向，即便location有url，也应该忽略。

    也就是307继承了302在HTTP 1.0中的规范（303继承了302在HTTP 1.0中的实现）。

3. 小结

    在HTTP 1.0规范中，302的规范并没有被服务器和浏览器遵守，即规范和实现出现了二义性，因此在HTTP 1.1中，将302的规范和实现拆分成了303和307。

三、结论

    虽然在不同版本的http规范中对重定向赋予了不同的语义，但是因为使用历史和服务器实现等原因，在实际中并不一定安全按照http规范实现，因此我个人感觉上述讨论只是一个了解，在实际写代码中302还是继续用吧···

参考：

1. 《http 1.0规范》
2. 《http 1.1规范》

3. 博客：点击打开链接

附注：

    本文如有错漏，烦请不吝指正，谢谢！

经测试，.NET Framework 4.8 的 Cache.Insert() 已恢复正常。

安装 .NET Framework 4.7 后，不管项目有没有升级到 .NET Framework 4.7，使用 Cache.Insert() 添加的自动过期的缓存都不会过期了，可以使用 Cache.Add() 来解决！

使用 Cache.Insert() 例：

HttpRuntime.Cache.Insert(key, value, null, DateTime.Now.AddSeconds(5), Cache.NoSlidingExpiration);

改为使用 Cache.Add()：

HttpRuntime.Cache.Add(key, value, null, DateTime.Now.AddSeconds(5), Cache.NoSlidingExpiration, CacheItemPriority.Default, null);

如果 Cache 中已保存了具有相同 key 的项，则调用 Add 方法将不作任何更改。（Insert 方法则会覆盖该值）

完整测试代码：

public static DateTime DateTimeNow
{
    get
    {
        if (HttpRuntime.Cache["DateTimeNow"] == null)
        {
            HttpRuntime.Cache.Add("DateTimeNow", DateTime.Now, 
                null, DateTime.Now.AddSeconds(5), Cache.NoSlidingExpiration, 
                CacheItemPriority.Default, null);
        }
        return Convert.ToDateTime(HttpRuntime.Cache["DateTimeNow"]);
    }
}

在部分项目中（如 .NET Framework 4 项目中）发现上述改动仍不起作用，不会自动过期，那么可以采用以下方法：

方法一、可以记录将数据添加到 Cache 的时间，获取数据时判断该时间，超时则清除该 Cache 并重新赋值；

方法二、放弃缓存依赖，用定时器清除 Cache 数据。

本文不定时更新！

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）等。

Q： 带宽波形以几分钟为周期呈锯齿状波动是什么原因？

A： 该现象主要由防火墙流量管控机制与检测周期设置共同作用所致。防火墙基于预设的带宽阈值执行安全防护策略，当检测到流量峰值超过设定阈值时，将自动触发限流策略拒绝后续请求。待流量回落至安全阈值后，系统自动恢复服务访问权限。若防火墙的带宽采样检测周期设置过长（如以分钟为单位的检测间隔），将导致系统对实时流量变化的响应出现迟滞。这种周期性的检测机制会使带宽监控数据在阈值临界点附近呈现规律性的锯齿状波动特征。

优化建议：可通过调整防火墙的流量检测周期至更小时间粒度（如10-15秒），或采用动态流量整形策略，以实现更平滑的带宽控制效果。

补充说明：对于阿里云监控数据的调用，建议注意接口调用频率管控。高频调用云监控API接口将触发阿里云的API计费策略，可能产生额外的资源消耗成本。

其它案例

1. 某台 ECS 上的多个网站出现 502，查询到 CPU / 内存 / 带宽 都比平时高，但都未满。用 iftop 看到连接的一个远程 Redis 占用内网带宽非常高。尝试重启远程 Redis 未果。尝试重启 ECS 上的 nginx 未果。尝试重启 ECS 未果。进入 ECS 的宝塔面板，重启 PHP 有效。