企业官网建设流程全解析

Jackett 性能优化：4 步诊断法降低搜索延迟与内存占用

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

Jackett 把各追踪器的搜索统一成 Torznab/RSS API，是 Sonarr、Radarr 等工具的后端；索引器加多了之后，Jackett 性能优化就成了刚需——同一个词搜一遍比上一遍慢，进程内存只涨不跌，就是最典型的两个信号。本文面向已在生产环境使用 Jackett 的读者，按"量化症状 → 定位瓶颈 → 按成本排序执行 → 验证"的顺序展开，每一步都给出可自查的判断标准。

搜索慢到什么程度算慢：先建立三个基准

没有基准就无法判断优化是否生效，先花十分钟记录基线：

• 总响应时长与单追踪器耗时：手动搜索（Manual Search）页面在结果列表上方会显示每个追踪器的命中数与耗时（如 "Internet Archive (11) [523ms]"），记下整次搜索的总时长和其中最慢的那一个。
• 单索引器延迟：在索引器列表对每个条目点 Test，日志会记录该次测试搜索的毫秒数，可据此排出"最慢索引器榜"。
• 内存：用 top（Linux）或任务管理器（Windows）记录 Jackett 进程在工作状态和一轮搜索后的常驻内存各一个数值。

经验判断线：相同关键词的第二次搜索与第一次耗时接近，或总时长随索引器数量近似翻倍，或空闲内存持续上升不回落——满足任意一条，即进入下一步诊断。

手动搜索界面：结果上方列出各追踪器命中数与耗时

瓶颈通常出在哪：按三个根源归类

根源一：并发查询量。查询 "all" 聚合索引器时，Jackett 会对全部已配置索引器并发发起真实请求，每个索引器还持有独立的网络客户端实例（见 src/Jackett.Common/Services/IndexerManagerService.cs）。结论：总耗时由最慢的那个索引器决定，索引器数量决定资源竞争程度。

根源二：缓存命中率。搜索结果缓存在内存中，按查询条件的哈希作键（实现见 src/Jackett.Common/Services/CacheService.cs）。要点：关键词、分类、参数任一不同就算不同的键；超 TTL 的结果会被清掉；Test 请求和出错的结果不写缓存。所以"换了个大小写再搜一次"必然 miss。

根源三：常驻内存。每个索引器的缓存条数受"每索引器最大结果数"上限约束，超限后最旧的查询结果先被淘汰。内存上限近似等于"索引器数量 × 每索引器上限 × 单条结果大小"，索引器越多，基数越大。

按成本从低到高执行优化

什么时候该禁用一个索引器

现象：某索引器长期占据"最慢榜"且你很少用它。原因：它拖累整次并发搜索，还占用一份缓存额度。动作：在 Configured Indexers 页面用 Actions 列的删除图标移除该索引器的配置——Jackett 没有单独的"禁用"开关，删除即等效禁用，需要时可随时重新添加配置。预期效果：总搜索时长回落到剩余最慢索引器的水平，结果上方的耗时列表变短。

Configured Indexers 页面：Actions 列提供测试、编辑与删除

分组是"禁用"的替代方案：Jackett 内置 "all" 聚合索引器，以及 public、private、semi-public 和基于标签的过滤索引器。API 调用时改为查询这些过滤入口，只命中相关组；手动搜索时则用 Tracker、Category、Type 下拉框缩小范围。效果同样是减少每次搜索的并发请求数。

缓存 TTL 设多少合适

设置页缓存区域：启用开关、TTL 与每索引器上限

现象：相同关键词反复搜索仍然每次都很慢。原因：TTL 过短，缓存频繁过期，等于没开缓存。动作：在设置页确认 "Cache enabled" 已勾选（默认开启），再调整 "Cache TTL (seconds)"。默认值 2100 秒（35 分钟）是源码中对各 arr 轮询间隔的折中（见 src/Jackett.Common/Models/Config/ServerConfig.cs）。取舍：调短（如 900）让手动查看新资源更及时，但 miss 率上升；调长（如 3600）提高命中率，代价是手动搜索看到的新结果偏少。以 arr 自动轮询为主维持 2100，以手动搜索为主可上调到 3600。

每索引器缓存条数上限设多少

现象：内存随使用时间缓慢爬升。原因：上限偏大，各索引器长期持有接近满额的结果集。动作：调整 "Cache max results per indexer"，默认 1000。低频手动搜索场景 500–1000 足够；使用频率高、关键词组合多时放宽到 1000–2000，否则频繁淘汰旧结果反而增加回源请求。该参数与 TTL 配合决定内存峰值，请按你的内存大小和索引器数量调整：索引器超过二十个时，优先压这条数而不是调 TTL。

内存建议与重启间隔怎么定

这是成本最高、收益最弱的一档，前两步做完再做。Jackett 缓存全部驻留内存，给宿主机至少 2GB 可用内存是前提；若与多个 arr 共跑在小内存机器上，回到上一步压上限。定期重启（每周一次即可，Linux 用 crontab、Windows 用任务计划程序）能重置缓存、让常驻内存回到起点。注意：重启只是把内存拉回基线，如果之后仍缓慢爬升，说明缓存参数仍偏大，而不是需要更频繁重启。预期效果：空闲内存回落到刚启动时的水平，且回落后的爬升斜率不变。

验证：对比哪些指标、观察多久、什么信号说明没生效

对比三个指标：① 相同关键词的总搜索时长与最慢单追踪器耗时；② 进程空闲与搜索后的常驻内存；③ 开启 "Enhanced logging" 后日志中的 CacheHit 字段（缓存命中为 true/false）。

观察时长：至少 24 小时，且必须覆盖一个完整 TTL 周期，否则短周期内的 miss 不代表稳态。

未生效的信号对照：第二次搜索与第一次一样慢 → 缓存未命中，检查缓存开关与查询参数是否每次都被改动；内存持续爬升 → 每索引器上限偏大；始终只有某一个追踪器慢 → 瓶颈在该追踪器自身，属于 Jackett 之外的问题。日常排查用设置页的 "View logs" 看有无集中的错误与超时记录。

边界说明

本文覆盖的是 Jackett 自身开销：并发查询量、缓存命中与常驻内存。它优化不了三类问题：追踪器站本身的响应速度、网络与代理链路质量、以及第三方工具的大规模并发拉取。优化的上限是 Jackett 自身开销趋近于零，剩下的时长就是追踪器的响应时间；若验证后剩余时长都集中在某一两个追踪器上，该去解决的是站点侧问题，而不是继续调 Jackett。

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