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

xmlianfeng · 2021 年12 月 29 日 09:07

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

xfworld · 2021 年12 月 29 日 09:09

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

Lucien-卢西恩 · 2021 年12 月 29 日 09:14

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

xmlianfeng · 2021 年12 月 29 日 09:47

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

xmlianfeng · 2021 年12 月 29 日 10:16

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

Lucien-卢西恩 · 2021 年12 月 29 日 10:18

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

Lucien-卢西恩 · 2021 年12 月 29 日 10:20

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

Lucien-卢西恩 · 2021 年12 月 29 日 10:23

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

xmlianfeng · 2021 年12 月 29 日 10:33

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

xmlianfeng · 2021 年12 月 29 日 10:42

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

Lucien-卢西恩 · 2021 年12 月 29 日 11:11

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

Lucien-卢西恩 · 2021 年12 月 29 日 11:11

什么时候升级的？

xmlianfeng · 2021 年12 月 29 日 11:18

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

Lucien-卢西恩 · 2021 年12 月 29 日 11:19

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

xmlianfeng · 2021 年12 月 29 日 11:36

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

Lucien-卢西恩 · 2021 年12 月 29 日 11:50

帮忙确认一下这个 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` =

xmlianfeng · 2021 年12 月 29 日 11:53

这个上两周就有了，咋了

xmlianfeng · 2021 年12 月 29 日 12:03

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

Lucien-卢西恩 · 2021 年12 月 29 日 12:17

要在看一下，现在定位应该写入处理在 KV 层堆积，触发 write stall，需要对比一下TiKV 升级前后 RocksDB 参数，参考一下两个文档：
7.3 TiKV is busy 处理思路 · TiDB in Action
https://en.pingcap.com/blog/how-to-troubleshoot-rocksdb-write-stalls-in-tikv/

xmlianfeng · 2021 年12 月 29 日 12:25

升级前后没有修改过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 这两个参数入手是吗