Jackett 性能优化全记录从缓存调参到索引器瘦身【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett实例上配置的索引器攒到 25 个以后Jackett 性能优化的问题就变得很直观走「all」索引器搜一次从 2 秒涨到 8 秒Radarr 的周期扫描也开始拖后。这不是单点故障是缓存参数、索引器规模、搜索习惯三者叠加的结果。下面是我在一台老实例上排障时走的路径先定位瓶颈再动参数。 先诊断再开药怎么找到瓶颈诊断占 Jackett 性能优化的一半别急着改配置先看瓶颈在哪。三步定位看日志配置页点 View logs重点找 CACHE 开头的行。缓存服务的每次读写都打 Debug 日志见 CacheService.cs可以确认同一搜索词是否命中缓存以及哪个站点频繁超时。看进程资源top 或任务管理器里盯 Jackett 进程。CPU 高但内存平稳 → 索引器并发竞争内存持续爬升 → 缓存参数问题两者都高 → 机器规格不够直接跳到文末那一节。单索引器 Test在 Configured Indexers 页逐个 Test。IndexerManagerService.cs 的 TestIndexer 会用计时器给每个索引器计时日志里的耗时毫秒数就是处理优先级最直接的依据。判断标准日志大量超时、CPU 平稳 → 网络或代理层问题别动参数Test 慢的只有一两个 → 定向禁用或替换即可CPU 高、内存平稳 → 并发竞争靠后文分组解决缓存层缓存 TTL 设多少秒合适缓存层是 Jackett 性能优化里最可控的变量。先讲清生命周期再谈参数。Jackett 的缓存是纯内存的以查询哈希为键。读 CacheService.cs 这个文件是因为三条规则都写在这里同词重搜才是有效场景搜索词、分类、类型任一变化哈希就不同必然回源。所以重复搜同一个词才是缓存收益最大的动作。双重过期每次搜索先执行 TTL 修剪清掉超过 CacheTtl 的结果单个索引器结果总数超限时按查询新旧批量淘汰旧查询。缓存不会无限驻留内存是有界的。例外不缓存Test 查询、抛异常的请求都直接丢弃。所以改完某个索引器配置后命中率短暂下降是正常的它的缓存会被清掉重测。Cache TTL 设多少默认 2100 不是拍脑袋。ServerConfig.cs 里默认值和注释写得明白Sonarr 15 分钟、Radarr 60 分钟、LazyLibrarian 20 分钟35 分钟是能盖住它们的公共值。设得比 15 分钟短arr 工具的周期扫描会全部穿透缓存比 60 分钟长库更新快的私有站就会长期给旧结果。三档对比TTL 档位内存占用结果时效适用场景600 秒低10 分钟即过期回源多索引器少、内存紧张2100 秒默认中35 分钟覆盖 arr 扫描间隔通用起点3600 秒偏高1 小时私有站结果滞后索引器多、刷库快Cache max results per indexer 默认 1000是单个索引器缓存结果总数的上限超限就淘汰旧查询。跨分类搜索多可以提到 2000但每个索引器的内存占用会翻倍别盲目拉高。配置页底部这三项就是缓存调参的全部入口截图中的 2100 是默认值️ 索引器瘦身与分组策略索引器数量是性能第一杀手。走 all 搜索时Jackett 会把请求同时扇出到所有启用的索引器IndexerManagerService.cs 里的聚合索引器就是直接拿全部索引器实例构建的。数量越多、越慢资源竞争越激烈。瘦身比调参见效直接是 Jackett 性能优化里我最建议先做的动作。禁用与删除有本质区别禁用只是本次搜索不请求它配置和 cookie 状态都保留恢复是一键的事删除会清掉配置cookie 得重新登录导入。长期不用的站点禁用不要删除。分组有现成基础Jackett 内置了按类型和标签的过滤器索引器可以直接用过滤名当搜索入口。自己划组的常见方案按内容类型电影站归电影组、动漫站单独一组各 arr 只指向自己那组按响应速度Test 稳定在 1 秒内的进快组留给手动搜索慢的进背景组只做订阅按使用频率每天要搜的核心站一组长尾站一组机器吃紧时只跑核心组列表里每行的类型标签和右侧 Test 按钮是瘦身操作最常用的两个入口搜索行为微调用筛选器砍掉请求量搜索习惯是 Jackett 性能优化的最后一块成本最低。手动搜索时先用 Tracker、Category、Type 筛选器收窄范围只查需要的站点和分类结果集变小、响应变短缓存命中率还会顺带提升。Type 筛选public / private / semi-public排查时尤其有用——先确认慢的是不是私有站那一批再动手。并发上Jackett 没有暴露可配置的并发上限all 搜索天然是全量扇出。替代策略不要在上一轮搜索没返回时叠加发起新一轮能拆成分组搜索就拆别每次都点 all。结果上方会列出各追踪器的耗时慢索引器一眼就能挑出来系统资源与长期维护缓存在内存里15 个以上索引器同时启用宿主机至少给 2GB 内存低于这个线调参都是白搭。长期运行会有内存碎片累积配一个定期重启Linux 用 crontab 每周重启一次服务Windows 用任务计划程序。重启同时是配置体检的机会顺手看一眼日志里有没有新增的超时。⚠️ 避坑清单缓存 TTL 设 60 秒 → 每次搜索都打满所有索引器带宽先炸 → 回 2100 秒追求新鲜度最低也只降到 600 秒关缓存图省事 → 所有请求实时回源CPU 和内存双高 → 保持开启需要时只清对应索引器的缓存Cache max results per indexer 拉到 10000 → 内存翻倍淘汰只在超限后发生 → 最多给到 2000改完代理配置还怀疑旧结果残留 → 源码里这种情况会整体清缓存 → 仍见怪结果先查代理配置本身加索引器后不 Test → 慢的站要到搜索时才暴露瓶颈难定位 → 添加后立即 Test在日志里留耗时基线连续叠加多个 all 搜索 → 全量并发竞争第二轮被拖慢 → 换分组搜索或等上一轮返回如果只做三件事按优先级排第一确认缓存开启、TTL 2100 秒、每索引器 1000 条第二禁用长期不用的索引器高频搜索改走分组而不是 all第三把每周自动重启写进 crontab 或任务计划程序。Jackett 性能优化本质是减法砍掉无谓的请求面参数自然就少得多了。【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Jackett 性能优化全记录：从缓存调参到索引器瘦身
Jackett 性能优化全记录从缓存调参到索引器瘦身【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett实例上配置的索引器攒到 25 个以后Jackett 性能优化的问题就变得很直观走「all」索引器搜一次从 2 秒涨到 8 秒Radarr 的周期扫描也开始拖后。这不是单点故障是缓存参数、索引器规模、搜索习惯三者叠加的结果。下面是我在一台老实例上排障时走的路径先定位瓶颈再动参数。 先诊断再开药怎么找到瓶颈诊断占 Jackett 性能优化的一半别急着改配置先看瓶颈在哪。三步定位看日志配置页点 View logs重点找 CACHE 开头的行。缓存服务的每次读写都打 Debug 日志见 CacheService.cs可以确认同一搜索词是否命中缓存以及哪个站点频繁超时。看进程资源top 或任务管理器里盯 Jackett 进程。CPU 高但内存平稳 → 索引器并发竞争内存持续爬升 → 缓存参数问题两者都高 → 机器规格不够直接跳到文末那一节。单索引器 Test在 Configured Indexers 页逐个 Test。IndexerManagerService.cs 的 TestIndexer 会用计时器给每个索引器计时日志里的耗时毫秒数就是处理优先级最直接的依据。判断标准日志大量超时、CPU 平稳 → 网络或代理层问题别动参数Test 慢的只有一两个 → 定向禁用或替换即可CPU 高、内存平稳 → 并发竞争靠后文分组解决缓存层缓存 TTL 设多少秒合适缓存层是 Jackett 性能优化里最可控的变量。先讲清生命周期再谈参数。Jackett 的缓存是纯内存的以查询哈希为键。读 CacheService.cs 这个文件是因为三条规则都写在这里同词重搜才是有效场景搜索词、分类、类型任一变化哈希就不同必然回源。所以重复搜同一个词才是缓存收益最大的动作。双重过期每次搜索先执行 TTL 修剪清掉超过 CacheTtl 的结果单个索引器结果总数超限时按查询新旧批量淘汰旧查询。缓存不会无限驻留内存是有界的。例外不缓存Test 查询、抛异常的请求都直接丢弃。所以改完某个索引器配置后命中率短暂下降是正常的它的缓存会被清掉重测。Cache TTL 设多少默认 2100 不是拍脑袋。ServerConfig.cs 里默认值和注释写得明白Sonarr 15 分钟、Radarr 60 分钟、LazyLibrarian 20 分钟35 分钟是能盖住它们的公共值。设得比 15 分钟短arr 工具的周期扫描会全部穿透缓存比 60 分钟长库更新快的私有站就会长期给旧结果。三档对比TTL 档位内存占用结果时效适用场景600 秒低10 分钟即过期回源多索引器少、内存紧张2100 秒默认中35 分钟覆盖 arr 扫描间隔通用起点3600 秒偏高1 小时私有站结果滞后索引器多、刷库快Cache max results per indexer 默认 1000是单个索引器缓存结果总数的上限超限就淘汰旧查询。跨分类搜索多可以提到 2000但每个索引器的内存占用会翻倍别盲目拉高。配置页底部这三项就是缓存调参的全部入口截图中的 2100 是默认值️ 索引器瘦身与分组策略索引器数量是性能第一杀手。走 all 搜索时Jackett 会把请求同时扇出到所有启用的索引器IndexerManagerService.cs 里的聚合索引器就是直接拿全部索引器实例构建的。数量越多、越慢资源竞争越激烈。瘦身比调参见效直接是 Jackett 性能优化里我最建议先做的动作。禁用与删除有本质区别禁用只是本次搜索不请求它配置和 cookie 状态都保留恢复是一键的事删除会清掉配置cookie 得重新登录导入。长期不用的站点禁用不要删除。分组有现成基础Jackett 内置了按类型和标签的过滤器索引器可以直接用过滤名当搜索入口。自己划组的常见方案按内容类型电影站归电影组、动漫站单独一组各 arr 只指向自己那组按响应速度Test 稳定在 1 秒内的进快组留给手动搜索慢的进背景组只做订阅按使用频率每天要搜的核心站一组长尾站一组机器吃紧时只跑核心组列表里每行的类型标签和右侧 Test 按钮是瘦身操作最常用的两个入口搜索行为微调用筛选器砍掉请求量搜索习惯是 Jackett 性能优化的最后一块成本最低。手动搜索时先用 Tracker、Category、Type 筛选器收窄范围只查需要的站点和分类结果集变小、响应变短缓存命中率还会顺带提升。Type 筛选public / private / semi-public排查时尤其有用——先确认慢的是不是私有站那一批再动手。并发上Jackett 没有暴露可配置的并发上限all 搜索天然是全量扇出。替代策略不要在上一轮搜索没返回时叠加发起新一轮能拆成分组搜索就拆别每次都点 all。结果上方会列出各追踪器的耗时慢索引器一眼就能挑出来系统资源与长期维护缓存在内存里15 个以上索引器同时启用宿主机至少给 2GB 内存低于这个线调参都是白搭。长期运行会有内存碎片累积配一个定期重启Linux 用 crontab 每周重启一次服务Windows 用任务计划程序。重启同时是配置体检的机会顺手看一眼日志里有没有新增的超时。⚠️ 避坑清单缓存 TTL 设 60 秒 → 每次搜索都打满所有索引器带宽先炸 → 回 2100 秒追求新鲜度最低也只降到 600 秒关缓存图省事 → 所有请求实时回源CPU 和内存双高 → 保持开启需要时只清对应索引器的缓存Cache max results per indexer 拉到 10000 → 内存翻倍淘汰只在超限后发生 → 最多给到 2000改完代理配置还怀疑旧结果残留 → 源码里这种情况会整体清缓存 → 仍见怪结果先查代理配置本身加索引器后不 Test → 慢的站要到搜索时才暴露瓶颈难定位 → 添加后立即 Test在日志里留耗时基线连续叠加多个 all 搜索 → 全量并发竞争第二轮被拖慢 → 换分组搜索或等上一轮返回如果只做三件事按优先级排第一确认缓存开启、TTL 2100 秒、每索引器 1000 条第二禁用长期不用的索引器高频搜索改走分组而不是 all第三把每周自动重启写进 crontab 或任务计划程序。Jackett 性能优化本质是减法砍掉无谓的请求面参数自然就少得多了。【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考