BTN & Tracker 服务器宕机情况说明

[Ghost-chu]

有的朋友可能已经注意到了，自 12 月以来，BTN 和 Tracker 服务器频频宕机，特别是近几周几乎无法使用，数据提交也受到了影响。

尽管我们全力投入维护服务运行，但仍然无法解决目前出现的性能瓶颈。

Sparkle 包括 BTN 和 Tracker 在内都在同一台服务器上运行，情况介绍如下：

BTN 现状

Sparkle BTN 目前有超过 2000 名注册用户，有大量的数据提交。目前数据库中存储封禁记录超过 17,664,667 条；而 Peer 详情记录仅仅自 11 月 19 日以来就超过了 78,136,402 条。

为了计算反吸血，Sparkle BTN 需要定时在 PostgreSQL 数据库程序上运行多个复杂查询，如下面这里几个：

https://gist.github.com/Ghost-chu/10f01aab255bce407327e8e2e21cc8cf

起初大约运行 ~15 秒就能够查询完成，但随着数据量增长，overdownload 的查询已经超过了 500 秒。而 Sparkle BTN 显然要运行多个查询，这就导致定时任务一旦开始，则可能需要执行超过一个小时，而在此期间 PostgreSQL 耗尽所有硬盘 I/O 和 CPU 资源，并导致在此期间无法提供任何服务。

Tracker 现状

Tracker 曾经属于 Sparkle 的一部分，但由于 Sparkle 的负载日益增加，由 @Gaojianli 使用 golang 单独编写了一个高性能的 Tracker 服务器 —— Trunker。目前在晚高峰承载超过 70 万的 Peers 和超过 50 万的 Torrent 数据，每秒请求数（QPS）可达 1200+。

目前 Trunker 处于早期活跃开发阶段，因此还有不少 BUG。为了简化开发，暂时采取手动线上编译和手动启用，由于可能崩溃，在夜间崩溃时就没有人手动重新启动它了。并且它显然也不在状态监测列表中，因此悄悄的在角落里挂掉之后我们也毫不知情。

除此之外，巨大的并发同时也导致服务器上部署的 Tengine 超负荷运行，尽管使用了 Unix Domain Socket 等减少了内部网络流量，但仍然将服务器的软中断 CPU 耗时打到了 20%+，本就不足的 CPU 资源变得更加雪上加霜。偶尔甚至会撑爆目前系统的链接跟踪表。

下一步计划

清理旧数据

目前 banhistory 数据表从不清理，而 peer_history 表则只保留最近 14 天的数据。

我们通过修改 TimescaleDB 的数据保留设置，将 banhistory 的数据保留在最近 6 个月，而 peer_history 只保留最近 7 天，以暂时缓解目前的燃眉之急。

同时暂停客户端发现服务，我们发现随着发现的客户端数量成倍增加，这项服务也给数据库带去的沉重的负担。后续考虑这个脏活丢给 Redis 或者别的什么的干。

其它的各类系统日志表也均已设置了合理的数据保留规则，但考虑这些日志表几乎从不查询。

有关 Tracker 的压力问题，我们在 CloudFlare 的 WAF 上新增了一些规则，过滤拦截一些不受欢迎的客户端（迅雷，BTSP 等）暂时降低压力，同时设置了单 IP QPS 上限。目前这个 QPS 的限制是 10 秒内最多请求 100 次 Tracker。

希望这个改动能够解决晚上 7-9 点高峰期间，出现超过 1500 的并发请求尖峰的问题。

当性能问题得到解决后，这些限制也会逐渐放开。

读写分离

计划增加一台服务器，与主数据库做主从同步。此类耗时查询移动到从库上执行，避免影响主库的服务。

不过由于数据、业务的复杂性和巨大的数据文件，可能需要一段时间才能完成这个工作。

改进数据结构

在 Sparkle BTN 设计之初我们从未料想过这个服务能够发展的如此之快和之大，许多查询并不高效。尽管这个耗时会更久，但从长远角度来看，改进数据结构是非常必要的。