本文整理自蚂蚁集团数据库专家力虾、OceanBase 开源团队和顺，在 OceanBase 社区版入门教程直播的分享。本篇内容主要分为七个部分：

1.如何对 OceanBase 进行扩容和缩容

2.如何重建 OceanBase 集群节点

3.如何对 OceanBase 集群进行备份

4.如何对 OceanBase 租户进行恢复

5.如何使用 OBD 对 OceanBase 集群进行扩容

6.如何升级 OceanBase 集群

7.如何对 OceanBase 集群调优

一、如何对 OceanBase 进行扩容和缩容

1.   DB 可扩展性概述

DB 有两种常见的扩展方式，即 scale up 和 scale out 。scale up 为纵向扩展，单个节点扩大计算或存储资源，成本高，容易达到瓶颈。scale out 为横向扩展，主要以节点为单位扩展，解决单个节点的性能瓶颈。

目前，数据库的架构主要有三种，分别是集中式数据库、分布式数据库中间件、以及原生分布式数据库架构。

• 传统的集中式数据库架构：其性能和可靠性主要依赖特定的硬件，只能支持纵向扩展，且成本高，很难支持横向水平扩展。

• 分布式数据库中间件：通过通用服务器，降低系统成本，但中间件复杂，跨库查询复杂。虽然初步解决了横向扩展问题，但数据分片逻辑跟业务逻辑强绑定，后继调整分片非常复杂，也无法满足用户的透明需求。

• 原生分布式数据库架构：支持分布式查询和事务灵活的部署模式，以 OceanBase 为代表，其高可用的负载均衡能力完美解决了数据库扩展性的问题。

2.   OceanBase 扩展性核心设计

OceanBase 存储引擎在单机引擎的基础上，引入了分布式架构。使得以集群形式的部署，支持水平扩展能力。内置的负载均衡技术，支持跨机房，跨城市部的署灵活容灾和灵活部署。

在多租户方面，OceanBase 的资源载体实现了多租户架构，支持租户间的资源隔离，满足了用户按需分配，动态无损扩缩容的需求。

3.   OceanBase 多租户架构

接下来，重点介绍一下 OceanBase 的多租户架构。上图是简化的 OceanBase 集群部署图，可以看到 OceanBase 有三个 zone，分布在一个城市的三个机房。每个 zone 里有三台 OBServer，这种部署简称为 N-N-N。OBServer 皆为 30C 200G 4T 的 docker ,所以集群总资源是 270C 1800G 36T。

如上图所示，sys 租户总资源为 15C 60G，租户A 总资源为 60C 120G，租户B总资源为 120C 600G。由此可见，OceanBase 是多租户的数据库系统，以 n-n-n 结构布局，一个集群内可包含多个相互独立的租户，每个租户提供独立数据库服务。

在 OceanBase 数据库中，使用资源单元（Unit），资源配置（Unit_Config），资源池（Resource Pool)，对租户进行资源管理。

资源单元对应 CPU、内存、存储空间、IOPS ；任何一个资源单元一定会放置在一个资源足够容纳它的 OBServer 上，一个租户在同一个 OBServer 上最多有一个资源单元；当 OBServer 服务器下线前，其上的资源单元必须迁移到其他 OBServer 上，如果集群内其他 OBServer 不足以容纳会导致下线无法成功。

资源配置是描述资源池的配置信息，用来描述资源池中每个资源单元可用的 CPU 、内存、存储空间和 IOPS 等的规格。修改资源配置可动态调整资源单元的物理资源，进而调整对应租户的资源（目前只有 CPU 、内存实际产生作用，存储空间和 IOPS 的值需要填写，但是系统不会限制）。

资源池由具有相同资源配置的若干个资源单元组成。一个资源池只能属于一个租户，一个租户可以拥有一或多个资源池，这些资源池的集合描述了这个租户所能使用的所有物理资源。

Docker 或虚拟机隔离主要有以下几个问题：

第一，虚拟机运行环境的开销太重，OceanBase 数据库需要支持轻量级租户；

第二，虚拟机迁移开销比较大，OceanBase 数据库希望租户的规格变化和迁移尽量快；

第三，虚拟机不便于租户间的资源共享, 例如，对象池的共享；

第四，虚拟机资源隔离很难定制，例如，租户内的优先级支持；

第五，虚拟机的实现不便于暴露统一视图；

为了确保租户间不出现资源争抢保障业务稳定运行，OceanBase 设计了更加轻量的租户隔离。OceanBase 把 Unit 当作给租户分配资源的基本单位，一个 Unit 可以类比于一个 Docker 容器。

一个 OBServer 上可以创建多个 Unit ，在 OBServer 上每创建一个 Unit 都会占用一部分该 OBServer 的 CPU、内存等物理资源。OBServer 的资源分配情况会记录在内部表中以便 DBA ： SELECT * FROM __all_virtual_server_stat

一个租户可以在多个 OBServer 上放置多个 Unit ，但一个特定的租户在某个 OBServer 上只能有一个 Unit 。资源隔离，就是 OBServer 控制本地多个 Unit 间的资源分配的行为, 它是 OBServer 本地的行为，OceanBase 数据库并没有依赖 Docker 或虚拟机技术，而是在数据库内部实现资源隔离。

4.OceanBase ge

资源单元（Unit）是多租户架构、分布式架构下的重要概念。RS 模块需要对资源单元进行管理，并通过把资源单元在多个 OBServer 间调度，对系统资源进行有效利用。

RS 对资源单元的管理包括：资源单元的分配，即新建一个资源单元时，RS 需要决定这个 Unit 分配到哪个 OBServer 上资源单元的均衡，即在系统运行过程中，RS 根据 Unit 的资源规格等信息对 Unit 进行再平衡的一个调度过程。

CPU 单一资源的均衡示例背景：假设存在两个 OBServer：OBS0（10个CPU）和 OBS1（10个CPU）。其中，OBS0 上包含6个 Unit，每个 Unit 的资源规格为1个 CPU；OBS1 上包含4个 Unit，每个 Unit 的资源规格为1个 CPU。通过在 OBServer 间迁移 Unit ，使得各 OBServer 的 CPU 占用率尽可能接近。

从该示例场景可以看到，OBS0 的 CPU 占用率为 (6/10)*100%=60%，OBS1 的 CPU 占用率为 (4/10)*100%=40%。两个 OBServer 的 CPU 占用率差值为 0.2 ，将 OBS0 上的一个 Unit 迁移到 OBS1 上，迁移后的 OBS0 和 OBS1 的 CPU 占用率都为 (5/10)*100%=50%，与迁移 Unit 前相比，两个 OBServer 的资源占用率更平均。

多种资源均衡算法，即为参与分配和均衡的每种资源分配一个权重，作为计算 OBServer 总的资源占用率时该资源所占的百分比，某种资源使用的越多，则该资源的权重就越高。

如果宿主机的 CPU 不足，肯定会影响到 docker 或者 unit。但 unit 存在 CPU 不足时，未必会反应在 Docker或者宿主机上，宿主机、Docker、unit三个维度都要治理，重要性由高到低分别是宿主机->Docker->unit。

二、如何重建 OceanBase 集群节点

1.什么情况需要重建 OceanBase 节点

在两种情况下需要重建 OceanBase 节点，第一，节点磁盘损坏后修复，怀疑数据有丢失；第二，想对节点数据文件大小进行缩容，重新初始化进程 OBServer 。

2.如何重建 OceanBase 节点

重建 OceanBase 节点主要有四步：

第一，停掉待重建的 OBServer 节点的进程。直接使用 kill-9‘pidof OBServer ，确认 OBServer 进程的工作目录。

第二，确认待重建 OBServer 节点永久下线。首先，节点掉线时间超过参数 server_temporary_offline_time 值（默认 60s）后，状态会进入“临时下线”状态。

此后，如果节点进程能重新正常起来，节点还是集群的成员，会自动同步落后的数据。节点掉线后进入“临时下线”状态时，上面节点视图的 status 列会变为 inactive。同时，在 OceanBase 事件日志视图里也会有一笔“临时下线”记录。

节点掉线首先会有个 lease_expire 事件，都是节点掉线。节点掉线原因可以有很多。如进程宕掉、网络超时或延时过大、时间误差过大等。此外，由于这个示例集群是三节点，所以一个节点的掉线对总控服务成员也是有影响的，所以参数 rootservice_list 会自动变化，踢掉了故障节点。

如果节点掉线时间再超过参数 server_permanent_offline_time 值（默认是 3600s）后，节点会进入“永久下线”状态。此时，集群会清空该节点上的数据副本，并自动在同 Zone 其他节点寻求资源补足被清空的数据副本。

如果没有可用资源，则这个副本对应的分区就只剩下两个副本（或者四个副本）。此时依然是多数派副本可用，所以数据读写是正常的，只是如果再宕机就面临进一步风险，可能就是不可用。

从“临时下线”到“永久下线”时间可能有点长，默认1个小时。如果你不想等，可以临时把这个节点的参数 server_permanent_offline_time 调小。等节点永久下线后再重新上线时，把参数再改回来。

第三，清理待重建 OBServer 上相关数据库文件。清理的文件包括：运行日志，数据文件，事务日志文件，保存运行进程 id 文件。

其中，运行日志包括 election.log，OBServer.log 和 rootservice.log ；数据文件包括 sstable 下的 block_file 文件；事务日志文件：包括目录 {ilog、clog、slog} 下的文件；保存运行进程 id 文件包括，run 目录下文件。

如果需要重建副本，这一步不是必须的。如果想借重建副本操作，重新定义数据文件大小，应注意不要删除参数文件 etc。再次启动节点进程时，只需要在启动参数 -o 里，指定需要修改的参数即可。

第四步，启动 OBServer 进程。status 表示节点状态。inactive，表示节点已经掉线或者进程退出了。节点掉线常见原因是节点时钟偏差过大、网络延时过大、clog 空间盘满（ used 大于等于95%）。

如果进程刚刚启动，则是进程在跟 rootserver 通信沟通。正常情况下启动几秒就能变 active，异常宕机后的再启动可能需要几十秒变 acitve ，最长不超过2分钟。

start_service_time 表示节点开始提供服务时间。如果是默认值 1970-1-1，则表示进程还在应用 clog、刷新 schema 等。通常如果要应用的 clog 不多的时候，这个几秒钟就好了。如果是此前内存中大量数据还没有合并落盘就宕机了，这个恢复时间就长一些，可能会要十几分钟。

stop_time 表示停止服务时间。如果是默认值1970-1-1，表示没有停止服务。如果时间大于默认值（在当前时间附近），表示手动发起过 stop server 或 stop zone 命令。则需要手动发起 start server 或者 start zone 命令恢复服务。只有这三个列都正常了，节点才是正常的。

3.重建 OceanBase 节点实战

将1-1-1集群形态中的一个节点进行重建。观察重建前后节点的状态，

理解临时下线和永久下线的参数，即 server_temporary_offline_time和server_permanent_offline_time

4.   重建 OceanBase 节点其他说明

如上图所示，修改 OBServer1 对应的 server_permanent_offline_time（默认值是3600s),调整为300s：

alter system set server_permanent_offline_time='120s' server='xxx:2882';

show parameters where name = 'server_permanent_offline_time' and svr_ip='xxx';

确认生效之后，观察 kill-9 OBServer1 对应的进程。然后观察 SQL 查询的结果一直没有出现 permanent_offline 相关的记录，

因为修改配置项，不用指定 server。所以 server_permanent_offline_time 是一个集群级配置项，对 RS 生效。如果改配置项指定 server，只有指定的 server 能感知到配置项的变化。

如果租户的架构是1-1-1并且重建的节点就是该租户的成员，宕机后可能导致租户的 DDL 报错：

MySQL[test]>create table t2 like t1;

ERROR 4624(HY000):machine resource is not enough to hold a new unit

此时需要将全局变量 ob_create_table_strict_mode 值设置为 OFF。

三、如何对 OceanBase 集群进行备份

1.备份介绍

OceanBase 的备份分为逻辑备份和物理备份。逻辑备份是导出数据或表结构，逻辑备份的优点是功能灵活，可以指定租户名、库名、表名等进行导出。缺点是只支持离线导出，不支持增量导出。

物理备份是数据块的备份，目前是按集群级别备份，集群里的所有租户都会被备份。备份的内容包含全量数据、增量数据和事务日志。理论上当拥有全量数据备份以及其后的所有事务日志备份，就可以还原出该数据库到历史任意时间点。

备份是数据库可靠性的最后一层保障，是 OceanBase 高可用的兜底。当数据库宕机的时候，可以通过恢复功能将数据库恢复到故障之前的状态。

2.备份介质

OceanBase 的物理备份是将基线数据（sstable）和事务日志（clog）备份到一个共享目录里。在 OceanBase 社区版目前该共享目录只支持 NFS 的共享目录，该共享目录要挂载到每个 OceanBase 节点的本地文件系统上。

在设置共享目录时，设置允许访问 NFS 目录的客户端IP网段，出于安全考虑尽量只包含 OceanBase 集群相关节点服务器的 IP 地址。

rw 是允许客户端读写这个目录。sync 是同步写模式。将客户端的所有 UIDs 和 GIDs 映射到 NFSS SERVER 端的匿名用户。

在修改内核参数时，Linux nfs 客户端对于同时发起的 NFS 请求数量进行了控制，若该参数配置较小会导致 IO 性能较差。

使用 NFS 环境时，需要保证先挂载 NFS ，再开启备份。如果备份期间 NFS 出现问题，需要先停止数据备份和日志备份，再解决 NFS 的问题。

在使用 NFS 作为备份介质时，必须保证所有 OBServer 都挂载了同一个服务器的 NFS 。同时，为保证备份的顺利进行，务必使用官方文档上提供的挂载参数。

在重启 OBServer 时，需要先启动 NFS ，再启动 OBServer 。添加新的机器后，在启动 OBServer 前，需要保证新的机器挂载 NFS 成功。

3.   备份策略

OceanBase 的备份策略跟传统数据库备份一样，支持数据全量备份、数据增量备份和事务日志备份。

在开启全量备份之前，需要先开启事务日志备份。OceanBase 的事务日志备份跟传统数据库的日志备份不完全一样，它是近实时备份的。平均每秒钟检查一下事务日志是否有新增，如果有就备份到备份目录里。

OceanBase 备份跟传统数据库备份的区别在于，OceanBase 的全量备份，是备份数据文件里的基线数据（sstable）。当前的版本不会备份转储的数据，如果在日志归档开启后直接发起全量备份会存在空洞，所以在全量备份发起之前，需要先发起一次基线合并，将这部分空洞数据补齐。

如果后续的日志归档备份没有发生断流，后续的全量备份前不需要发起合并。在执行增量备份前，请确保已经有全量备份存在，且日志备份没有断流。

4.   备份步骤

为了减少日志备份耗时，建议在开启日志备份前进行一次转储，待转储完成后再备份。因为日志备份的起始位点是最近一次的转储位点，转储以后可以减少日志备份启动的时间。

5.   备份报错问题排查

当 backup_dest 路径设置错误，

select  backup_dest, tenant_id, incarnation, log_archive_round, time_to_usec(min_first_time) min_first_time, time_to_usec(max_next_time) max_next_time, status , is_mount_file_cree

ated, compatible, backup_piece_id, start_piece_id  from __all_backup_log_archive_status_v2 where tenant_id=1;

在进行全量备份的时，先执行合并操作，OceanBase 的全量备份是备份数据文件的基线数据（sstable），当前的版本不会备份转储的数据，如果在日志归档开启后直接发起全量备份，会存在空洞。

所以，在全量备份发起之前，需要发起一次基线合并，将部分空洞数据补齐。如果后续日志归档备份没有发生断流，后续的全量备份前不需要再发起合并。

在备份任务运行期间，CDB_OB_BACKUP_PROGRESS 表会有相应的记录，且状态是 running。如果没有记录，可能是已经执行完成，或其他原因导致没有运行任务。如上图所示，最终排出的原因是 NFS server 端断开。

四、如何对 OceanBase 租户进行恢复

OceanBase 的备份是集群级别的，会备份集群下的所有租户的数据。但 OceanBase 的恢复是按租户恢复，且只能恢复到一个空租户环境。

如果恢复到新的租户下，这个租户不需要提前创建，只需要创建对应的资源单元规格和资源池即可。如果恢复到原有租户，需要先删除这个租户 drop tenant tenant_name force ，然后查看有效的备份集。

开启租户恢复参数，参数 restore_concurrency 指定了恢复线程的并发数，默认是0，不恢复。需要修改为大于0的值。通常开启恢复命令后默认还会等待一段时间才开始恢复，整个恢复期间会有三次等待。

每次等待时间是由内部参数 _restore_idle_time 设置，默认值是 60s。参数未来版本可能会发生变化。在生产环境不建议去调整这个参数。在测试时，如果追求恢复调度时间尽可能的短，可以缩小这个时间到 10s：ALTER SYSTEM SET_restore_idle_time='10s'。

物理恢复所处阶段,具体语义如下：

CREATE_TENANT：创建租户阶段。

RESTORE_SYS_REPLICA：租户系统表恢复阶段。

MODIFY_SCHEMA：租户元信息修正阶段。

CREATE_USER_PARTITIONS：租户用户表创建阶段。

RESTORE_USER_REPLICA：租户用户表恢复阶段。

REBUILD_INDEX：索引重建阶段。

POST_CHECK：校验阶段。

RESTORE_SUCCESS：恢复成功。

RESTORE_FAIL：恢复失败。

恢复完成后，cdb_ob_restore_progress 内部表查询记录为空。

了解具体的恢复情况还可以通过查询：

__all_restore_info和__all_rootservice_event_history

select tenant_id,count(*) from gv$partition where role=1 group by tenant_id。

完成上述操作后，登录到恢复到租户中，检查数据恢复情况。

五、如何使用 OBD 对 OceanBase 集群进行扩容

如上图所示，有一个三节点的集群，每个节点都有一个 zone。

首先，写一份新的配置文件，然后再用 OBD 新的进程。

完成之后，把新的配置复制一份到老的配置里，且新配置一定在旧配置下面。

可以看到旧配置的服务名是 z1，z2，z3 新服务的名称是 z4，z5，z6。

配置修改之后，可以直接启动集群，如上图所示，每台机器都有两个 OceanBase 进程。

连接 OceanBase，添加新的进程到集群。每个 zone 都有两个进程，扩容成功。

接下来，为业务租户扩容。创建业务租户 Amber babe ，查看创建好的业务租户

，将 unit num 调整为2，扩容完成。

六、如何升级 OceanBase 集群

随着 OceanBase 社区版版本的不断迭代，近日已发布了社区版 OceanBase 3.1.2 版本和对应的 OBD1.2.1版 本，提供 OceanBase 内核版本在线升级功能，用户可以借助 OBD cluster upgrade 命令轻松完成对 OceanBase 数据库集群的内核升级替换。

OBD cluster upgrade 一次只能升级一个组件，并且必须指定目标版本。然后自动识别，最优跨版本升级路径。当获取到升级路径后，就明确需要哪些镜像。此时通过的 MirrorManager 和 RepositoryManager 便可以获取到对应的仓库和镜像。

然后进入持久化升级流程，用户需要确认路径和镜像是否合适。持久化信息中包含升级路径、所需镜像信息、已完成的升级步骤。

轮转升级可以按 zone 升级，可以不停服升级。轮转升级的使用条件，是当前停掉一个 zone 后仍满足多数派。因此单 zone 或双 zone 不能使用轮转升级，只能选择停服升级。

综上所述，升级流程是 OBD 根据匹配指定待升级组件和待升级的目标版本，自动识别最优跨版本升级路径策略，通过切换 Primary Zone，逐个完成对 Zone 进行升级，进而实现数据不停服、业务不中断的升级。

然后，需要确认 OBD 的版本是1.2.1(+),如果版本低于1.2.1需要在 root 用户下执行 OBD update 升级一下 OBD 的版本 Yum update。

OBD cluster upgrade 一次只能升级一个组件，并且必须指定目标版本。-c 是指要升级的组件名称，-V是指要升级到的目标版本。

在目标版本存在多个候选项的情况，可以指定对应的 hash 来优先使用对应的。如果是自己编译的版本或非官方版本，不能保证升级的兼容性。

接下来，进行离线升级。首先，在可以联网的机器上下载需要升级的组件对应的 rpm 包。OBProxy 从 3.1.0 升级到3.2.0的时候需要在 root@proxysys 下调整，否则升级后无法登录。

alter proxyconfig set skip_proxy_sys_private_check=true;

其次，关闭远程镜像源，OBD mirror disable remote。

然后，将第一步中下载好的镜像加入到 local 中：OBD mirror clone*.rpm

最后，执行 OBD cluster upgrade 部署名–c组件名-V目标版本号。在升级过程

中，用户需要注意升级的快慢跟集群的规模（并非数据量）和规格有关系。如果集群规模是1-1-1，升级前先修改租户的全局变量：ob_create_table_strict_mode=0。

如果是刚新部署的新集群测试升级，需要先做一次合并操作。一次只能升级一个组件，并且必须指定目标版本。升级时建议先升级 OBProxy ，再升级 OceanBase-CE。

七、如何对OceanBase集群调优

1.   OceanBase 内存结构

上图是 OceanBase 的内存模块划分。当 OceanBase 进程启动，默认占用80%的机器内存，剩下20%留给操作系统。在 OceanBase 内部，内存又分为几部分。右边白色区域称之为 OceanBase 系统内存，内存默认20G。除了 OceanBase 系统内存，其余所有内存都可以划分给租户使用。

OceanBase 是多租户架构，红色部分是所有租户共同分配的内存。租户内部又分为两大块，一部分是 memstore 占用的内存，另一部分是 cache 占用的内存。

2.   OceanBase 内存控制参数

接下来，讲讲 OceanBase 通过哪些参数来调整 OceanBase 相应模块的内存大小。首先介绍的两个参数是 memory limit percentage和memory limit。

这两个参数控制的是 OceanBase 使用内存的一个上限。memory limit percentage 是按照百分比的方式来计算自身可用内存的上限，memory limit 使用绝对值的方式设置 OceanBase 可用内存的上限。而且 memory limit 优先级高于 memory limit percentage。

memory limit 可以直接设置 OceanBase 数据库可用内存的上限，memory_limit 参数值为0时.使用百分比的配置方式，否则使用绝对值的配置方式。

第二个参数是 system memory，如上所述，OceanBase 是一个多租户架构，它的内存分配不能全部分配给租户使用。因为每一个 OceanBase 上，所有的租户可能是会共享一些信息或者功能，比如配置信息或 log 模块。这些共享的资源或者功能所使用的内存不属于任何一个租户。所以我们归置为系统内存。这部分内存使用上限通过 system memory 来设置。

OceanBase 数据库支持多租户架构，租户使用的内存不是直接通过参数设置的，而是通过 RESOURCEUNIT 设置的，创建用户租户时需要指定资源池，而资源池就和 resource unit 绑定，从而确定租户使用资源的规格。

memstore 称之为不可动态伸缩的内存，KVCache 称之为可动态伸缩的内存。目前与不可动态伸缩内存相关的配置只有 memstore_limit_percentage。

它表示租户的 memstore 部分最多占租户总内存上限的百分比，默认值为租户 MinMemory 的50%。租户的写入或者更新会增加 memstore 的内存使用，当租户的 memstore 部分内存到达上限以后，后续的写入或者更新操作将会被拒绝。

与 memstore 相关的另一个参数是 freeze trigger percentage。OceanBase 数据库会根据 memstore 的内存使用比例决定何时进行转储或者合并释放 memstore 的内存。

该比例由配置项 freeze_trigger_percentage 控制,表示当 memstore 内存占用到达其上限的百分比后就进行冻结（转储和合并的前置动作），默认值为租户 memstore 内存上限的70%，即租户 MinMemory 的35%。

3.   OceanBase 内存监控

首先，通过 OCP 运维平台查看 OceanBase 的内存使用情况。蓝色的部分表示 active memstore 的使用，红色部分表示 total memstore 的使用情况。上图是非常有规律的锯齿状，说明它是在不断的冻结。

除此之外，还可以通过它计算业务写入速度。获取两点间的时间，观察它的数值情况，就可以计算出业务每秒写入的速度。

一般情况下，memstore 的监控是有规律的锯齿状。当 active memstore 业务写入过快，磁盘性能较差，total memstore 不能及时转储到磁盘。红色线条的趋势可能慢慢趋近于水平状态，表明内存不能及时释放。业务就会开始报错。

除了上述 OCP 的方式，用户还可以通过 SQL 的方式来观察 OceanBase 内存的使用情况。

上图的 SQL 是一个 memstore 的总体使用情况。可以看到当前查询时间；租户名IP；active 表示 active memstore 的使用占用情况；total 表示总的占用情况；trigger 表示 active 触发冻结的阈值；limit 表示 memstore 的总大小，used 表示占用内存的百分比。

上图的 SQL 查看对应租户内部的模块监控，可以看到对应模块的使用大小。除了 kvstore 和 memstore。还可以查看某一个 IP 所有模块的使用情况。

OceanBase 内存监控的第三种方式是通过日志查看。一般作为第一种、第二种的补充。在排查线上问题时，查看租户的内存使用情况，以及每个内存模块的内存占用情况。

4.OceanBase 内存调优

接下来，分享一些内存调优经验。第一，要合理调整 memory limit percentage 的大小。因为这个参数用来来控制 OceanBase 的内存使用上限。

第二，freeze_trigger_pereentage 控制了内存转储的时间,应该根据实际的内存大小和业务写入速度调整。如果设置太大，在合并时会需要更长的时间，消耗在线资源，影响在线业务。

第三，学会查看 _all_virtual_memory_info。它可以清晰的查看到各模块的内存占用情况，对于排查内存泄露问题，可以看到模块的内存和平常占用的区别，从而大概定位到某个模块的内存是否有泄露情况。

最后的最后，有任何问题都可以和我们联系。

联系我们

欢迎广大 OceanBase 爱好者、用户和客户随时与我们联系、反馈，方式如下：

社区版官网论坛

社区版项目网站提 Issue