Jackett性能优化实战指南让聚合搜索从40秒降到单索引器水平【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/JackettJackett 把多个种子追踪器聚合成一个 Torznab API供 Sonarr、Radarr 这类媒体管理工具统一调用。索引器配得越多一次「all」聚合搜索要并发的站点就越多于是搜索超时、缓存不命中、内存一路涨就接踵而来。这篇文章按「症状自查 → 分级方案 → 效果验证」来走每个改法都给出验证方式你改完能立刻确认是否生效。 症状自查先判断你卡在哪一层动手前先对号入座不同症状对应不同的修法别一上来就改缓存。同一个关键词反复搜第二次还是慢—— 缓存没命中。打开 Debug 日志如果搜两次都看不到CACHE Search ... CacheHit: true说明结果根本没被存下来测试查询、报错查询都不进缓存见 CacheService.cs 开头注释。内存只涨不跌—— 缓存是纯内存实现按「索引器 × 查询」堆积超过上限才会淘汰旧条目。涨到某个平台期就稳住是正常的如果持续增长不平稳检查第 2 层的参数。搜索偶尔整批超时—— 聚合搜索整体硬编码了40 秒总超时BaseMetaIndexer.cs 第 93 行任何一个慢索引器都会拖到最后一刻才返回。改了索引器配置后结果一直不更新—— 通常是缓存 TTL 太长正常情况下改配置会自动清掉该索引器的缓存如果没生效说明改的不是这个索引器。单个索引器单独搜都慢—— 这是网络或代理问题跟缓存无关直接跳到第 3 层。 第 1 层立即可做——只改一个设置确认 Cache enabled 已勾选TTL 设为 2100-3600 秒原因Jackett 把每个「索引器 查询」的结果按 SHA256 哈希存在内存里命中就直接返回不再请求站点。TTL 控制结果存活多久代码里的默认值是2100 秒注释写明这是为了兼顾 Sonarr15 分钟和 Radarr60 分钟的轮询节奏ServerConfig.cs 第 22 行。操作进 Settings 页面确认Cache enabled勾选把Cache TTL设为2100-3600 秒即 35-60 分钟。媒体类追踪器更新频率低偏长一点收益更大。验证把日志级别开到 Debug连搜两次相同关键词第二次应出现CACHE Search / ... / CacheHit: true。命中率上来后同一查询的响应会从几秒降到毫秒级。别用「all」聚合源改成按索引器的 feed原因Jackett 的all元索引器会把所有已配置索引器全部并发查询一次。你配 30 个索引器Sonarr 每 15 分钟轮询一次等于每 15 分钟对 30 个站点发一轮请求——这是响应慢和站点限流的主因。操作在 Sonarr/Radarr 的自定义索引器里把 feed URL 从?tsearch...指向 all改成对应具体索引器的 URL/api/v2.0/{索引器ID}/...。Jackett 还内置了按类型和标签的过滤源比如只查 public、private 或某个 tag比 all 少查一半以上站点同样在 BaseMetaIndexer.cs 里以FilterIndexer实现。验证改完后看日志一次搜索应该只出现你指定的那几行索引器请求而不是全部同时聚合源的 40 秒超时风险也随之消失。⚙️ 第 2 层配置层——需要理解参数再动手Cache max results per indexer 设多少默认 1000区间 500-2000原因每个索引器的缓存条目有数量上限超了就淘汰最旧的查询。这个值直接决定内存占用和「缓存够不够用」的平衡。操作内存紧张Jackett 和媒体库共用一台机器就调到500-1000内存充裕、索引器查询种类多分类多、关键词多就放到1000-2000即每个索引器最多缓存 500 到 2000 条结果。注意是「每个索引器」总内存 ≈ 值 × 索引器数 × 单条大小。验证调整前后各观察一天任务管理器或top里 Jackett 进程内存应稳定在新平台期Debug 日志里若频繁出现Pruned queries计数上涨说明上限设小了旧查询总被挤掉命中率会受损。搜索结果不对时清单个索引器缓存而不是全清原因改某个索引器的配置会自动触发CleanIndexerCache只清它自己但如果你怀疑某个索引器缓存了脏数据比如站点结构变了需要手动清它。操作在已配置索引器列表里对该索引器执行清理缓存操作然后重新 Test 一次。Test 查询本身不进缓存query.IsTest直接跳过所以不会污染缓存。验证清理后立刻发一次真实搜索日志应显示该索引器走了实时请求且无CacheHit下一轮再搜同一词才出现CacheHit: true。不用 IMDB 回退就别填 OMDB Key原因填了 OMDB Key 后聚合搜索会额外走 IMDB 解析做回退查询和结果过滤OmdbResolver见 IndexerManagerService.cs 的GetStrategyProviders每次聚合搜索都多出外部请求纯拖慢速度。操作不依赖 IMDB 匹配媒体就留空。验证日志里不再出现 OMDB 相关的外部请求记录聚合搜索整体耗时下降。 第 3 层系统层——动环境和部署索引器数量是性能天花板删掉不用的配置Jackett 没有「禁用」开关未配置的索引器本来就不会被查询CanHandleQuery会先检查是否已配置所以停用一个索引器的唯一干净办法就是删掉它的配置。操作在 Configured Indexers 页面删掉长期不用、或常年报错的索引器。每删一个all搜索的并发请求就少一条。验证重启后启动日志里Loaded X indexers in total的数量应减少all源的搜索耗时按索引器数量近似线性下降。代理与并发每站点 20 条连接是写死的原因HTTP 客户端对每个站点固定MaxConnectionsPerServer 20HttpWebClient.cs 第 90 行单请求默认超时100 秒。走代理时每个请求多一跳索引器多时 20 条连接很容易被慢站点占满后面的请求排队。操作能直连的索引器就别走代理必须走代理的把代理配到最稳的服务商上别贪便宜的慢节点。连接数和请求超时都是代码固定值改不了——这层能优化的只有网络质量本身。验证日志里单个索引器的请求耗时应稳定在几秒内若普遍逼近 100 秒或出现RequestTimeout问题在代理出口不在 Jackett。别指望定期重启「释放内存」缓存只存在内存里重启等于把整个缓存清空——之后所有查询都要重新打到站点上等于重启后一段时间内性能最差。Jackett 的缓存在 TTL 和数量上限双重保护下会自我淘汰不需要外部干预。真正常驻内存过高回第 2 层调Cache max results per indexer才对。 避坑什么时候不该动TTL 别拉到数小时你改过某个索引器配置后旧结果会一直撑到 TTL 过期虽然改配置会清对应缓存但站点侧数据本身也在变太久会搜到过期信息。别直接关 Cache enabled每次查询都裸奔打站点轻则慢重则被追踪器限流封 IP性能不升反降。别靠「等它加载」解决慢聚合搜索 40 秒总超时是硬编码等再久也不会多等慢就减少参与搜索的索引器。✅ 效果验证三步确认优化生效开 Debug 日志确认重复查询出现CacheHit: true——缓存链路通了。分别搜一次all源和单个索引器源记录耗时。单索引器源应在数秒内返回all源耗时若仍逼近 40 秒说明还有慢索引器在拖后腿回到第 3 层删配置。观察一周内存曲线应稳定在平台期配合启动日志的Loaded X indexers in total确认索引器数量符合预期。收尾清单确认 Cache enabled → TTL 设 2100-3600 秒 → 媒体工具的 feed 从 all 改为单索引器源 → 每索引器结果上限按内存设 500-2000 → Debug 日志确认 CacheHit: true。你的all聚合搜索现在大概要跑多久如果已经经常撞 40 秒上限最该先删掉的是哪几个索引器【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Jackett性能优化实战指南：让聚合搜索从40秒降到单索引器水平
Jackett性能优化实战指南让聚合搜索从40秒降到单索引器水平【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/JackettJackett 把多个种子追踪器聚合成一个 Torznab API供 Sonarr、Radarr 这类媒体管理工具统一调用。索引器配得越多一次「all」聚合搜索要并发的站点就越多于是搜索超时、缓存不命中、内存一路涨就接踵而来。这篇文章按「症状自查 → 分级方案 → 效果验证」来走每个改法都给出验证方式你改完能立刻确认是否生效。 症状自查先判断你卡在哪一层动手前先对号入座不同症状对应不同的修法别一上来就改缓存。同一个关键词反复搜第二次还是慢—— 缓存没命中。打开 Debug 日志如果搜两次都看不到CACHE Search ... CacheHit: true说明结果根本没被存下来测试查询、报错查询都不进缓存见 CacheService.cs 开头注释。内存只涨不跌—— 缓存是纯内存实现按「索引器 × 查询」堆积超过上限才会淘汰旧条目。涨到某个平台期就稳住是正常的如果持续增长不平稳检查第 2 层的参数。搜索偶尔整批超时—— 聚合搜索整体硬编码了40 秒总超时BaseMetaIndexer.cs 第 93 行任何一个慢索引器都会拖到最后一刻才返回。改了索引器配置后结果一直不更新—— 通常是缓存 TTL 太长正常情况下改配置会自动清掉该索引器的缓存如果没生效说明改的不是这个索引器。单个索引器单独搜都慢—— 这是网络或代理问题跟缓存无关直接跳到第 3 层。 第 1 层立即可做——只改一个设置确认 Cache enabled 已勾选TTL 设为 2100-3600 秒原因Jackett 把每个「索引器 查询」的结果按 SHA256 哈希存在内存里命中就直接返回不再请求站点。TTL 控制结果存活多久代码里的默认值是2100 秒注释写明这是为了兼顾 Sonarr15 分钟和 Radarr60 分钟的轮询节奏ServerConfig.cs 第 22 行。操作进 Settings 页面确认Cache enabled勾选把Cache TTL设为2100-3600 秒即 35-60 分钟。媒体类追踪器更新频率低偏长一点收益更大。验证把日志级别开到 Debug连搜两次相同关键词第二次应出现CACHE Search / ... / CacheHit: true。命中率上来后同一查询的响应会从几秒降到毫秒级。别用「all」聚合源改成按索引器的 feed原因Jackett 的all元索引器会把所有已配置索引器全部并发查询一次。你配 30 个索引器Sonarr 每 15 分钟轮询一次等于每 15 分钟对 30 个站点发一轮请求——这是响应慢和站点限流的主因。操作在 Sonarr/Radarr 的自定义索引器里把 feed URL 从?tsearch...指向 all改成对应具体索引器的 URL/api/v2.0/{索引器ID}/...。Jackett 还内置了按类型和标签的过滤源比如只查 public、private 或某个 tag比 all 少查一半以上站点同样在 BaseMetaIndexer.cs 里以FilterIndexer实现。验证改完后看日志一次搜索应该只出现你指定的那几行索引器请求而不是全部同时聚合源的 40 秒超时风险也随之消失。⚙️ 第 2 层配置层——需要理解参数再动手Cache max results per indexer 设多少默认 1000区间 500-2000原因每个索引器的缓存条目有数量上限超了就淘汰最旧的查询。这个值直接决定内存占用和「缓存够不够用」的平衡。操作内存紧张Jackett 和媒体库共用一台机器就调到500-1000内存充裕、索引器查询种类多分类多、关键词多就放到1000-2000即每个索引器最多缓存 500 到 2000 条结果。注意是「每个索引器」总内存 ≈ 值 × 索引器数 × 单条大小。验证调整前后各观察一天任务管理器或top里 Jackett 进程内存应稳定在新平台期Debug 日志里若频繁出现Pruned queries计数上涨说明上限设小了旧查询总被挤掉命中率会受损。搜索结果不对时清单个索引器缓存而不是全清原因改某个索引器的配置会自动触发CleanIndexerCache只清它自己但如果你怀疑某个索引器缓存了脏数据比如站点结构变了需要手动清它。操作在已配置索引器列表里对该索引器执行清理缓存操作然后重新 Test 一次。Test 查询本身不进缓存query.IsTest直接跳过所以不会污染缓存。验证清理后立刻发一次真实搜索日志应显示该索引器走了实时请求且无CacheHit下一轮再搜同一词才出现CacheHit: true。不用 IMDB 回退就别填 OMDB Key原因填了 OMDB Key 后聚合搜索会额外走 IMDB 解析做回退查询和结果过滤OmdbResolver见 IndexerManagerService.cs 的GetStrategyProviders每次聚合搜索都多出外部请求纯拖慢速度。操作不依赖 IMDB 匹配媒体就留空。验证日志里不再出现 OMDB 相关的外部请求记录聚合搜索整体耗时下降。 第 3 层系统层——动环境和部署索引器数量是性能天花板删掉不用的配置Jackett 没有「禁用」开关未配置的索引器本来就不会被查询CanHandleQuery会先检查是否已配置所以停用一个索引器的唯一干净办法就是删掉它的配置。操作在 Configured Indexers 页面删掉长期不用、或常年报错的索引器。每删一个all搜索的并发请求就少一条。验证重启后启动日志里Loaded X indexers in total的数量应减少all源的搜索耗时按索引器数量近似线性下降。代理与并发每站点 20 条连接是写死的原因HTTP 客户端对每个站点固定MaxConnectionsPerServer 20HttpWebClient.cs 第 90 行单请求默认超时100 秒。走代理时每个请求多一跳索引器多时 20 条连接很容易被慢站点占满后面的请求排队。操作能直连的索引器就别走代理必须走代理的把代理配到最稳的服务商上别贪便宜的慢节点。连接数和请求超时都是代码固定值改不了——这层能优化的只有网络质量本身。验证日志里单个索引器的请求耗时应稳定在几秒内若普遍逼近 100 秒或出现RequestTimeout问题在代理出口不在 Jackett。别指望定期重启「释放内存」缓存只存在内存里重启等于把整个缓存清空——之后所有查询都要重新打到站点上等于重启后一段时间内性能最差。Jackett 的缓存在 TTL 和数量上限双重保护下会自我淘汰不需要外部干预。真正常驻内存过高回第 2 层调Cache max results per indexer才对。 避坑什么时候不该动TTL 别拉到数小时你改过某个索引器配置后旧结果会一直撑到 TTL 过期虽然改配置会清对应缓存但站点侧数据本身也在变太久会搜到过期信息。别直接关 Cache enabled每次查询都裸奔打站点轻则慢重则被追踪器限流封 IP性能不升反降。别靠「等它加载」解决慢聚合搜索 40 秒总超时是硬编码等再久也不会多等慢就减少参与搜索的索引器。✅ 效果验证三步确认优化生效开 Debug 日志确认重复查询出现CacheHit: true——缓存链路通了。分别搜一次all源和单个索引器源记录耗时。单索引器源应在数秒内返回all源耗时若仍逼近 40 秒说明还有慢索引器在拖后腿回到第 3 层删配置。观察一周内存曲线应稳定在平台期配合启动日志的Loaded X indexers in total确认索引器数量符合预期。收尾清单确认 Cache enabled → TTL 设 2100-3600 秒 → 媒体工具的 feed 从 all 改为单索引器源 → 每索引器结果上限按内存设 500-2000 → Debug 日志确认 CacheHit: true。你的all聚合搜索现在大概要跑多久如果已经经常撞 40 秒上限最该先删掉的是哪几个索引器【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考