【 TiDB 使用环境】生产环境
【 TiDB 版本】v7.5.2
【遇到的问题：TiKV查询不到OOM的日志信息】
在系统日志中查到OOM，并且TiKV重启。
进入TiKV查询不到日志信息
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
机器多大内存？ 其他的还跑了什么？ tikv内存再18G左右也没有突增啥的
每个都是16核32G内存。TiKV节点都没跑其他的呢
cat tikv.log | grep -i ‘Welcome to TiKV’
你看下 node-expoter监控中 每个tikv的内存
没有日志
自从升级到v7.5.2版本后，就没打印日志了
OOM一般是因为大量的tikv扫描导致的，看不看日志也不那么关键，你看看监控里面的coprocessor请求是不是很多。然后对应的分析下sql，把大批量扫描的sql优化下。
看起来还好，PD的节点都正常么？
dashboard监控面板好像有个日志菜单，你点击进去，选中指定tikv机器，然后按时间范围搜索日志信息看下有没有
看不到重启日志呢
PD是正常的
- 检查 TiKV 的日志文件：TiKV 的日志文件（通常是
tikv.log）中可能包含 OOM 相关的详细信息。你需要检查日志文件，查看是否有关于 OOM 的关键词，如 “OOM detected” 或 “Memory Exceeded” 等 。 - 操作系统日志：操作系统日志中也可能存在关于 OOM 的线索。检查操作系统日志是否出现 “Out of Memory” 或 “Memory Exhausted” 等错误信息，这可以帮助定位问题 。
- 监控系统：通过 TiKV 的监控系统，你可以检查内存使用情况，例如在 TiKV Detail → Clusters → Memory 监控界面查看内存使用情况。同时，可以检查 RocksDB 的 block cache size 监控来确认是否是 block-cache 配置过大导致的问题 。
- TiKV 配置参数：确认 TiKV 的配置参数是否合理，特别是与内存使用相关的参数，如
memory-usage-high-water控制 TiKV 内存上限 。 - 网络和 gRPC 线程：如果 coprocessor 数据有积压，或者 gRPC CPU 线程存在瓶颈，也可能导致 OOM。可以检查 Node_exporter → Network → Network IN/OUT Traffice → Outbound 指标，以及 TiKV Detail → Thread CPU → gRPC poll CPU 来确认是否存在这些问题
tikvoom专门有个文件夹在deploy目录里面的tikv/log/oom 这里
你的tikv日志级别是什么？为什么只有error日志？
error，所以oom重启，不属于error，就没日志叭？
v 7.5.2 版本好像没有嘞