horizon启动后redis内存暴涨，需调优config/horizon.php：缩减trim值、禁用requests/redis指标、限制dashboard limit至20~50、关闭自动刷新，并停用supervisor中的queue:work进程以避免冲突。
Horizon 不是装上就能“自动变快”的监控工具，它本身会吃 Redis 资源、拖慢队列吞吐，不调优反而成性能瓶颈。
Horizon 启动后 Redis 内存暴涨怎么办
Horizon 默认每秒从 Redis 读取大量 zrange、hgetall 和 llen 数据，尤其在高并发队列场景下，会频繁触发 KEYS 类扫描操作（即使配置了前缀），导致 Redis CPU 占用飙升、响应延迟拉高。
- 在
config/horizon.php中关闭非必要指标采集：把'trim' => ['recent' => 100, 'failed' => 1000]改为更保守的值，比如50和200 - 禁用实时图表中不用的维度：将
'metrics' => ['jobs' => true, 'requests' => false, 'redis' => false]，requests和redis是重头开销来源 - 确认
HORIZON_PREFIX已在.env中设置（如HORIZON_PREFIX=horizon:），否则 Horizon 会扫全库 key，RedisKEYS *在生产环境等于自毁
任务列表卡顿、加载超时的直接原因
Horizon Web 界面默认按时间倒序拉取全部 recent_jobs，当单日任务量 > 5 万时，前端请求 /horizon/api/jobs/recent 可能卡住 10 秒以上，甚至触发 Nginx 504。
- 不要依赖“全量加载”：在
config/horizon.php的'dashboard' => ['limit' => 50]里把默认100降到20~50 - 禁用自动刷新：前端页面右上角的“Auto-refresh”开关关掉，改成手动点“Refresh”，避免后台持续轮询
- 失败任务页慎用“Retry All”：批量重试会瞬间向 Redis 写入大量新 job，可能压垮连接池；改用
php artisan queue:retry [id]单条处理
Supervisor 配置和 Horizon 进程冲突
常见错误是同时用 Supervisor 拉起 php artisan queue:work 和 php artisan horizon —— 两者都会消费同一 Redis 队列，造成任务被重复执行或状态错乱。
- Horizon 启动后，必须停掉所有
queue:work类进程：运行php artisan horizon:terminate清理残留，再检查ps aux | grep horizon是否只剩一个主进程 - Supervisor 配置里只留 Horizon：删掉旧的
queue-workerprogram 段，新增一个只跑php artisan horizon的段，并设autostart=true - Horizon 自带进程管理，不需要额外配
numprocs：它的environments配置块里已定义每个队列的processes数，改那里就行
Horizon 的真实价值不在“看得多”，而在“看得准”。把 trim、metrics、limit 三个配置项压到最低可用水位，再配合 failed_jobs 表 + Telescope 补充异常上下文，才是稳定可运维的组合。别让它成为你 Redis 的第一个背锅侠。
