升级5.0.5后,tikv一直出现oom。

原先版本5.0.3,使用tiup升级后
升级5.0.5后,tikv一出现 gc worker cpu 100%
然后出现oom了。。。


3 个赞

有更多的日志,或者监控信息,可以放出来么?

3 个赞

麻烦按照这个做一下信息收集给到我们。

4 个赞

久等了 麻烦帮忙看下。。
https://clinic.pingcap.com:4433/diag/files?uuid=8c16287e9fd72206-776632905d48d26d-2eebb4fd985f0629

3 个赞

兄弟~。这个咋搞,kv轮着崩,。

4 个赞

日志有点大,还没有打开。你这边是有大量的 delete 数据操作吗?这个操作已经完成么 ?有哪些大量的数据操作吗?

4 个赞

你先发我一下 tikv-details 监控数据吧, 我发一个工具给你哈。帮我抓一下最近 4 小时的监控数据,我们先看看这个哈。
https://metricstool.pingcap.com/

4 个赞

先按照这个文档排查一下这个问题 ,看一下参数配置是否有问题。https://docs.pingcap.com/zh/tidb/stable/tidb-troubleshooting-map/#42-tikv-oom

4 个赞

tidb-pro-TiKV-Details_2021-12-29T10_22_12.964Z.rar (2.5 MB)

4 个赞

storage.block-cache 这个参数我这是默认得, 在5.0.3版本得时候完全没问题。 主要升级后出现gc worker cpu 一直满,然后对应得机器 轮番出现oom

4 个赞

嗯 ,你对比一下前后升级的参数?业务有变化吗?

4 个赞

什么时候升级的?

4 个赞

这几个参数都没变化, 今天早上10点左右

4 个赞

再给一个 9:00-14:00 的 tikv-details 监控 ?

4 个赞

tidb-pro-TiKV-Details_2021-12-29T11_32_41.818Z.rar (2.1 MB)

5 个赞

帮忙确认一下这个 Update 操作是一直都有么?还是最近刚开始的?

digest:9505cacb7c710ed17125fcc6cb3669e8ddca6c8cd8af6a31f6b3cd64604c3098 component:tidb host:10.10.10.74 instanceid:tidb-4000 message:# Time: 2021-12-29T17:16:06.087011423+08:00 # Txn_start_ts: 430117844525776905 # User: root # Host: 10.10.10.74 # Conn_ID: 31615 # Exec_retry_count: 0 # Exec_retry_time: 0 # Query_time: 0.430880158 # Parse_time: 8.713e-06 # Compile_time: 3.1896e-05 # Rewrite_time: 1.951e-06 # Preproc_subqueries: 0 # Preproc_subqueries_time: 0 # Optimize_time: 1.9079e-05 # Wait_TS: 0.000184655 # Prewrite_time: 0.001362605 # Wait_prewrite_binlog_time: 3.51e-07 # Commit_time: 0.429233644 # Get_commit_ts_time: 0.000162917 # Commit_backoff_time: 0 # Backoff_types: # Resolve_lock_time: 0 # Local_latch_wait_time: 0 # Write_keys: 1 # Write_size: 2189 # Prewrite_region: 1 # Txn_retry: 0 # Cop_time: 0 # Process_time: 0 # Wait_time: 0 # Backoff_time: 0 # LockKeys_time: 0 # Request_count: 0 # Total_keys: 0 # Process_keys: 0 # Rocksdb_delete_skipped_count: 0 # Rocksdb_key_skipped_count: 0 # Rocksdb_block_cache_hit_count: 0 # Rocksdb_block_read_count: 0 # Rocksdb_block_read_byte: 0 # DB: # Index_names: # Is_internal: 0 # Digest: 9505cacb7c710ed17125fcc6cb3669e8ddca6c8cd8af6a31f6b3cd64604c3098 # Stats: # Cop_proc_avg: 0 # Cop_proc_p90: 0 # Cop_proc_max: 0 # Cop_proc_addr: # Cop_wait_avg: 0 # Cop_wait_p90: 0 # Cop_wait_max: 0 # Cop_wait_addr: # Mem_max: 0 # Disk_max: 0 # KV_total: 0.43053602 # PD_total: 0.00015782 # Backoff_total: 0 # Write_sql_response_total: 0 # Result_rows: 0 # Backoff_Detail: # Prepared: 0 # Succ: 1 # IsExplicitTxn: 0 # Plan_from_cache: 0 # Plan_from_binding: 0 # Plan: # Plan_digest: # Prev_stmt: UPDATE `readernovel_tidb_fr`.`userbuybookhistory` SET `UserId` = 118543237, `BookId` = 111410, `Chapters` =
2 个赞

这个上两周就有了, 咋了

我把capacity 降低到15G, 只能延长oom得时间间隔, 不会是啥bug把?

要在看一下,现在定位应该写入处理在 KV 层堆积,触发 write stall,需要对比一下TiKV 升级前后 RocksDB 参数,参考一下两个文档:
https://book.tidb.io/session4/chapter7/tikv-is-busy.html
https://en.pingcap.com/blog/how-to-troubleshoot-rocksdb-write-stalls-in-tikv/

2 个赞

升级前后没有修改过tikv得配置,
raftstore.raft-entry-max-size: 125829120
raftstore.sync-log: false
readpool.coprocessor.use-unified-pool: true
readpool.storage.use-unified-pool: true
一直都保持这份。

那目前得情况 我要缓解这个oom
可以从
max-sub-compactions 2~3
level0-slowdown-writes-trigger 这两个参数入手是吗