企业官网建设流程全解析

Jackett 性能优化：四步把种子搜索压到 10 秒内

【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett

Jackett 把各类种子追踪器统一成 Torznab API，一次搜索会向所有已启用索引器并发发请求。如果你的搜索要转十几秒、进程内存越跑越高、缓存结果半天不刷新，按下面这套"体检流程"先定位再改配置即可：做完后同一条搜索应从两位数秒级回到个位数秒级，且不再无节制地重复请求站点。

第一步：先定位——你的慢到底卡在哪

别猜，做三个测量动作：

1. 打开 Manual Search 页跑一个常用关键词，读结果区上方的统计行。Jackett 会按索引器列出命中数和耗时，例如 "The Pirate Bay (6) [422ms]"。单站超过 3 秒的就是嫌疑对象；长期 0 命中的则是另一类问题。
2. 在 Configured Indexers 列表逐个点 Test。日志里会记录每次测试的毫秒数，用它和全量搜索对比：单点慢是索引器自身问题，集体慢是网络或并发问题。
3. 点 View logs，筛出 timeout 和异常记录，看慢的索引器是否集中在少数几个站点。

对照结论：单个索引器慢→看下面"转圈/超时"；整体慢且内存上涨→看"内存"；结果不刷新→看"缓存"。

第二步：按"症状"开方

搜索一直转圈 / 超时

现象：一次搜索拖十几秒，或某个索引器永远是 0 命中。

原因：Jackett 对所有启用索引器并发查询，整体返回时间取决于最慢的那个站点。塞了二三十个索引器、其中一半宕机或被限速，平均延迟必然被拖垮；长关键词加大范围分类还会让页面解析变重。

操作：

• 在 Configured Indexers 页把超时、报错的索引器 Test 一遍，确认有问题的就禁用（保留配置，不要删除）。
• 搜索时用 Tracker 过滤器只圈定 3-5 个常用站点，配合 Category 缩小范围，别每次全量打。
• 私有站出现频繁限流提示时，检查你的查询频率是否超出站点限制——那是账号配额问题，不是机器性能问题。

预期：砍掉最差的 2-3 个索引器后，搜索总耗时通常从 10 秒级降到 3 秒内，结果上方统计行的毫秒数可直接验证。

内存越跑越高

现象：运行几天后进程常驻内存持续上涨，搜索也跟着变慢。

原因：搜索结果保存在内存中，CacheService.cs 用两道闸门控制规模——TTL 过期清理和"每索引器最大结果数"。这两项配得太大、又长期跑大关键词搜索，内存占用会随缓存条目线性增长。默认值见 ServerConfig.cs：TTL 2100 秒、每索引器 1000 条。

操作：

• Cache TTL 设在 2100-3600 秒之间，兼顾新鲜度与站点压力。
• Cache max results per indexer：4GB 以内内存的机器保持 1000；8GB 以上可放宽到 2000。
• 改完配置后重启一次 Jackett 进程——缓存在内存里，重启即清空已累积的旧结果。

预期：重启后内存回落到几百 MB 基线，之后按周观察，两道闸门生效的情况下不应出现持续爬升。

结果半天不更新 / 缓存不生效

现象：站点上已出现的资源，Jackett 迟迟搜不到；或改完索引器配置后仍返回旧结果。

原因：一是 TTL 未到，命中缓存直接返回旧数据，这是设计行为而非故障；二是缓存键是查询内容（关键词、分类等）的哈希，查询条件完全不变时即使过了 TTL 也是重新拉取，看起来"没变"属于正常。真正异常的情况是：绕过界面直接改了索引器配置文件，Jackett 没有机会触发对该索引器的缓存清理。

操作：

• 追求结果新鲜度就把 TTL 压到 1800-2100 秒；接受稍旧结果则放到 3600 秒。
• 改配置一律走界面保存/测试流程，它会自动清理对应索引器的缓存；直接编辑过文件的，重启一次 Jackett。
• 代理或账号信息有变动时，走界面修改（改代理会自动清全部缓存），然后点 View cached releases 核对时间戳。

预期：结果发布时间与站点更新节奏一致，缓存页面显示的时间戳能证明数据确实刷新过。

第三步：一份能直接抄的参数基线

第四步：长效运维——监控与定期巡检

• 每周一次 View logs：扫 timeout 与异常。同一站点集中超时，说明它在限速或宕机，直接禁用。
• 每周记录一次进程内存（Linux 用 top，Windows 用任务管理器）。持续超过 2GB 且涨不回去时，先核对每索引器结果上限是否被调高过。
• 每月对索引器列表做一次 Test All，把超过 3 秒的记下来，按使用频率决定去留。
• 把搜索页顶部那行按索引器的耗时当作前后对照指标：每次改完配置跑同一条查询，毫秒数是否下降一目了然。

先从第一步的三个测量动作和第三步的基线表开始改；改完用搜索结果里的耗时行验收，数字降下来才算优化到位。

【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett