•
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