Jackett 性能優(yōu)化全記錄從緩存調(diào)參到索引器瘦身【免費(fèi)下載鏈接】JackettAPI Support for your favorite torrent trackers項(xiàng)目地址: https://gitcode.com/GitHub_Trending/ja/Jackett實(shí)例上配置的索引器攢到 25 個(gè)以后Jackett 性能優(yōu)化的問題就變得很直觀走「all」索引器搜一次從 2 秒漲到 8 秒Radarr 的周期掃描也開始拖后。這不是單點(diǎn)故障是緩存參數(shù)、索引器規(guī)模、搜索習(xí)慣三者疊加的結(jié)果。下面是我在一臺(tái)老實(shí)例上排障時(shí)走的路徑先定位瓶頸再動(dòng)參數(shù)。 先診斷再開藥怎么找到瓶頸診斷占 Jackett 性能優(yōu)化的一半別急著改配置先看瓶頸在哪。三步定位看日志配置頁點(diǎn) View logs重點(diǎn)找 CACHE 開頭的行。緩存服務(wù)的每次讀寫都打 Debug 日志見 CacheService.cs可以確認(rèn)同一搜索詞是否命中緩存以及哪個(gè)站點(diǎn)頻繁超時(shí)。看進(jìn)程資源top 或任務(wù)管理器里盯 Jackett 進(jìn)程。CPU 高但內(nèi)存平穩(wěn) → 索引器并發(fā)競(jìng)爭(zhēng)內(nèi)存持續(xù)爬升 → 緩存參數(shù)問題兩者都高 → 機(jī)器規(guī)格不夠直接跳到文末那一節(jié)。單索引器 Test在 Configured Indexers 頁逐個(gè) Test。IndexerManagerService.cs 的 TestIndexer 會(huì)用計(jì)時(shí)器給每個(gè)索引器計(jì)時(shí)日志里的耗時(shí)毫秒數(shù)就是處理優(yōu)先級(jí)最直接的依據(jù)。判斷標(biāo)準(zhǔn)日志大量超時(shí)、CPU 平穩(wěn) → 網(wǎng)絡(luò)或代理層問題別動(dòng)參數(shù)Test 慢的只有一兩個(gè) → 定向禁用或替換即可CPU 高、內(nèi)存平穩(wěn) → 并發(fā)競(jìng)爭(zhēng)靠后文分組解決緩存層緩存 TTL 設(shè)多少秒合適緩存層是 Jackett 性能優(yōu)化里最可控的變量。先講清生命周期再談參數(shù)。Jackett 的緩存是純內(nèi)存的以查詢哈希為鍵。讀 CacheService.cs 這個(gè)文件是因?yàn)槿龡l規(guī)則都寫在這里同詞重搜才是有效場(chǎng)景搜索詞、分類、類型任一變化哈希就不同必然回源。所以重復(fù)搜同一個(gè)詞才是緩存收益最大的動(dòng)作。雙重過期每次搜索先執(zhí)行 TTL 修剪清掉超過 CacheTtl 的結(jié)果單個(gè)索引器結(jié)果總數(shù)超限時(shí)按查詢新舊批量淘汰舊查詢。緩存不會(huì)無限駐留內(nèi)存是有界的。例外不緩存Test 查詢、拋異常的請(qǐng)求都直接丟棄。所以改完某個(gè)索引器配置后命中率短暫下降是正常的它的緩存會(huì)被清掉重測(cè)。Cache TTL 設(shè)多少默認(rèn) 2100 不是拍腦袋。ServerConfig.cs 里默認(rèn)值和注釋寫得明白Sonarr 15 分鐘、Radarr 60 分鐘、LazyLibrarian 20 分鐘35 分鐘是能蓋住它們的公共值。設(shè)得比 15 分鐘短arr 工具的周期掃描會(huì)全部穿透緩存比 60 分鐘長庫更新快的私有站就會(huì)長期給舊結(jié)果。三檔對(duì)比TTL 檔位內(nèi)存占用結(jié)果時(shí)效適用場(chǎng)景600 秒低10 分鐘即過期回源多索引器少、內(nèi)存緊張2100 秒默認(rèn)中35 分鐘覆蓋 arr 掃描間隔通用起點(diǎn)3600 秒偏高1 小時(shí)私有站結(jié)果滯后索引器多、刷庫快Cache max results per indexer 默認(rèn) 1000是單個(gè)索引器緩存結(jié)果總數(shù)的上限超限就淘汰舊查詢。跨分類搜索多可以提到 2000但每個(gè)索引器的內(nèi)存占用會(huì)翻倍別盲目拉高。配置頁底部這三項(xiàng)就是緩存調(diào)參的全部入口截圖中的 2100 是默認(rèn)值? 索引器瘦身與分組策略索引器數(shù)量是性能第一殺手。走 all 搜索時(shí)Jackett 會(huì)把請(qǐng)求同時(shí)扇出到所有啟用的索引器IndexerManagerService.cs 里的聚合索引器就是直接拿全部索引器實(shí)例構(gòu)建的。數(shù)量越多、越慢資源競(jìng)爭(zhēng)越激烈。瘦身比調(diào)參見效直接是 Jackett 性能優(yōu)化里我最建議先做的動(dòng)作。禁用與刪除有本質(zhì)區(qū)別禁用只是本次搜索不請(qǐng)求它配置和 cookie 狀態(tài)都保留恢復(fù)是一鍵的事刪除會(huì)清掉配置cookie 得重新登錄導(dǎo)入。長期不用的站點(diǎn)禁用不要?jiǎng)h除。分組有現(xiàn)成基礎(chǔ)Jackett 內(nèi)置了按類型和標(biāo)簽的過濾器索引器可以直接用過濾名當(dāng)搜索入口。自己劃組的常見方案按內(nèi)容類型電影站歸電影組、動(dòng)漫站單獨(dú)一組各 arr 只指向自己那組按響應(yīng)速度Test 穩(wěn)定在 1 秒內(nèi)的進(jìn)快組留給手動(dòng)搜索慢的進(jìn)背景組只做訂閱按使用頻率每天要搜的核心站一組長尾站一組機(jī)器吃緊時(shí)只跑核心組列表里每行的類型標(biāo)簽和右側(cè) Test 按鈕是瘦身操作最常用的兩個(gè)入口搜索行為微調(diào)用篩選器砍掉請(qǐng)求量搜索習(xí)慣是 Jackett 性能優(yōu)化的最后一塊成本最低。手動(dòng)搜索時(shí)先用 Tracker、Category、Type 篩選器收窄范圍只查需要的站點(diǎn)和分類結(jié)果集變小、響應(yīng)變短緩存命中率還會(huì)順帶提升。Type 篩選public / private / semi-public排查時(shí)尤其有用——先確認(rèn)慢的是不是私有站那一批再動(dòng)手。并發(fā)上Jackett 沒有暴露可配置的并發(fā)上限all 搜索天然是全量扇出。替代策略不要在上一輪搜索沒返回時(shí)疊加發(fā)起新一輪能拆成分組搜索就拆別每次都點(diǎn) all。結(jié)果上方會(huì)列出各追蹤器的耗時(shí)慢索引器一眼就能挑出來系統(tǒng)資源與長期維護(hù)緩存在內(nèi)存里15 個(gè)以上索引器同時(shí)啟用宿主機(jī)至少給 2GB 內(nèi)存低于這個(gè)線調(diào)參都是白搭。長期運(yùn)行會(huì)有內(nèi)存碎片累積配一個(gè)定期重啟Linux 用 crontab 每周重啟一次服務(wù)Windows 用任務(wù)計(jì)劃程序。重啟同時(shí)是配置體檢的機(jī)會(huì)順手看一眼日志里有沒有新增的超時(shí)。?? 避坑清單緩存 TTL 設(shè) 60 秒 → 每次搜索都打滿所有索引器帶寬先炸 → 回 2100 秒追求新鮮度最低也只降到 600 秒關(guān)緩存圖省事 → 所有請(qǐng)求實(shí)時(shí)回源CPU 和內(nèi)存雙高 → 保持開啟需要時(shí)只清對(duì)應(yīng)索引器的緩存Cache max results per indexer 拉到 10000 → 內(nèi)存翻倍淘汰只在超限后發(fā)生 → 最多給到 2000改完代理配置還懷疑舊結(jié)果殘留 → 源碼里這種情況會(huì)整體清緩存 → 仍見怪結(jié)果先查代理配置本身加索引器后不 Test → 慢的站要到搜索時(shí)才暴露瓶頸難定位 → 添加后立即 Test在日志里留耗時(shí)基線連續(xù)疊加多個(gè) all 搜索 → 全量并發(fā)競(jìng)爭(zhēng)第二輪被拖慢 → 換分組搜索或等上一輪返回如果只做三件事按優(yōu)先級(jí)排第一確認(rèn)緩存開啟、TTL 2100 秒、每索引器 1000 條第二禁用長期不用的索引器高頻搜索改走分組而不是 all第三把每周自動(dòng)重啟寫進(jìn) crontab 或任務(wù)計(jì)劃程序。Jackett 性能優(yōu)化本質(zhì)是減法砍掉無謂的請(qǐng)求面參數(shù)自然就少得多了。【免費(fèi)下載鏈接】JackettAPI Support for your favorite torrent trackers項(xiàng)目地址: https://gitcode.com/GitHub_Trending/ja/Jackett創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考