调优#

`magma-site.xml` 关键参数配置说明#

nbuffers

配置 btree 使用的buffer pool中buffer的数目（page默认16K)。其主要目的在于将 index，已删除数据等尽可能缓存在内存中。这是 Magma 中目前内存消耗最大的配置项。对于重在测试index查询，以及update/delete比较频繁的场景，需要将该参数调大。

实际情况还需要结合机器的内存进行合理配置。理论上配置越大越好，因为我们总是希望将尽可能多的数据放入内存中。根据机器的内存，可以分为3档：

机器内存	配置项数值
0~32g	nBuffers = 10240(大约每个rg配置160MB) 对于索引比较多，update/delete比较频繁一类的OLTP场景，可以调大该配置
32g ~ 256g	nBuffers = 102400 (大约每个rg配置1.6GB)
256g 以上	nBuffers = 204800(大约每个rg配置3.2GB)

注：具体过程中遇到问题时，根据机器的总内存量，副本数目，并发数，适当调整该配置。

shared_buffer_size_per_table_per_range

等同于 HDFS 中的块大小，单位是 Byte, 是 Magma AP 表存储压缩的最小单位，小于这个大小的数据，通常会存储在内存中；这个参数对于TP、AP场景比较敏感。AP场景不低于4MB，TP场景不超过4MB。

shared_buffer_size_max_per_table_per_range

在AP型场景中，不乏有宽表存在，很快就会超过前面设定的块大小（shared_buffer_size_per_table_per_range），但是这时候可能缓存的block内部行数还很少，压缩解压带来的性价比不高，所以需要积累行数，但是不能超过这个上限值。一旦到达这个上限，必然会触发压缩写。AP型场景不超过32MB, TP型场景不超过8MB。

shared_buffer_min_tuples

单个存储block内的最少行数，如果行数太少，会导致大表的block数目过多，从而影响IO性能。通常与shared_buffer_size_per_table_per_range 和 shared_buffer_size_max_per_table_per_range联动修改。

rpc_server_work_thread_num

配置 Magma 的 Meta Rg上的rpc服务的线程池大小,目前仅仅对 vsc_catalog 有作用，当并发的 rpc 服务超过线程池大小时就会出现等待。通常的 rpc 服务有 drop table, create index 等。建议配置成cpu的虚拟核数，或者可能的create index的最大并发数；经验参数：32。

shared_buffer_fixed_pool_size

类似nbuffers参数，该参数表示的是表数据的内存池中的buffer数目（单个buffer大小默认是128KB)。

该参数通常配置需要参考并发dml数目，以及内存限制。理论上配置越大越好，因为我们总是希望将尽可能多的数据放入内存中。根据机器的内存，可以分为3档：

机器内存	配置项数值
0~32g	shared_buffer_fixed_pool_size = 512(大约每个rg配置64MB, 可同时支撑约500个并发写) 如果实际的并发数较大，偏向OLTP类交易型场景，可以调大该配置
32g ~ 256g	shared_buffer_fixed_pool_size=10240(大约每个rg配置1.2GB)
256g以上	shared_buffer_fixed_pool_size=20480(大约每个rg配置2.4GB

注：具体过程中遇到问题时，根据机器的总内存量，副本数目，并发数，适当调整该配置。

Magma 内存规划公式#

通常计划将机器30%~50%（magma_reserved_ratio）的内存用于 Magma 配置，检测配置是否合理，可以按照如下公式计算：以单节点为例：

Total_Magma_Memory_Size = Size(Btree Buffer Pool) + Size(L0 Buffer Pool)

Size(Btree Buffer Pool) = num_ranges_pernode * num_replicates * nbuffers * 16K

Size(L0 Buffer Pool) = num_ranges_pernode * shared_buffer_fixed_pool_size * 128K

应该总是满足：
Total_Magma_Memory_Size <= Physical_Memory_Size * magma_reserved_ratio

这套公式能帮助我们：

在nbuffers等内核参数使用经验参数时，反推单个节点上应该配置多少个ranges
在性能调优等场景里，调整nbuffers等参数时，作为上限参考；

元数据集群配置参考#

元数据集群通常都是 index 查询，并且客户端 cache 都是以整行 tuple 为单位进行缓存的，所以针对 index 扫描的性能非常重要。调整index表现相关的的配置参数对于元数据集群的性能非常关键。

配置magma-topology.yaml

 - name: vsc_catalog
   nodes: m[1~3]
   port: 6666
   num_ranges: 3
   num_replicas: 3
   data_dir: /disk1/magma_catalog
   log_dir:
   replica_locations: "regionA.zoneA:3"
   leader_preferences: "regionA.zoneA"
   conf_path: /usr/local/oushu/conf/oushudb/vsc_catalog

配置magma-site.xml

    <property>
        <name>nbuffers</name>
        <value>204800</value>
        <description>The buffer number of buffer manager.</description>
    </property>

    <property>
        <name>shared_buffer_size_per_table_per_range</name>
        <value>4194304</value>
        <description>Ap L0 buffer size of per range per table. Unit: Bytes </description>
    </property>

    <property>
        <name>shared_buffer_size_max_per_table_per_range</name>
        <value>8388608</value>
        <description>Ap L0 max buffer size of per range per table. Unit: Bytes</description>
    </property>

    <property>
        <name>shared_buffer_min_tuples</name>
        <value>5000</value>
        <description>Ap L0 minimal tuple count per block.</description>
    </property>

    <property>
        <name>shared_buffer_fixed_pool_size</name>
        <value>10240</value>
        <description>Ap L0 buffer pool size.</description>
    </property>

    <property>
        <name>rpc_server_work_thread_num</name>
        <value>32</value>
    </property>

用户数据集群配置参考#

Magma 设计之初为了纯正的 HTAP 而生，并且也一直在朝着这个方向努力。但是 POC 场景，以及一些特定的环境，性能总是可以通过调整资源配置参数来达到最优。目前尚未达到一份配置，适用所有场景的境界。通常Magma 用户数据集群区分是偏AP场景，还是偏TP型场景。