Benchmarksql造数据报错。

【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.2 企业版
【问题描述】benchmarksql 造数据提示ob_query_timeout 。修改了set global ob_query_timeout=3600000000;
set global ob_trx_timeout=3600000000;
set global ob_trx_idle_timeout=86400000000; 之后benchmarksql 还是提示超时10000000(us)。
【复现路径】问题出现前后相关操作
【附件及日志】

结果是会导致压测数据时报错数据缺失。
这个是我的jdbc 的连接串
driver=com.mysql.jdbc.Driver
conn=jdbc:mysql://...:2883/test?rewriteBatchedStatements=true&allowMultiQueries=true&useLocalSessionState=true&useUnicode=true&characterEncoding=utf-8&socketTimeout=300000000&useSSL=false

要在压测对应的租户下设置超时,你应该在sys租户下设置了

1 个赞

感谢!

timeout 问题是解决了,但是出现了新的报错。发生了事务回滚。
image


错误日志如下:
[2024-01-11 14:23:22.183615] WARN handle_timeout (ob_trans_part_ctx.cpp:546) [170603][T1004_TransTime][T1004][Y0-0000000000000000-0-0] [lt=19][errcode=-6280] Transaction cost too much without commit or rollback(msg=“transaction live cost too much time without commit or abort”, ret=-6280, *this={this:0x7fcb4ab53550, trans_id:{txid:1000469}, tenant_id:1004, is_exiting:false, trans_expired_time:1704956735908685, cluster_version:17180000514, trans_need_wait_wrap:{receive_gts_ts_:[mts=0], need_wait_interval_us:0}, stc:[mts=0], ctx_create_time:1704953135908685}{ls_id:{id:1002}, session_id:3221778134, part_trans_action:2, pending_write:0, exec_info:{state:10, upstream:{id:-1}, participants:[], incremental_participants:[], prev_record_lsn:{lsn:18446744073709551615}, redo_lsns:[{lsn:4523929434}, {lsn:4523929629}, {lsn:4523929944}, {lsn:4523930139}, {lsn:4523930696}, {lsn:4523938244}, {lsn:4523945661}, {lsn:4523952696}, {lsn:4523960059}, {lsn:4523967139}, {lsn:4523971767}, {lsn:4523979288}, {lsn:4523986834}, {lsn:4523993519}, {lsn:4524002173}, {lsn:4524009990}, {lsn:4608113775}, {lsn:4623244944}, {lsn:4640972324}, {lsn:4649863866}, {lsn:4667642964}, {lsn:4694137947}, {lsn:4707158903}, {lsn:4725552538}, {lsn:4741885952}, {lsn:4754347277}, {lsn:4778532510}, {lsn:4792330636}, {lsn:4798225295}, {lsn:4804120495}, {lsn:4806085490}, {lsn:4806535361}], redo_log_no:82, multi_data_source:[], scheduler:“192.168.0.83:2882”, prepare_version:{val:18446744073709551615, v:3}, trans_type:0, next_log_entry_no:82, max_applied_log_ts:{val:1704953790925631744, v:0}, max_applying_log_ts:{val:1704953790925631744, v:0}, max_applying_part_log_no:0, max_submitted_seq_no:1704953771219241, checksum:2846689418, checksum_scn:{val:1704953790925631745, v:0}, max_durable_lsn:{lsn:10543307695}, data_complete:false, is_dup_tx:false, prepare_log_info_arr:[], xid:{gtrid_str:"", bqual_str:"", format_id:1, gtrid_str_.ptr():“data_size:0, data:”, bqual_str_.ptr():“data_size:0, data:”, g_hv:0, b_hv:0}, need_checksum:true, is_sub2pc:false}, sub_state:{flag:0}, is_leaf():false, is_root():false, busy_cbs_.get_size():0, final_log_cb_:{ObTxBaseLogCb:{base_ts:{val:18446744073709551615, v:3}, log_ts:{val:18446744073709551615, v:3}, lsn:{lsn:18446744073709551615}, submit_ts:0}, this:0x7fcb4ab564d0, is_inited_:true, trans_id:{txid:1000469}, ls_id:{id:1002}, ctx:0x7fcb4ab53550, tx_data_guard:{tx_data:NULL}, is_callbacked_:false, is_dynamic_:false, mds_range_:{range_array_.count():0, range_array_:[]}, cb_arg_array_:[], first_part_scn_:{val:18446744073709551615, v:3}}, ctx_tx_data_:{ctx_mgr_:0x7fcb23e04030, tx_data_guard_:{tx_data:{tx_id:{txid:1000469}, ref_cnt:1, state:“RUNNING”, commit_version:{val:18446744073709551615, v:3}, start_scn:{val:1704953134552897715, v:0}, end_scn:{val:18446744073709551615, v:3}, undo_status_list:{head:null, undo_node_cnt:0{}}}}, read_only_:false}, role_state_:0, start_replay_ts_:{val:18446744073709551615, v:3}, start_recover_ts_:{val:18446744073709551615, v:3}, is_incomplete_replay_ctx_:false, mt_ctx_:{ObIMvccCtx={alloc_type=0 ctx_descriptor=0 min_table_version=0 max_table_version=1704952847072552 trans_version={val:4611686018427387903, v:0} commit_version={val:0, v:0} lock_wait_start_ts=0 replay_compact_version={val:0, v:0}} end_code=0 tx_status=0 is_readonly=false ref=0 trans_id={txid:1000469} ls_id=1002 callback_alloc_count=143079 callback_free_count=143079 checksum=0 tmp_checksum=2846689418 checksum_scn={val:1704953790925631745, v:0} redo_filled_count=143087 redo_sync_succ_count=143087 redo_sync_fail_count=0 main_list_length=0 unsynced_cnt=0 unsubmitted_cnt_=0 cb_statistics:[main=143087, slave=0, merge=0, tx_end=0, rollback_to=0, fast_commit=140082, remove_memtable=3005]}, coord_prepare_info_arr_:[], upstream_state:10, retain_cause:-1, 2pc_role:-1, collected:[], ref:2, rec_log_ts:{val:18446744073709551615, v:3}, prev_rec_log_ts:{val:18446744073709551615, v:3}, lastest_snapshot:{val:18446744073709551615, v:3}, state_info_array:[], last_request_ts:1704953771219240, block_frozen_memtable:null})

建议:

  1. 发测试租户的 资源规格。
SELECT tenant_id, ZONE,svr_ip,max_cpu,min_cpu,round(memory_size/1024/1024/1024) mem_gb,max_iops,round(log_disk_size/1024/1024/1024) log_size_gb FROM `GV$OB_UNITS` ;
  1. 发一下 benchmarksql 的测试配置文件 props.xxx 。

感谢,已经解决了,是物理机器的磁盘io_write_wtite 太高导致的,更换了磁盘。