事务两阶段提交中第一阶段(prewrite 阶段)的耗时比较慢,主要发生在哪个阶段:
我下面有张图:
id task estRows operator info actRows execution info memory disk Insert_1 root 0 N/A 0 time:69.5μs, loops:1, prepare: 36.3μs, insert:33.2μs,
commit_txn: {prewrite:2.02s, slowest_prewrite_rpc: {total: 2.020s, region_id: 111019779, store: 10.0.47.24:20160,
tikv_wall_time: 1.48s, scan_detail: {get_snapshot_time: 5.07μs, rocksdb: {block: {cache_hit_count: 14}}}, write_detail:
{store_batch_wait: 15.8μs, propose_send_wait: 0s, persist_log: {total: 211.4μs, write_leader_wait: 47.5μs, sync_log: 109.2μs, write_memtable: 2.15μs},
commit_log: 1.46s, apply_batch_wait: 15.6μs, apply: {total:473.5μs, mutex_lock: 0s, write_leader_wait: 157.8μs, write_wal: 0s, write_memtable: 133.6μs}}},
region_num:1, write_keys:2, write_byte:7925} 8.66 KB N/A
以上是执行计划的具体耗时,看时间主要耗时在tikv_wall_time: 1.48s 这块的监控图主要要哪里找?
不是显示慢在commit_log了吗?
commit log 阶段不是包含在
阶段里面吗?storage async write duration 整个阶段最高就是2.50ms
这个有点多,我慢慢理解一下,谢谢。
这个是99线,可以改下表达式看下
grafana 监控 tikv details— raft propose —propose wait duration per server
grafana 监控 tikv details— raft IO —append log duration
grafana 监控 tikv details— raft IO —commit log duration
grafana 监控 tikv details— raft propose—apply wait duration
grafana 监控 tikv details— raft IO —apply log duration
对应的几个阶段再grafana里面都有监控项啊,看下commit log吧先
学习一下
insert这么慢,大概率硬件出现问题了,io瓶颈或者tikv节点不够了
磁盘是ssd的吗
是nvme盘
tikv_wall_time
prewrite 阶段主要做的事情是版本检查和所冲突检测。
如果耗时较久,可以重点排查是不是数据版本过多、是不是有比较多的事务冲突。
进grafana,找到TiKV-Trouble-Shooting面板 -》Pending compaction bytes图。
我想看看10:20分的时候这个Pending compaction bytes图有些什么内容。