client-go icon indicating copy to clipboard operation
client-go copied to clipboard

select report error while run sysbench update

Open Lily2025 opened this issue 3 years ago • 2 comments

v5.1.2 case:TiKVWorkloadStress001 select report error while run sysbench update oltp_write_only:1024 threads

image

Lily2025 avatar Sep 26 '21 08:09 Lily2025

[2021/09/25 11:50:48.531 +00:00] [WARN] [backoff.go:175] ["txnLockFast backoffer.maxSleep 40000ms is exceeded, errors:
primary_lock:"t\200\000\000\000\000\000\000\334_r\200\000\000\000\000L$\376" lock_version:427968577045004397 key:"t\200\000\000\000\000\000\000\264_r\200\000\000\000\000EI\224" lock_ttl:20015 txn_size:1 lock_for_update_ts:427968577045004397 use_async_commit:true min_commit_ts:427968577057849385  at 2021-09-25T11:50:43.458920916Z
primary_lock:"t\200\000\000\000\000\000\000\334_r\200\000\000\000\000L$\376" lock_version:427968577045004397 key:"t\200\000\000\000\000\000\000\264_r\200\000\000\000\000EI\224" lock_ttl:20015 txn_size:1 lock_for_update_ts:427968577045004397 use_async_commit:true min_commit_ts:427968577057849385  at 2021-09-25T11:50:46.127846468Z
primary_lock:"t\200\000\000\000\000\000\000\334_r\200\000\000\000\000L$\376" lock_version:427968577045004397 key:"t\200\000\000\000\000\000\000\264_r\200\000\000\000\000EI\224" lock_ttl:20015 txn_size:1 lock_for_update_ts:427968577045004397 use_async_commit:true min_commit_ts:427968577057849385  at 2021-09-25T11:50:48.531687229Z"]

[2021/09/25 11:50:48.532 +00:00] [INFO] [conn.go:877] ["command dispatched failed"] [conn=3261] [connInfo="id:3261, addr:10.244.4.180:56142 status:10, collation:utf8mb4_general_ci, user:root"] [command=Query] [status="inTxn:0, autocommit:1"] [sql="select * from sbtest2 limit 1,100"] [txn_mode=PESSIMISTIC] [err="[tikv:9004]Resolve lock timeout\ngithub.com/pingcap/errors.AddStack\n\t/nfs/cache/mod/github.com/pingcap/[email protected]/errors.go:174\ngithub.com/pingcap/errors.Trace\n\t/nfs/cache/mod/github.com/pingcap/[email protected]/juju_adaptor.go:15\ngithub.com/pingcap/tidb/store/copr.(*copIteratorWorker).handleCopResponse\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/store/copr/coprocessor.go:903\ngithub.com/pingcap/tidb/store/copr.(*copIteratorWorker).handleTaskOnce\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/store/copr/coprocessor.go:751\ngithub.com/pingcap/tidb/store/copr.(*copIteratorWorker).handleTask\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/store/copr/coprocessor.go:643\ngithub.com/pingcap/tidb/store/copr.(*copIteratorWorker).run\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/store/copr/coprocessor.go:380\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1371"]

workload: sysbench oltp_write_only + range query. Transaction commits slowly. I assume we can exclude txnLockFast backoffs like serverIsBusy. /cc @sticnarf

youjiali1995 avatar Sep 26 '21 08:09 youjiali1995

@youjiali1995 It seems a bit strange to exclude txnLockFast because TTLs of these locks should be short and can be resolved in a short time.

With flow control, at least it should not be slow to resolve locks. So I suggest additionally making CheckTxnStatus and CheckSecondaryLocks as sys commands to bypass flow control. And reading requests should be able to quickly resolve these locks.

Of course, for versions below 5.2, excluding txnLockFast backoffs can be a workaround but I doubt a bit about worthness.

sticnarf avatar Sep 26 '21 08:09 sticnarf