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