3-4点监控显示异常

机器配置:
tidb 1台 b7(32c,128g)
tikv 3台 b11(32c,128g),b53(40C,128g),b56(32c,128g)
pd 3台 b49主(32c,64g),b26(8c,32g),b24(8c,32g)

出现这种异常特别是在凌晨的3-5点之间
tidb时不时出现堵塞,期间各种类型的query都变慢。然后几小时自己会恢复。在堵塞期间,通过dashboard观察,发现以下情况:
1,所有的kv server(一共三个)的io utility降到非常低,几乎为0,而同期的cpu使用很高。
2,同期update leader和tikvrpc都上涨,pd的pending也都上涨。
3,slow query log里包括各种查询,即使很小的表的查询也会达到1700s,但实际process时间不到1s,wait time几秒,不知道时间花在哪里。
4,tidb server 的log里频繁的报三个:1)、switch region leader to specific leader due to kv return NotLeader
2)、invalidate current region, because others failed on same store
3)、[2020/07/15 06:30:11.820 +08:00] [WARN] [client_batch.go:590] [“wait response is cancelled”] [to=192.168.241.11:20160] [cause=“context canceled”]。

监控:










tikv日志:
链接:https://pan.baidu.com/s/1rXUb8s6Xtora5G9v1RdzFA
提取码:2gps

  1. 从监控来看 56 的 TiKV 节点似乎重启了

  2. 这个蓝色的 应该是 56 吧,看起来应该是内存耗尽,导致 TikV 重启.

  1. 在 dashboard 看下在 TiKV 重启前,是否有占用内存非常多的 SQL,试着优化下 SQL,或者有批量SQL,能否分时段来跑

我这用的是ansable 部署的3.10版本,没有这个dshboard

那您可以到 tidb 慢日志里 找一下 内存消耗高的 sql, 多谢。

Time: 2020-07-15T03:48:01.957190018+08:00

Txn_start_ts: 418055596290080769

User: oopin@192.168.241.32

Conn_ID: 7243508

Query_time: 541.897792668

Parse_time: 0.000325676

Compile_time: 0.000405519

Process_time: 0.001 Wait_time: 54.232 Backoff_time: 7.636 Request_count: 2

DB: bsppr

Index_names: [xsite:url]

Is_internal: false

Digest: 2b13df4a9040bd8c3bd9e1442192eaf02e964190b7627e822c3e82da0daa7af9

Stats: xsite:418054684894035970

Num_cop_tasks: 2

Cop_proc_avg: 0.0005 Cop_proc_p90: 0.001 Cop_proc_max: 0.001 Cop_proc_addr: 192.168.241.56:20160

Cop_wait_avg: 27.116 Cop_wait_p90: 54.231 Cop_wait_max: 54.231 Cop_wait_addr: 192.168.241.56:20160

Mem_max: 11736

Prepared: false

Has_more_results: false

Succ: true

Plan: tidb_decode_plan(‘7gJoMAkzXzcJMAkxCWJzcHByLnQxLnNpdGVpZCwgFREoY2lyY3VsYXRpb24dFhxpbmR1c3RyeR0TCGxvYz4mAAxuYW1lHSIUcmF0aW5nHREIdXJsHQ4ocGlkCjEJMzFfMTQFlLhsaW1pdCBlbWJlZGRlZChvZmZzZXQ6MCwgY291bnQ6MSkKMgkxNl8xMwkxCTEJbz4fABwKMwkxM18xMQUePHRhYmxlOnQxLCBpbmRleDoFelhyYW5nZTpbImZjLnZvYy5jb20uY24iLDoQAEhdLCBrZWVwIG9yZGVyOmZhbHNlAXkMMF8xMjpbAD4nADgsIHN0YXRzOnBzZXVkbwo=’)

Plan_digest: 6e204fcc7b8510d099f8cb5ed442b85712f4981926481b332648fce24a76ed8a

SELECT t1.siteid, t1.circulation, t1.industry, t1.location, t1.name, t1.rating, t1.url, t1.pid FROM xsite AS t1 WHERE (t1.url = ‘fc.voc.com.cn’) LIMIT 1 OFFSET 0;

像这种表,单独拿出来执行是很快的

  1. 请问,这和上面的问题有什么关系呢? 并发情况下,如果集群资源不足,很可能都没有响应或者有长时间的排队
  2. Mem_max :表示执行期间 TiDB 使用的最大内存空间,单位为 byte , 可以找一下是否有 mem_max 非常大的 sql,占用了非常多的内存,多谢。

你不是说去慢日志查吗,这就是慢日志里面的

  1. 请问,这个 sql 是占用内存比较多的吗? 如果按照上面答复的 Mem_max 来找一下内存占用较多的 sql,最多的能够占用多少内存?
  2. 由于是内存不足导致的 tikv 重启,可以把重点先放到内存这里试试,从监控看应该是3点多到3点半之间内存开始下降,可以重点看这部分慢日志。

好的,谢谢

如果有疑问请继续跟帖,多谢。