Jackett 性能优化:四步把种子搜索压到 10 秒内
Jackett 性能优化四步把种子搜索压到 10 秒内【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/JackettJackett 把各类种子追踪器统一成 Torznab API一次搜索会向所有已启用索引器并发发请求。如果你的搜索要转十几秒、进程内存越跑越高、缓存结果半天不刷新按下面这套体检流程先定位再改配置即可做完后同一条搜索应从两位数秒级回到个位数秒级且不再无节制地重复请求站点。第一步先定位——你的慢到底卡在哪别猜做三个测量动作打开 Manual Search 页跑一个常用关键词读结果区上方的统计行。Jackett 会按索引器列出命中数和耗时例如 The Pirate Bay (6) [422ms]。单站超过 3 秒的就是嫌疑对象长期 0 命中的则是另一类问题。在 Configured Indexers 列表逐个点 Test。日志里会记录每次测试的毫秒数用它和全量搜索对比单点慢是索引器自身问题集体慢是网络或并发问题。点 View logs筛出 timeout 和异常记录看慢的索引器是否集中在少数几个站点。对照结论单个索引器慢→看下面转圈/超时整体慢且内存上涨→看内存结果不刷新→看缓存。第二步按症状开方搜索一直转圈 / 超时现象一次搜索拖十几秒或某个索引器永远是 0 命中。原因Jackett 对所有启用索引器并发查询整体返回时间取决于最慢的那个站点。塞了二三十个索引器、其中一半宕机或被限速平均延迟必然被拖垮长关键词加大范围分类还会让页面解析变重。操作在 Configured Indexers 页把超时、报错的索引器 Test 一遍确认有问题的就禁用保留配置不要删除。搜索时用 Tracker 过滤器只圈定 3-5 个常用站点配合 Category 缩小范围别每次全量打。私有站出现频繁限流提示时检查你的查询频率是否超出站点限制——那是账号配额问题不是机器性能问题。预期砍掉最差的 2-3 个索引器后搜索总耗时通常从 10 秒级降到 3 秒内结果上方统计行的毫秒数可直接验证。内存越跑越高现象运行几天后进程常驻内存持续上涨搜索也跟着变慢。原因搜索结果保存在内存中CacheService.cs 用两道闸门控制规模——TTL 过期清理和每索引器最大结果数。这两项配得太大、又长期跑大关键词搜索内存占用会随缓存条目线性增长。默认值见 ServerConfig.csTTL 2100 秒、每索引器 1000 条。操作Cache TTL 设在 2100-3600 秒之间兼顾新鲜度与站点压力。Cache max results per indexer4GB 以内内存的机器保持 10008GB 以上可放宽到 2000。改完配置后重启一次 Jackett 进程——缓存在内存里重启即清空已累积的旧结果。预期重启后内存回落到几百 MB 基线之后按周观察两道闸门生效的情况下不应出现持续爬升。结果半天不更新 / 缓存不生效现象站点上已出现的资源Jackett 迟迟搜不到或改完索引器配置后仍返回旧结果。原因一是 TTL 未到命中缓存直接返回旧数据这是设计行为而非故障二是缓存键是查询内容关键词、分类等的哈希查询条件完全不变时即使过了 TTL 也是重新拉取看起来没变属于正常。真正异常的情况是绕过界面直接改了索引器配置文件Jackett 没有机会触发对该索引器的缓存清理。操作追求结果新鲜度就把 TTL 压到 1800-2100 秒接受稍旧结果则放到 3600 秒。改配置一律走界面保存/测试流程它会自动清理对应索引器的缓存直接编辑过文件的重启一次 Jackett。代理或账号信息有变动时走界面修改改代理会自动清全部缓存然后点 View cached releases 核对时间戳。预期结果发布时间与站点更新节奏一致缓存页面显示的时间戳能证明数据确实刷新过。第三步一份能直接抄的参数基线配置项默认值建议值说明Cache enabled开开关掉则每次搜索都打向站点延迟和配额双输Cache TTL秒21001800-3600越短越新鲜但对站点请求越多Cache max results per indexer10001000-2000仅在内存 8GB 以上时考虑上调启用索引器数量不限5-10 个用不到的禁用而非删除每次搜索范围全部索引器Tracker 过滤器圈定搜索页直接生效第四步长效运维——监控与定期巡检每周一次 View logs扫 timeout 与异常。同一站点集中超时说明它在限速或宕机直接禁用。每周记录一次进程内存Linux 用 topWindows 用任务管理器。持续超过 2GB 且涨不回去时先核对每索引器结果上限是否被调高过。每月对索引器列表做一次 Test All把超过 3 秒的记下来按使用频率决定去留。把搜索页顶部那行按索引器的耗时当作前后对照指标每次改完配置跑同一条查询毫秒数是否下降一目了然。先从第一步的三个测量动作和第三步的基线表开始改改完用搜索结果里的耗时行验收数字降下来才算优化到位。【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考