月度归档： 2015年3月

3月12日21时14分至21时35分，USTC Blog 服务和 freeshell 控制面板无法访问。我们对本次故障给您带来的不便深表歉意。

故障原因是数据库连接数最大限制过低（151 个），连接数达到最大限制后无法建立新数据库连接。需要在 MySQL 配置文件 /etc/mysql/my.cnf 中增大 max_connections。

修复方法是依次重启 mysql 服务和 php-sandbox 服务。由于 mysql 连接数满，sudo service mysql restart 会失败，因而 monit 在发现数据库无法连接后，尝试自动重启 mysql 失败了；每分钟监控 blog 首页 HTTP 状态并重启相关服务的脚本，由于也是使用 service mysql restart，同样没有奏效。最后 左格非（Alkaid）kill 掉了 mysql 进程，再启动 mysql 服务，才算活过来。

造成大量数据库连接的可能是来自北京某数据中心的 Web 扫描，在21时的前5分钟，伪装成 OS X 10.10 上的 Safari 浏览器，以每秒数十个请求的速度扫描 kekao.ustc.edu.cn 的某些敏感路径。21时03分，扫描到 phpmyadmin 目录（数据库管理工具），遂以全速暴力尝试密码，但估计没有破解出密码。由于 nginx 每 IP 每秒 50 次 HTTP 请求的安全限制，每秒尝试密码的次数接近 50 次。

我们使用 ab 重试了这个尝试密码的过程，每秒几乎恰好涌入 50 个请求，不过数据库连接数一直稳定在 21～23（php-fpm 的线程数，每个线程一个持久数据库连接），没有出现异常。从服务器监控看到，服务中断之前的10分钟出现了负载高峰，而我们模拟的压力测试没有造成负载高峰。因此大量数据库连接的罪魁祸首有可能仍然藏在幕后。

     66 [12/Mar/2015 20 56
     33 [12/Mar/2015 20 57
     26 [12/Mar/2015 20 58
     70 [12/Mar/2015 20 59
    650 [12/Mar/2015 21 00
   3490 [12/Mar/2015 21 01
   2399 [12/Mar/2015 21 02
   3223 [12/Mar/2015 21 03
   5315 [12/Mar/2015 21 04
     74 [12/Mar/2015 21 05
     32 [12/Mar/2015 21 06
     82 [12/Mar/2015 21 07
     22 [12/Mar/2015 21 08
     60 [12/Mar/2015 21 09
    104 [12/Mar/2015 21 10
     50 [12/Mar/2015 21 11
     88 [12/Mar/2015 21 12
     27 [12/Mar/2015 21 13
     98 [12/Mar/2015 21 14