国产海光与鲲鹏服务器CPU性能瓶颈及OceanBase优化方案解析

服务器性能测试及调优在技术界备受关注。国产数据库与Intel服务器的性能有何不同？OceanBase在不同应用场景中应如何进行优化？让我们来共同分析讨论。

CREATE PROCEDURE test_cpu
IS
 test_power     number;
g_start number;
second_run number;
BEGIN
g_start:= dbms_utility.get_time;
  for v in 1..1000000 loop
    select power(32,64) 
    into test_power
    from dual;
  end loop;
second_run:=(dbms_utility.get_time-g_start);
 dbms_output.put_line('cpu耗时（厘秒）：'||second_run);
END test_cpu;
/

服务器性能测试对比

先来查看一下服务器的性能测试结果。以Intel服务器和一家国产数据库服务器为例，Intel服务器完成一个存储过程大约需要13.739秒，而那家国产数据库服务器则需要大约25.921秒。一对比之下，我们发现Intel服务器的CPU性能大约是国产服务器的CPU性能的1.96倍，这表明国产服务器CPU的性能与Intel存在显著差距。因此，那些在Intel服务器CPU上消耗较大的SQL操作，一旦迁移到国产服务器，可能会遇到性能上的问题。

OceanBase 逻辑核处理能力

select dispatchta0_.id as id1_53_, dispatchta0_.bo_actual_id as bo_actual_id2_53_, dispatchta0_.claim_variable_id as claim_variable_id3_53_, 
dispatchta0_.create_time as create_time4_53_, dispatchta0_.memo as memo5_53_, dispatchta0_.message as message6_53_, 
dispatchta0_.notification_no as notification_no7_53_, dispatchta0_.proc_inst_id as proc_inst_id8_53_, dispatchta0_.status as status9_53_, 
dispatchta0_.task_def_key as task_def_key10_53_, dispatchta0_.task_id as task_id11_53_, dispatchta0_.task_variable_id as 
task_variable_id12_53_, dispatchta0_.top_actual_id as top_actual_id13_53_, dispatchta0_.update_time as update_time14_53_ from BPM_DISPATCH_TASK_PARA 
dispatchta0_ where 1=1 and dispatchta0_.status='0' and mod(dispatchta0_.top_actual_id, 13)=4 and rownum<100 order by dispatchta0_.id asc

我们来讨论一下OceanBase服务器的逻辑核处理能力。以Intel的64核x86服务器为例，得考虑到Proxy、sys租户和操作系统带来的额外负担，同时CPU使用率需保持在70%以下，这样大概可以维持在70000QPS或7000TPS的水平。若QPS或TPS中任一数值超出单服务器CPU的承载极限，就需要考虑对应用架构及代码进行优化，或者借助OceanBase的分布式特性进行分布式架构设计。

|ID|OPERATOR                   |NAME        |EST. ROWS|COST |
-------------------------------------------------------------
|0 |SORT                       |            |1        |20728|
|1 | SUBPLAN SCAN              |VIEW1       |1        |20728|
|2 |  LIMIT                    |            |1        |20728|
|3 |   PX COORDINATOR          |            |1        |20728|
|4 |    EXCHANGE OUT DISTR     |:EX10000    |1        |20728|
|5 |     LIMIT                 |            |1        |20728|
|6 |      PX PARTITION ITERATOR|            |1        |20728|
|7 |       TABLE SCAN          |DISPATCHTA0_|1        |20728|
=============================================================
|DISPATCHTA0_:table_rows:32, physical_range_rows:52480, logical_range_rows:32,

OceanBase 删除机制影响

ALTER TABLE user_table TABLE_MODE = 'queuing';

OceanBase 删除表记录的过程与众不同。在删除记录时，它并不会立即进行物理删除，而是仅在内存中为相应记录添加删除标识。只有等到 OceanBase 每日进行数据合并时，这些记录才会被真正删除。因此，在进行表调度任务参数表的全量扫描时，会扫描到大量已被标记为删除的记录，这直接导致了查询性能的显著降低。因此，在应用 OceanBase 构建表格和处理数据时，这一点必须被考虑在内。

extended select runtimeuse0_.id as id1_68_, runtimeuse0_.dispatch_task_type as dispatch_task_type2_68_, runtimeuse0_.task_def_key as 
task_def_key3_68_, runtimeuse0_.task_state as task_state4_68_, runtimeuse0_.task_variable_id as task_variable_id5_68_, 
runtimeuse0_.task_weight as task_weight6_68_, runtimeuse0_.unit_code as unit_code7_68_, runtimeuse0_.user_code as user_code8_68_, 
runtimeuse0_.user_group as user_group9_68_, runtimeuse0_.count as count10_68_, runtimeuse0_.create_time as create_time11_68_, 
runtimeuse0_.memo as memo12_68_, runtimeuse0_.status as status13_68_, runtimeuse0_.update_time as update_time14_68_ 
    -> from bpm.BPM_USER_TASKCOUNT_DETAIL runtimeuse0_ 
    -> where 1=1 and runtimeuse0_.status='0' and rownum<1000 
    -> order by runtimeuse0_.id ascG

AP 场景性能挑战

|ID|OPERATOR                   |NAME        |EST. ROWS|COST |
-------------------------------------------------------------
|0 |SORT                       |            |918      |44164|
|1 | SUBPLAN SCAN              |VIEW1       |918      |42233|
|2 |  LIMIT                    |            |918      |42219|
|3 |   PX COORDINATOR          |            |918      |42205|
|4 |    EXCHANGE OUT DISTR     |:EX10000    |918      |39576|
|5 |     LIMIT                 |            |918      |39576|
|6 |      PX PARTITION ITERATOR|            |918      |39562|
|7 |       TABLE SCAN          |RUNTIMEUSE0_|918      |39562|

在AP环境下，处理数据时常常面临海量的信息，挑战不少。数据量庞大，SQL操作逻辑复杂，子查询和外连接频繁使用，还涉及PL特性。这要求技术人员具备高超的SQL优化技巧。他们必须拥有丰富的优化经验和专业技能，才能有效应对SQL优化的复杂任务，确保服务器性能最佳。

标量子查询优化策略

标量子查询优化对于提升性能至关重要。将成本较高的标量子查询改为外连接后，性能可提高20%至30%。在Oracle 9版本中，人们常利用标量子查询优化外连接性能。然而，尽管OceanBase支持标量子查询，其性能通常不如外连接。因此，在将数据库从Oracle迁移至OceanBase的过程中，将原子查询转换为外部连接，是一种有效的逆向优化策略。这样做能够有效提高数据库的整体运行效率。

create index status_idx on BPM_USER_TASKCOUNT_DETAIL(case deleted_status when ‘0’ then ‘0’    end);

不同场景优化手段

Where status=’0’ and (case deleted_status when ‘0’ then ‘0’    end)=’0’

不同情境下，优化策略各有不同。当国产服务器CPU性能难以显著提高时，在处理大量高并发场景时，通常会采取索引设计优化和queuing表设计来提升效率；而在处理海量数据加工时，则常通过改进标量子查询和外连接、优化虚拟表处理inlist问题、优化索引设计、将全局索引改为本地索引以提升并发性能、以及清理冗余索引来优化DML操作的性能。合理用这些优化手段能提升数据库系统整体性能和稳定性。

在工作中，你是否遇到过类似提升服务器性能的挑战？若觉得本文对你有帮助，别忘了点赞和转发！

UPDATE fssc_expensebillline_ods SET status = 'S' WHERE BATCHNO = 
'JB_EXPENSEBILL_W60827207_20231118_020908_03588e523ef244efae82ff5cf619565e'

|ID|OPERATOR  |NAME                    |EST. ROWS|COST   |
----------------------------------------------------------
|0 |TABLE SCAN|FSSC_EXPENSEBILLLINE_ODS|140485   |5576337|
FSSC_EXPENSEBILLLINE_ODS:table_rows:14190397, physical_range_rows:14194466, logical_range_rows:14190397, index_back_rows:0, 
output_rows:140484, est_method:local_storage, optimization_method=cost_based, |7 |       TABLE SCAN          |RUNTIMEUSE0_|918      |39562|

发表评论 取消回复

发表评论取消回复