慢查询界面报错

[chenhanneu]

一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题

【TiDB 使用环境】生产环境 /测试环境
【TiDB 版本】v7.1.3
【部署方式】物理机
【操作系统/CPU 架构/芯片详情】
【机器部署详情】CPU大小/内存大小/磁盘大小
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
有多个tidb server节点，慢日志保留30天，每个节点慢日志多个文件大约有9G

[kang]

你这报错通常是慢日志文件过大导致查询超时。建议：

1. 调整慢日志保留策略，减少保留天数或限制单文件大小。

[TiDBer_bawpguhQ]

慢查询页加载失败多因慢日志过大或解析超时。建议：缩短慢日志保留、按节点轮转清理；Dashboard/ng-monitoring 适当提超时与资源；也可用pt-query-digest或直接扫慢日志。先确认各 TiDB 节点磁盘与 ng-monitoring 是否 OOM。

[菩提老祖]

是不是可以改下日志级别 少产生些日志

[刘大明白 (拾橘光)]

调整慢日志保留策略，设置保留天数

[mike117 (Ti D Ber Uvu Vx Fwd)]

多 TiDB 节点、慢日志总量到数 GB 时，Dashboard 慢查询页解析失败很常见（超时/内存/文件过多）。

处理：
1）先在各节点本地用 pt/tidb-lightning 无关工具或 grep 抽近期慢日志，确认不是 UI 独有问题。
2）缩短保留天数或减小单文件体积；清理过期慢日志后再开 Dashboard。
3）升级到你版本对应已知修复（慢查询页对超大日志更稳的版本）。

把报错完整文案和 Dashboard 版本贴一下，可以判断是解析超时还是权限/路径问题。

[独善其身 (Ti D Ber Bi Rqfz5 K)]

• 单节点 9G、多节点合计几十 GB 日志，一次性读入内存触发Dashboard OOM，进程直接终止请求，页面转圈 / 空白 / 500 报错；
• 前端 HTTP 网关 / 浏览器请求超时：海量日志解析、JSON 序列化耗时远超前端默认 60s 超时；
• v5.4 老版本 Dashboard 无分片流式读取逻辑，不支持边读边过滤，必须全文件加载；
• 日志切割参数未配置，单文件无限膨胀 + 长期保留 30 天备份文件叠加，体积爆炸。