概述

本文主要分享針對(duì)想壓測(cè)OceanBase時(shí)需要了解的一些技術(shù)原理。這些建議可以幫助用戶對(duì)OceanBase做一些調(diào)優(yōu)，再結(jié)合測(cè)試程序快速找到適合業(yè)務(wù)的最佳性能。由于OceanBase自身參數(shù)很多、部署形態(tài)也比較靈活，這里并沒有給出具體步驟。

數(shù)據(jù)庫讀寫特點(diǎn)

壓測(cè)的本質(zhì)就是對(duì)一個(gè)會(huì)話的邏輯設(shè)計(jì)很高的并發(fā)。首先需要了解單個(gè)會(huì)話在數(shù)據(jù)庫內(nèi)部的讀寫邏輯。比如說，業(yè)務(wù)會(huì)話1對(duì)數(shù)據(jù)庫發(fā)起一個(gè)DML SQL，第一次修改某筆記錄，數(shù)據(jù)庫會(huì)怎么做呢？

為了便于理解OB的行為，我們先看看ORACLE是怎么做的。后面有對(duì)比才可以加深理解。

ORACLE 讀寫特點(diǎn)

ORACLE會(huì)話第一次修改一行記錄，如果該記錄所在塊(8K大小)不在內(nèi)存(Buffer Cache)里時(shí)會(huì)先從磁盤文件里讀入到內(nèi)存里。這個(gè)稱為一次物理讀，為了性能考慮，ORACLE一次會(huì)連續(xù)讀取相鄰的多個(gè)塊。然后就直接在該塊上修改，修改之前會(huì)先記錄REDO和UNDO(包括UNDO的REDO)。然后這個(gè)數(shù)據(jù)塊就是臟塊(Dirty Block)。假設(shè)事務(wù)沒有提交，其他會(huì)話又來讀取這個(gè)記錄，由于隔離級(jí)別是讀已提交(READ COMMITTED),ORACLE會(huì)在內(nèi)存里克隆當(dāng)前數(shù)據(jù)塊到新的位置，新塊包含了最新的未提交數(shù)據(jù)。然后ORACLE在新塊上逆向應(yīng)用UNDO鏈表中的記錄，將數(shù)據(jù)塊回滾到讀需要的那個(gè)版本(SCN)，然后才能讀。這個(gè)也稱為一次一致性讀(Consistency Read)，這個(gè)新塊也稱為CR塊。

即使是修改一條記錄一個(gè)字段的幾個(gè)字節(jié)，整個(gè)塊(8K大小)都會(huì)是臟塊。隨著業(yè)務(wù)持續(xù)寫入，大量臟塊會(huì)消耗數(shù)據(jù)庫內(nèi)存。所以O(shè)RACLE會(huì)有多重機(jī)制刷臟塊到磁盤數(shù)據(jù)文件上。在事務(wù)日志切換的時(shí)候也會(huì)觸發(fā)刷臟塊操作。如果業(yè)務(wù)壓力測(cè)試ORACLE，大量的寫導(dǎo)致事務(wù)日志切換很頻繁，對(duì)應(yīng)的刷臟操作可能相對(duì)慢了，就會(huì)阻塞日志切換，也就阻塞了業(yè)務(wù)寫入。這就是ORACLE的特點(diǎn)。解決辦法就是加大事務(wù)日志文件，增加事務(wù)日志成員或者用更快的磁盤存放事務(wù)日志和數(shù)據(jù)文件。

ORACLE里一個(gè)表就是一個(gè)Segment(如果有大對(duì)象列還會(huì)有獨(dú)立的Segment，這個(gè)先忽略)，Segment由多個(gè)不一定連續(xù)的extent組成，extent由連續(xù)的Block(每個(gè)大小默認(rèn)8K)組成，extent缺點(diǎn)是可能會(huì)在后期由于頻繁刪除和插入產(chǎn)生空間碎片。

OceanBase 讀寫特點(diǎn)

OceanBase會(huì)話第一次修改一行記錄，如果該記錄所在塊(64K大小)不在內(nèi)存(Block Cache)里時(shí)也會(huì)先從磁盤文件里讀入到內(nèi)存里。這個(gè)稱為一次物理讀。然后要修改時(shí)跟ORACLE做法不同的是，OceanBase會(huì)新申請(qǐng)一小塊內(nèi)存用于存放修改的內(nèi)容，并且鏈接到前面Block Cache里該行記錄所在塊的那筆記錄下。如果修改多次，每次修改都跟前面修改以鏈表形式關(guān)聯(lián)。同樣在修改之前也要先在內(nèi)存里記錄REDO。每次修改都會(huì)記錄一個(gè)內(nèi)部版本號(hào)，記錄的每個(gè)版本就是一個(gè)增量。其他會(huì)話讀取的時(shí)候會(huì)先從Block Cache中該記錄最早讀入的那個(gè)版本(稱為基線版本)開始讀，然后疊加應(yīng)用后面的增量版本直到合適的版本(類似ORACLE中SCN概念)。(隨著版本演進(jìn)，這里細(xì)節(jié)邏輯可能會(huì)有變化。)

OB的這個(gè)讀方式簡單說就是從最早的版本讀起，逐步應(yīng)用增量(類似REDO，但跟REDO日志無關(guān))。而ORACLE一致性讀是從最新的版本讀起，逐步回滾(應(yīng)用UNDO)。在OB里，沒有UNDO。當(dāng)版本鏈路很長時(shí)，OB的讀性能會(huì)略下降，所以O(shè)B也有個(gè)checkpoint線程定時(shí)將記錄的多個(gè)版本合并為少數(shù)幾個(gè)版本。這個(gè)合并稱為小合并(minor compaction)。此外，OB在內(nèi)存里針對(duì)行記錄還有緩存，

從上面過程還可以看出，每次修改幾個(gè)字節(jié)，在內(nèi)存里的變臟的塊只有增量版本所在的塊(默認(rèn)寫滿才會(huì)重新申請(qǐng)內(nèi)存)，基線數(shù)據(jù)塊是一直不變化。所以O(shè)B里臟塊產(chǎn)生的速度非常小，臟塊就可以在內(nèi)存里保存更久的時(shí)間。實(shí)際上OB的設(shè)計(jì)就是臟塊默認(rèn)不刷盤。那如果機(jī)器掛了，會(huì)不會(huì)丟數(shù)據(jù)呢？

OB跟ORACLE一樣，修改數(shù)據(jù)塊之前會(huì)先記錄REDO，在事務(wù)提交的時(shí)候，REDO要先寫到磁盤上(REDO同時(shí)還會(huì)發(fā)送往其他兩個(gè)副本節(jié)點(diǎn)，這個(gè)先忽略)。有REDO在，就不怕丟數(shù)據(jù)。此外，增量部分每天還是會(huì)落盤一次。在落盤之前，內(nèi)存中的基線數(shù)據(jù)和相關(guān)的增量數(shù)據(jù)會(huì)在內(nèi)存里進(jìn)行一次合并(稱Merge)，最終以SSTable的格式寫回到磁盤。如果說內(nèi)存里塊內(nèi)部產(chǎn)生碎片，在合并的那一刻，這個(gè)碎片空間基本被消弭掉了。所以說OB的數(shù)據(jù)文件空間碎片很小，不需要做碎片整理。同時(shí)OB的這個(gè)設(shè)計(jì)也極大降低了LSM的寫放大問題。

當(dāng)業(yè)務(wù)壓測(cè)寫OB時(shí)，臟塊的量也會(huì)增長，最終達(dá)到增量內(nèi)存限制，這時(shí)候業(yè)務(wù)就無法寫入，需要OB做合并釋放內(nèi)存。OB的合并比較耗IO、CPU(有參數(shù)可以控制合并力度)，并且也不會(huì)等到內(nèi)存用盡才合并，實(shí)際會(huì)設(shè)置一個(gè)閾值。同時(shí)為了規(guī)避合并，設(shè)計(jì)了一個(gè)轉(zhuǎn)儲(chǔ)機(jī)制。當(dāng)增量內(nèi)存使用率超過閾值后，就開啟轉(zhuǎn)儲(chǔ)。轉(zhuǎn)儲(chǔ)就是直接把增量內(nèi)存寫到磁盤上(不合并)。轉(zhuǎn)儲(chǔ)對(duì)性能的影響很小，可以高峰期發(fā)生，并且可以轉(zhuǎn)儲(chǔ)多次(參數(shù)配置)。

OB增量內(nèi)存就類似一個(gè)水池，業(yè)務(wù)寫是進(jìn)水管在放水， 轉(zhuǎn)儲(chǔ)和大合并是出水管。水位就是當(dāng)前增量內(nèi)存使用率。當(dāng)進(jìn)水的速度快于出水，池子可能就會(huì)滿。這時(shí)候業(yè)務(wù)寫入就會(huì)報(bào)內(nèi)存不足的錯(cuò)誤。
這就是OB讀寫的特點(diǎn)，解決方法就是加大OB內(nèi)存、或者允許OB自動(dòng)對(duì)業(yè)務(wù)寫入速度限流。

OceanBase部署建議

OB 在commit的時(shí)候redo落盤會(huì)寫磁盤。讀數(shù)據(jù)的時(shí)候內(nèi)存未命中的時(shí)候會(huì)有物理讀，轉(zhuǎn)儲(chǔ)和大合并的時(shí)候落盤會(huì)有密集型寫IO。這些都依賴磁盤讀寫性能。所以建議磁盤都是SSD盤，并且建議日志盤和數(shù)據(jù)盤使用獨(dú)立的文件系統(tǒng)。如果是NVME接口的閃存卡或者大容量SSD盤，那日志盤和數(shù)據(jù)盤放在一起也可以。不要使用LVM對(duì)NVME接口的大容量SSD做劃分，那樣瓶頸可能會(huì)在LVM自身。

OB的增量通常都在內(nèi)存里，內(nèi)存不足的時(shí)候會(huì)有轉(zhuǎn)儲(chǔ)，可以轉(zhuǎn)儲(chǔ)多次。盡管如此，建議測(cè)試機(jī)器的內(nèi)存不要太小，防止頻繁的增量轉(zhuǎn)儲(chǔ)。通常建議192G內(nèi)存以上。

OB集群的節(jié)點(diǎn)數(shù)至少要有三個(gè)。如果是功能了解，在單機(jī)上起3個(gè)OB進(jìn)程模擬三節(jié)點(diǎn)是可以的，但是如果是性能測(cè)試，那建議還是使用三臺(tái)同等規(guī)格的物理機(jī)比較合適。機(jī)器規(guī)格不一致時(shí)，最小能力的機(jī)器可能會(huì)制約整個(gè)集群的性能。 OceanBase集群的手動(dòng)部署請(qǐng)參考《OceanBase數(shù)據(jù)庫實(shí)踐入門——手動(dòng)搭建OceanBase集群》。在部署好OceanBase之后，建議先簡單了解一下OceanBase的使用方法，詳情請(qǐng)參考文章《OceanBase數(shù)據(jù)庫實(shí)踐入門——常用操作SQL》。

如果要驗(yàn)證OB的彈性縮容、水平擴(kuò)展能力，建議至少要6節(jié)點(diǎn)(部署形態(tài)2-2-2)。并且測(cè)試租戶(實(shí)例)的每個(gè)Zone里的資源單元數(shù)量至少也要為2個(gè)，才可以發(fā)揮多機(jī)能力。這是因?yàn)镺B是多租戶設(shè)計(jì)，對(duì)資源的管理比較類似云數(shù)據(jù)庫思想，所以里面設(shè)計(jì)有點(diǎn)精妙，詳情請(qǐng)參見《揭秘OceanBase的彈性伸縮和負(fù)載均衡原理》。

下面是一個(gè)租戶的測(cè)試租戶資源初始化建議

• 登錄sys租戶

create resource unit S1, max_cpu=2, max_memory='10G', min_memory='10G', max_iops=10000, min_iops=1000, max_session_num=1000000, max_disk_size=536870912; create resource unit S2, max_cpu=4, max_memory='20G', min_memory='20G', max_iops=20000, min_iops=5000, max_session_num=1000000, max_disk_size=1073741824; create resource unit S3, max_cpu=8, max_memory='40G', min_memory='40G', max_iops=50000, min_iops=10000, max_session_num=1000000, max_disk_size=2147483648; select * from __all_unit_config;create resource pool pool_demo unit = 'S2', unit_num = 2; select * from __all_resource_pool order by resource_pool_id desc ;create tenant t_obdemo resource_pool_list=('pool_demo'); alter tenant t_obdemo set variables ob_tcp_invited_nodes='%';

請(qǐng)注意上面的unit_num=2這個(gè)很關(guān)鍵。如果unit_num=1，OB會(huì)認(rèn)為這個(gè)租戶是個(gè)小租戶，后面負(fù)載均衡處理時(shí)會(huì)有個(gè)默認(rèn)規(guī)則。

• 登錄業(yè)務(wù)租戶

create database sbtest; grant all privileges on sbtest.* to sbuser@'%' identified by 'sbtest';

sysbench壓測(cè)建議

因?yàn)闇y(cè)試場景跟業(yè)務(wù)有關(guān)，這里就以常見的sysbench場景舉例分析

sysbench工具可以建幾個(gè)結(jié)構(gòu)相同的表，然后執(zhí)行純讀、純寫、讀寫混合。其中讀又分根據(jù)主鍵或者二級(jí)索引查詢，等值查詢、IN查詢或范圍查詢幾種。詳細(xì)的可以查看官方介紹。

如果用sysbench壓測(cè)OB，創(chuàng)建很多表是一種方法。另外一種方法就是創(chuàng)建分區(qū)表。OceanBase是分布式數(shù)據(jù)庫，數(shù)據(jù)遷移和高可用的最小粒度是分區(qū)，分區(qū)是數(shù)據(jù)表的子集。分區(qū)表有多個(gè)分區(qū)，非分區(qū)表只有一個(gè)分區(qū)。分區(qū)表的拆分細(xì)節(jié)是業(yè)務(wù)可以定義的。OceanBase可以將多個(gè)分區(qū)分布到不同節(jié)點(diǎn)，也可能不會(huì)分布到多個(gè)節(jié)點(diǎn)。這個(gè)取決于OB集群和租戶的規(guī)劃設(shè)計(jì)。所以對(duì)sysbench創(chuàng)建的表(分區(qū))，在性能分析時(shí)要分析分區(qū)具體的位置。

建表準(zhǔn)備

下面是sysbench里分區(qū)表示例，修改 oltp_common.lua:

query = string.format([[ CREATE TABLE sbtest%d(id %s,k INTEGER DEFAULT '0' NOT NULL,c CHAR(120) DEFAULT '' NOT NULL,pad CHAR(60) DEFAULT '' NOT NULL,%s (id,k) ) partition by hash(k) partitions %s %s %s]],table_num, id_def, id_index_def, part_num, engine_def, extra_table_options)

需要注意用分區(qū)表后，主鍵列和唯一索引列需要包含分區(qū)鍵。分區(qū)表的索引有本地(LOCAL)索引和全局索引兩種。本地索引的存儲(chǔ)跟數(shù)據(jù)是在一起的，全局索引的存儲(chǔ)是獨(dú)立的。全局索引是為了應(yīng)對(duì)查詢條件不是分區(qū)鍵的場景，沒有全局索引時(shí)，會(huì)掃描所有分區(qū)的本地索引。這兩種索引的性能優(yōu)劣沒有定論，以實(shí)際業(yè)務(wù)場景測(cè)試為準(zhǔn)。此外，傳統(tǒng)數(shù)據(jù)庫索引對(duì)修改操作會(huì)有負(fù)面影響，分布式數(shù)據(jù)庫的全局索引對(duì)修改操作的影響可能更大，因?yàn)橐粋€(gè)簡單的DML語句都會(huì)因?yàn)橐叫薷娜炙饕a(chǎn)生分布式事務(wù)。而本地索引就沒有分布式事務(wù)問題。所以對(duì)全局索引的使用場景要謹(jǐn)慎評(píng)估。這個(gè)特性不是OB特有，只要是分布數(shù)據(jù)庫都會(huì)面臨這個(gè)問題。

數(shù)據(jù)分布均衡

本節(jié)是說明OB數(shù)據(jù)分布背后的原理和方法。

OceanBase是分布式數(shù)據(jù)庫，它通過每個(gè)機(jī)器上的observer進(jìn)程將多個(gè)機(jī)器的資源能力聚合成一個(gè)大的資源池，然后再為每個(gè)業(yè)務(wù)分配不同資源規(guī)格的租戶(實(shí)例)。所以每個(gè)業(yè)務(wù)租戶(實(shí)例)的資源能力都只是整個(gè)集群能力的子集。業(yè)務(wù)并不一定能使用到全部機(jī)器資源。

OceanBase里的數(shù)據(jù)都有三份，細(xì)到每個(gè)分區(qū)有三個(gè)副本，角色上有1個(gè)leader副本2個(gè)follower副本。默認(rèn)只有l(wèi)eader副本提供讀寫服務(wù)，leader副本所在的節(jié)點(diǎn)才有可能提供服務(wù)，有負(fù)載。OceanBase調(diào)整各個(gè)節(jié)點(diǎn)負(fù)載的方法是通過調(diào)整內(nèi)部leader副本的位置實(shí)現(xiàn)的。這個(gè)調(diào)整可以讓OceanBase自動(dòng)做，也可以手動(dòng)控制。

OceanBase自動(dòng)負(fù)載均衡是參數(shù)enable_rebalance控制，默認(rèn)值為True。可以查看確認(rèn)。修改用alter system語句。

alter system set enable_rebalance=True; show parameters like 'enable_rebalance';

查看實(shí)際表的分區(qū)leader副本位置

##查看分區(qū)分布 SELECT t5.tenant_id,t5.tenant_name,t3.database_name, t4.tablegroup_name, t2.table_name, t1.partition_id, concat(t1.svr_ip,':',t1.svr_port) observer, t1.role, t1.data_size,t1.row_count from `gv$partition` t1 join `__all_table` t2 on (t1.tenant_id=t2.tenant_id and t1.table_id=t2.table_id)join `__all_database` t3 on (t2.tenant_id=t3.tenant_id and t2.database_id=t3.database_id)left join `__all_tablegroup` t4 on (t1.tenant_id=t4.tenant_id and t1.tablegroup_id=t4.tablegroup_id)join `__all_tenant` t5 on (t1.tenant_id=t5.tenant_id) where t5.tenant_id = 1020 and role=1 and database_name in ('sysbenchtest') order by t5.tenant_id,t3.database_id,t1.tablegroup_id,t1.partition_id, t1.role;

sysbench命令參數(shù)

sysbench的機(jī)制是壓測(cè)過程中如果有錯(cuò)誤就會(huì)報(bào)錯(cuò)退出，所以需要針對(duì)一些常見的錯(cuò)誤進(jìn)行忽略處理，這樣sysbench會(huì)話可以重試?yán)^續(xù)運(yùn)行。比如說主鍵或者唯一鍵沖突、事務(wù)被殺等等。
下面的運(yùn)行命令供參考

• 初始化

./sysbench --test=./oltp_read_only.lua --mysql-host=***.***.82.173 --mysql-port=4001 --mysql-db=test --mysql-user="sbuser" --mysql-password=sbtest --tables=16 --table_size=100000000 --threads=32 --time=300 --report-interval=5 --db-driver=mysql --db-ps-mode=disable --skip-trx=on --mysql-ignore-errors=6002,6004,4012,2013,4016 prepare

• 純讀

./sysbench --test=./oltp_read_only.lua --mysql-host=***.***.82.173 --mysql-port=4001 --mysql-db=test --mysql-user="sbuser" --mysql-password=sbtest --tables=16 --table_size=100000000 --threads=96 --time=600 --db-driver=mysql --db-ps-mode=disable --skip-trx=on --mysql-ignore-errors=6002,6004,4012,2013,4016 --secondary=on run

• 純寫

./sysbench --test=./oltp_write_only.lua --mysql-host=***.***.82.173 --mysql-port=4001 --mysql-db=test --mysql-user="sbuser" --mysql-password=sbtest --tables=16 --table_size=100000000 --threads=32 --time=600 --report-interval=5 --db-driver=mysql --db-ps-mode=disable --skip-trx=on --mysql-ignore-errors=6002,6004,4012,2013,4016,1062 run

• 讀寫混合

./sysbench --test=./oltp_read_write.lua --mysql-host=***.***.82.173 --mysql-port=4001 --mysql-db=test --mysql-user="sbuser" --mysql-password=sbtest --tables=16 --table_size=100000000 --threads=32 --time=600 --report-interval=5 --db-driver=mysql --db-ps-mode=disable --skip-trx=on --mysql-ignore-errors=6002,6004,4012,2013,4016,1062 run

測(cè)試觀察

在純寫或者讀寫測(cè)試中，注意觀察增量增量內(nèi)存使用進(jìn)度。如果寫入速度比轉(zhuǎn)儲(chǔ)和合并速度還快，那會(huì)碰到內(nèi)存不足寫入失敗錯(cuò)誤。這就是OB租戶資源相對(duì)不足了。觀察這個(gè)內(nèi)存使用進(jìn)度可以通過 dooba腳本。dooba腳本默認(rèn)在/home/admin/oceanbase/bin/目錄下。
使用示例如下：

python dooba -h11..84.84 -uroot@sys#obdemo -P2883 -p**

OB有個(gè)內(nèi)部視圖gv$sql_audit可以查看執(zhí)行過所有成功或失敗的SQL，用來分析具體的SQL性能。用法詳情參見官網(wǎng)(oceanbase.alipay.com) 或 文章《阿里數(shù)據(jù)庫性能診斷的利器——SQL全量日志》。

select /*+ read_consistency(weak) query_timeout(1000000000) */ usec_to_time(request_time) req_time, svr_Ip, trace_id, sid, client_ip, tenant_id,tenant_name,user_name,db_name, query_sql, affected_rows,ret_code, event, state, elapsed_time, execute_time, queue_time, decode_time, get_plan_time, block_cache_hit, bloom_filter_cache_Hit, block_index_cache_hit, disk_reads,retry_cnt,table_scan, memstore_read_row_count, ssstore_read_row_count, round(request_memory_used/1024/1024) req_mem_mb from gv$sql_audit where tenant_id=1012 and user_name in ('demouser') order by request_time desc limit 100;

經(jīng)驗(yàn)總結(jié)

本節(jié)是一些測(cè)試場景的經(jīng)驗(yàn)總結(jié)，需要提前了解一些OceanBase的原理特性介紹。

實(shí)際測(cè)試情形可能會(huì)出現(xiàn)由于是三節(jié)點(diǎn)部署，所以測(cè)試時(shí)壓力都打到一臺(tái)服務(wù)器上，這個(gè)建議用六節(jié)點(diǎn)測(cè)試。還有個(gè)辦法就是禁用自動(dòng)負(fù)載均衡手動(dòng)調(diào)整分區(qū)位置。調(diào)整是OB給業(yè)務(wù)的手段，業(yè)務(wù)上有些表會(huì)有JOIN，為了性能(避免跨節(jié)點(diǎn)請(qǐng)求)，業(yè)務(wù)需要這種干預(yù)能力。

還有一種情形是寫入壓力非常大，跑了一段時(shí)間后報(bào)內(nèi)存不足的提示，這個(gè)就是租戶內(nèi)存資源相對(duì)寫入速度和量不足了(OB的轉(zhuǎn)儲(chǔ)和合并對(duì)內(nèi)存的回收趕不上寫入對(duì)內(nèi)存的消耗)，此時(shí)需要擴(kuò)容或者調(diào)整測(cè)試需求。OB 2.x版本還有自動(dòng)對(duì)應(yīng)用寫入限速功能(自我保護(hù))，這個(gè)會(huì)影響測(cè)試報(bào)告里性能結(jié)果。如果數(shù)據(jù)庫分析sql性能以及分布式調(diào)優(yōu)都做了，那可以認(rèn)為當(dāng)前寫入的TPS就是數(shù)據(jù)庫的寫入峰值了。需要注意的是不同的硬件，不同的租戶規(guī)格，不同的測(cè)試場景，這個(gè)TPS能力都表現(xiàn)不同。

sysbench有個(gè)batch insert功能，當(dāng)表是分區(qū)表的時(shí)候，默認(rèn)這個(gè)batch insert 很可能會(huì)產(chǎn)生分布式事務(wù)，性能比單表寫入要慢。需要靠提高客戶端并發(fā)數(shù)來提升總的吞吐量。此外這個(gè)批量的大小不宜太大。由于OB支持SQL執(zhí)行計(jì)劃緩存，SQL文本過大且并發(fā)很高時(shí)，會(huì)在SQL解析環(huán)節(jié)面臨內(nèi)存不足問題。數(shù)據(jù)庫內(nèi)存的大部分還是主要用于存取數(shù)據(jù)。JAVA的addBatch方法也同理，建議批量大小設(shè)置為100以內(nèi)。

在查詢驗(yàn)證數(shù)據(jù)的時(shí)候，可能會(huì)碰到超時(shí)類錯(cuò)誤。OB里超時(shí)的可能場景有多個(gè)：

• SQL語句超時(shí)，由租戶變量 ob_query_timeout控制。單位是微秒，默認(rèn)是10秒。
• 事務(wù)空閑超時(shí)，由租戶變量 ob_trx_idle_timeout控制。單位是微秒，默認(rèn)120秒。
• 事務(wù)超時(shí)，由租戶變量 ob_trx_timeout控制。單位是微秒，默認(rèn)100秒。

以上超時(shí)時(shí)間都可以在租戶里根據(jù)實(shí)際情況修改。

其他

關(guān)于使用分布式數(shù)據(jù)庫測(cè)試，不同的做法可以得到不同的結(jié)果。即使是同一個(gè)OB租戶(實(shí)例)，不同的人設(shè)計(jì)的表結(jié)構(gòu)不同，或者SQL不同都有可能取得不同的性能數(shù)據(jù)。這些不同都是可以從原理上給出解釋。熟知這些原理的更容易發(fā)揮OB的分布式數(shù)據(jù)庫特點(diǎn)。使用越深入會(huì)發(fā)現(xiàn)這個(gè)原理越多且更加有趣。當(dāng)然環(huán)境、場景的不同，還是會(huì)遇到一些問題。如果有碰到問題，歡迎公眾號(hào)留言討論。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的OceanBase数据库实践入门——性能测试建议的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。