各位好,在OceanBase的生产环境中,我们通常使用多租户模型进行业务隔离。理论上资源是隔离的,但在一些高负载场景下,仍可能观察到某个租户的性能抖动是因为受到了其他租户的影响。
例如,当一个租户进行大规模数据批处理或全表扫描时,可能会对共享存储的IO带宽造成压力,进而影响到其他对延迟敏感的在线业务租户。
想和大家探讨的具体问题是:
-
监控与预警 :除了观察租户自身的
CPU_TIME 、IOPS 等基础指标,有哪些更有效的全局资源视图 或关键信号,可以提前发现这种跨租户的资源争用?(比如GV$SYSSTAT 中的某些特定项?)
-
隔离策略 :在创建资源单元(
CREATE RESOURCE UNIT )时,除了设置MAX_CPU 和MIN_CPU ,IOPS_WEIGHT 等参数的实际调优经验是怎样的?如何为在线交易和批量处理两类负载设计差异化的单元配置?
-
应急干预 :如果已经发生因资源争用导致的线上业务卡顿,除了对“问题租户”进行
KILL 会话这种强硬操作外,是否有更平滑的、在数据库内部的资源限流或降级手段 ?
希望有实际运维经验的朋友分享你们的配置策略、监控大盘和应急流程,这对我们构建稳定的多租户环境至关重要。
【标签】 #多租户 #资源管理 #性能调优 #生产运维
1 个赞
论坛小助手
#4
在多租户环境下,OceanBase 提供了多种机制来预防和排查租户间资源(如 CPU/IO)争用导致的性能抖动,具体包括以下几个方面:
监控与预警
-
全局资源视图:
-
GV$SYSSTAT: 可以监控系统级别的统计信息,包括 CPU 使用情况、IOPS 等。
-
GV$OB_UNIT_STAT: 提供了每个租户单元的资源使用情况,包括 CPU 使用、内存使用、IOPS 等。
-
GV$OB_TENANT_MEMORY_INFO: 显示每个租户的内存使用情况。
-
GV$OB_RESOURCE_POOL_STAT: 显示每个资源池的资源使用情况。
-
关键信号:
-
CPU 使用率:监控租户的 CPU 使用率,特别是在高峰时段。
-
IOPS: 监控租户的 IOPS 使用情况,特别是写 IOPS。
-
延迟:监控租户的 SQL 执行延迟,特别是对延迟敏感的在线业务租户。
隔离策略
-
资源单元配置:
-
MAX_CPU 和 MIN_CPU: 通过设置 MAX_CPU 和 MIN_CPU 来限制租户的最大和最小 CPU 使用。
-
IOPS_WEIGHT: 通过设置 IOPS_WEIGHT 来调整租户的 IOPS 权重,从而影响其在高负载下的资源分配。
-
LOG_DISK_SIZE: 通过设置 LOG_DISK_SIZE 来限制租户的 clog 磁盘使用。
-
差异化单元配置:
-
在线交易租户:
- 设置较高的 MIN_CPU 以保证稳定的 CPU 资源。
- 设置较低的 IOPS_WEIGHT 以减少对 IO 资源的争用。
-
批量处理租户:
- 设置较高的 MAX_CPU 以允许在低负载时使用更多的 CPU 资源。
- 设置较高的 IOPS_WEIGHT 以保证在批处理时有足够的 IO 资源。
应急干预
-
资源限流:
-
OB_QUERY_TIMEOUT: 设置 SQL 的最大执行时间,防止长时间运行的 SQL 占用过多资源。
-
OB_TRX_TIMEOUT: 设置事务的最大执行时间,防止长时间运行的事务占用过多资源。
-
PARALLEL_SERVERS_TARGET: 控制租户在每个节点上可申请的并行执行线程数量。
-
降级手段:
-
KILL 会话: 对于严重影响其他租户的会话,可以考虑 KILL 会话。
-
动态调整资源: 根据实时监控数据,动态调整租户的资源配置,如 CPU、内存、IOPS 等。
-
临时增加资源: 在高负载时段,可以临时增加资源池的资源,提高租户的资源上限。
实际运维经验
-
监控大盘:
- 建立全面的监控体系,包括系统级别的监控和租户级别的监控。
- 使用 Grafana 等工具可视化监控数据,实时发现异常。
-
配置策略:
- 定期审查和调整租户的资源配置,确保资源分配合理。
- 根据业务需求和历史数据,优化资源单元的配置。
-
应急流程:
- 制定详细的应急响应流程,包括资源限流、会话 KILL 等操作。
- 定期进行应急演练,提高团队的应急响应能力。
以上措施可以帮助你在多租户环境中更好地预防和排查租户间资源争用导致的性能抖动。
更多信息请查看:
- 租户间的资源隔离
- 产品 FAQ
- 查看 OceanBase 集群资源的使用情况
- SQL 性能问题的典型场景和排查思路
- OceanBase 数据库性能的影响因素