数据库OLAP数据仓库大数据湖仓一体数据分析【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址https://gitcode.com/GitHub_Trending/st/starrocks点击查看免费下载SHOW USAGE RESOURCE GROUPS 是 StarRocks 用于查询各资源组在 BE 节点上实时资源占用情况的 SQL 语句帮助开发与运维人员直观掌握 CPU、内存与并发查询在资源组粒度上的分配与消耗。本文以官方文档为基础结合 BE 端上报实现与 Thrift 协议定义系统讲解该命令的语法、返回字段、工作原理与使用建议使读者能够独立完成资源组运行状态的监控与初步排查。功能概述SHOW USAGE RESOURCE GROUPS 用于展示资源组Resource Group的使用情况该功能自StarRocks v3.1.4起支持。与 SHOW RESOURCE GROUPS 这类查看资源组定义/配置的命令不同本命令聚焦的是运行时实际用量例如某个资源组在某个 BE 上当前占用了多少 CPU 核、多少内存、还有多少查询在跑。该命令无需任何权限即可执行适合作为日常巡检与故障排查的第一手观测工具。语法SHOW USAGE RESOURCE GROUPS命令不接收任何参数直接返回集群中所有 BE 节点上各资源组的实时用量明细。返回字段说明命令执行后返回一张表包含以下六列字段说明Name资源组名称。Id资源组 ID。BackendBE 节点的 IP 或 FQDN。BEInUseCpuCores该资源组在此 BE 上当前正在使用的 CPU 核数属于近似估算值。BEInUseMemBytes该资源组在此 BE 上当前正在使用的内存字节数。BERunningQueries该资源组在此 BE 上仍在运行中的查询数量。其中BEInUseCpuCores与BEInUseMemBytes直接对应集群实际的负载状态CPU 核数用于判断资源组是否逼近cpu_core_limit上限内存字节数则用于观察资源组的内存消耗趋势。使用说明与关键行为使用该命令时有两个需要特别注意的行为特征周期性上报BE 会按照report_resource_usage_interval_ms配置项指定的时间间隔周期性向 Leader FE 上报资源使用信息该参数默认值为 1 秒1000 毫秒。因此本命令反映的是最近一次上报快照而非严格实时的瞬时值。仅显示活跃资源组结果中只展示BEInUseCpuCores、BEInUseMemBytes、BERunningQueries三者中至少有一项为正数的行。换言之只有某个资源组在某个 BE 上真正占用了资源时该行才会出现完全空闲的资源组不会出现在结果集中。示例以下为官方文档给出的输出示例MySQL [(none)] SHOW USAGE RESOURCE GROUPS; ------------------------------------------------------------------------------- | Name | Id | Backend | BEInUseCpuCores | BEInUseMemBytes | BERunningQueries | ------------------------------------------------------------------------------- | default_wg | 0 | 127.0.0.1 | 0.100 | 1 | 5 | ------------------------------------------------------------------------------- | default_wg | 0 | 127.0.0.2 | 0.200 | 2 | 6 | ------------------------------------------------------------------------------- | wg1 | 0 | 127.0.0.1 | 0.300 | 3 | 7 | ------------------------------------------------------------------------------- | wg2 | 0 | 127.0.0.1 | 0.400 | 4 | 8 | -------------------------------------------------------------------------------从输出可以读到default_wg在 127.0.0.1 和 127.0.0.2 两台 BE 上均有负载wg1、wg2目前只活跃在 127.0.0.1 上空闲的 BE 或资源组组合不会出现对应行。底层实现BE 如何采集并上报资源用量SHOW USAGE RESOURCE GROUPS 的数据来自 BE 的周期性上报机制理解这条链路有助于正确解读查询结果。上报线程与采集逻辑在 BE 端资源使用上报由一个独立的后台线程池驱动。其核心实现位于 be/src/agent/task_worker_pool.cpp 的ReportResourceUsageTaskWorkerPool::_worker_thread_callback约 L779-L823工作流程如下等待并获取 Leader FE 的地址心跳未就绪时会短暂睡眠重试组装TReportRequest携带本 BE 标识与上报版本号填充TResourceUsage运行中查询数取自query_context_mgr()-size()内存用量取自进程级内存跟踪器process_mem_tracker()CPU 用量千分比由_cpu_usage_recorder按采样区间计算填充按资源组统计的group_usages由ResourceGroupUsageRecorder汇总通过report_taskRPC 上报给 Leader FE失败时记录告警日志并累加失败计数按照 be/src/common/config.h 第 235 行定义的CONF_mInt32(report_resource_usage_interval_ms, 1000)休眠即默认每 1000 毫秒上报一次。这也印证了文档中的说明report_resource_usage_interval_ms默认值为 1 秒且可在 BE 配置文件 conf/be.conf 中调整上报频率单位毫秒。上报数据的协议结构BE 上报的资源组用量数据由 Thrift 协议定义见 gensrc/thrift/ResourceUsage.thriftTResourceGroupUsage单个资源组维度包含group_id、cpu_core_used_permilleCPU 使用千分比、mem_used_bytes、num_running_queries、mem_limit_bytes及内存池mem pool相关字段、group_versionTResourceUsageBE 整体维度包含num_running_queries、mem_limit_bytes、mem_used_bytes、cpu_used_permille并以group_usages列表携带各资源组明细。可以看到BEInUseCpuCores展示的核数实际由千分比形式的cpu_core_used_permille换算而来且文档已明确说明这是一个近似估算值这正是协议中采用 permille 精度、周期性采样的原因。可观测性指标BE 还通过 Agent 指标暴露了上报链路的健康状态。在 be/src/agent/agent_metrics.h 中定义了report_resource_usage_requests_total上报总次数与report_resource_usage_requests_failed上报失败次数等计数器。当 SHOW USAGE RESOURCE GROUPS 长期不返回任何行而集群实际存在负载时可以结合这些指标判断是否为上报链路故障例如 BE 与 Leader FE 网络异常。常见问题与使用建议为什么结果里没有空闲资源组这是设计行为命令仅返回至少一项用量为正的行用于精简输出。若需了解全量资源组定义请使用 SHOW RESOURCE GROUPS。数值波动较大怎么办由于默认 1 秒上报一次且 CPU 为近似估算短时间内数值出现跳动属于正常现象观察趋势时建议连续多次执行或结合监控面板查看。如何调整上报频率修改 BE 配置report_resource_usage_interval_ms并重启 BE 生效。提高频率可获得更细粒度的数据但会增加 BE 与 FE 之间的通信开销降低频率则相反请按监控需求权衡。配合资源组限流使用当某个资源组频繁出现 CPU 或内存逼近上限时可以结合 CREATE RESOURCE GROUP 中定义的cpu_core_limit、memory_limit等参数进行对比判断是否需要调整资源组配额实现多租户场景下的精细化资源治理。总结SHOW USAGE RESOURCE GROUPS 以零权限、零参数的形式将资源组粒度的 CPU、内存与运行中查询数直接呈现在 SQL 终端中。其数据源于 BE 端ReportResourceUsageTaskWorkerPool按report_resource_usage_interval_ms默认 1 秒周期上报的TResourceUsage/TResourceGroupUsage快照。理解这一采集与上报链路后运维人员便能准确解读命令输出并将其作为资源组配额调整与负载均衡排查的有效依据。赞分享数据库OLAP数据仓库大数据湖仓一体数据分析【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址https://gitcode.com/GitHub_Trending/st/starrocks点击查看免费下载相关推荐StarRocks SHOW PROCESSLIST 使用指南查询集群会话与执行状态StarRocks SHOW PROCESSLIST 使用指南查询集群会话与执行状态 本篇指南围绕 StarRocks 的 SHOW PROCESSLIST数据库OLAP数据仓库大数据湖仓一体数据分析推荐开源项目Jupyter Resource Usage —— 智能监控你的Jupyter资源推荐开源项目Jupyter Resource Usage —— 智能监控你的Jupyter资源 在数据科学和机器学习领域高效监控资源消耗是保持项目高效运行的Jupyter Resource Usage 开源项目安装与使用指南Jupyter Resource Usage 开源项目安装与使用指南 本指南将引导您了解并使用 Jupyter Resource Usage https://g创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 StarRocks SHOW USAGE RESOURCE GROUPS：资源组使用状态监控指南
数据库OLAP数据仓库大数据湖仓一体数据分析【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址https://gitcode.com/GitHub_Trending/st/starrocks点击查看免费下载SHOW USAGE RESOURCE GROUPS 是 StarRocks 用于查询各资源组在 BE 节点上实时资源占用情况的 SQL 语句帮助开发与运维人员直观掌握 CPU、内存与并发查询在资源组粒度上的分配与消耗。本文以官方文档为基础结合 BE 端上报实现与 Thrift 协议定义系统讲解该命令的语法、返回字段、工作原理与使用建议使读者能够独立完成资源组运行状态的监控与初步排查。功能概述SHOW USAGE RESOURCE GROUPS 用于展示资源组Resource Group的使用情况该功能自StarRocks v3.1.4起支持。与 SHOW RESOURCE GROUPS 这类查看资源组定义/配置的命令不同本命令聚焦的是运行时实际用量例如某个资源组在某个 BE 上当前占用了多少 CPU 核、多少内存、还有多少查询在跑。该命令无需任何权限即可执行适合作为日常巡检与故障排查的第一手观测工具。语法SHOW USAGE RESOURCE GROUPS命令不接收任何参数直接返回集群中所有 BE 节点上各资源组的实时用量明细。返回字段说明命令执行后返回一张表包含以下六列字段说明Name资源组名称。Id资源组 ID。BackendBE 节点的 IP 或 FQDN。BEInUseCpuCores该资源组在此 BE 上当前正在使用的 CPU 核数属于近似估算值。BEInUseMemBytes该资源组在此 BE 上当前正在使用的内存字节数。BERunningQueries该资源组在此 BE 上仍在运行中的查询数量。其中BEInUseCpuCores与BEInUseMemBytes直接对应集群实际的负载状态CPU 核数用于判断资源组是否逼近cpu_core_limit上限内存字节数则用于观察资源组的内存消耗趋势。使用说明与关键行为使用该命令时有两个需要特别注意的行为特征周期性上报BE 会按照report_resource_usage_interval_ms配置项指定的时间间隔周期性向 Leader FE 上报资源使用信息该参数默认值为 1 秒1000 毫秒。因此本命令反映的是最近一次上报快照而非严格实时的瞬时值。仅显示活跃资源组结果中只展示BEInUseCpuCores、BEInUseMemBytes、BERunningQueries三者中至少有一项为正数的行。换言之只有某个资源组在某个 BE 上真正占用了资源时该行才会出现完全空闲的资源组不会出现在结果集中。示例以下为官方文档给出的输出示例MySQL [(none)] SHOW USAGE RESOURCE GROUPS; ------------------------------------------------------------------------------- | Name | Id | Backend | BEInUseCpuCores | BEInUseMemBytes | BERunningQueries | ------------------------------------------------------------------------------- | default_wg | 0 | 127.0.0.1 | 0.100 | 1 | 5 | ------------------------------------------------------------------------------- | default_wg | 0 | 127.0.0.2 | 0.200 | 2 | 6 | ------------------------------------------------------------------------------- | wg1 | 0 | 127.0.0.1 | 0.300 | 3 | 7 | ------------------------------------------------------------------------------- | wg2 | 0 | 127.0.0.1 | 0.400 | 4 | 8 | -------------------------------------------------------------------------------从输出可以读到default_wg在 127.0.0.1 和 127.0.0.2 两台 BE 上均有负载wg1、wg2目前只活跃在 127.0.0.1 上空闲的 BE 或资源组组合不会出现对应行。底层实现BE 如何采集并上报资源用量SHOW USAGE RESOURCE GROUPS 的数据来自 BE 的周期性上报机制理解这条链路有助于正确解读查询结果。上报线程与采集逻辑在 BE 端资源使用上报由一个独立的后台线程池驱动。其核心实现位于 be/src/agent/task_worker_pool.cpp 的ReportResourceUsageTaskWorkerPool::_worker_thread_callback约 L779-L823工作流程如下等待并获取 Leader FE 的地址心跳未就绪时会短暂睡眠重试组装TReportRequest携带本 BE 标识与上报版本号填充TResourceUsage运行中查询数取自query_context_mgr()-size()内存用量取自进程级内存跟踪器process_mem_tracker()CPU 用量千分比由_cpu_usage_recorder按采样区间计算填充按资源组统计的group_usages由ResourceGroupUsageRecorder汇总通过report_taskRPC 上报给 Leader FE失败时记录告警日志并累加失败计数按照 be/src/common/config.h 第 235 行定义的CONF_mInt32(report_resource_usage_interval_ms, 1000)休眠即默认每 1000 毫秒上报一次。这也印证了文档中的说明report_resource_usage_interval_ms默认值为 1 秒且可在 BE 配置文件 conf/be.conf 中调整上报频率单位毫秒。上报数据的协议结构BE 上报的资源组用量数据由 Thrift 协议定义见 gensrc/thrift/ResourceUsage.thriftTResourceGroupUsage单个资源组维度包含group_id、cpu_core_used_permilleCPU 使用千分比、mem_used_bytes、num_running_queries、mem_limit_bytes及内存池mem pool相关字段、group_versionTResourceUsageBE 整体维度包含num_running_queries、mem_limit_bytes、mem_used_bytes、cpu_used_permille并以group_usages列表携带各资源组明细。可以看到BEInUseCpuCores展示的核数实际由千分比形式的cpu_core_used_permille换算而来且文档已明确说明这是一个近似估算值这正是协议中采用 permille 精度、周期性采样的原因。可观测性指标BE 还通过 Agent 指标暴露了上报链路的健康状态。在 be/src/agent/agent_metrics.h 中定义了report_resource_usage_requests_total上报总次数与report_resource_usage_requests_failed上报失败次数等计数器。当 SHOW USAGE RESOURCE GROUPS 长期不返回任何行而集群实际存在负载时可以结合这些指标判断是否为上报链路故障例如 BE 与 Leader FE 网络异常。常见问题与使用建议为什么结果里没有空闲资源组这是设计行为命令仅返回至少一项用量为正的行用于精简输出。若需了解全量资源组定义请使用 SHOW RESOURCE GROUPS。数值波动较大怎么办由于默认 1 秒上报一次且 CPU 为近似估算短时间内数值出现跳动属于正常现象观察趋势时建议连续多次执行或结合监控面板查看。如何调整上报频率修改 BE 配置report_resource_usage_interval_ms并重启 BE 生效。提高频率可获得更细粒度的数据但会增加 BE 与 FE 之间的通信开销降低频率则相反请按监控需求权衡。配合资源组限流使用当某个资源组频繁出现 CPU 或内存逼近上限时可以结合 CREATE RESOURCE GROUP 中定义的cpu_core_limit、memory_limit等参数进行对比判断是否需要调整资源组配额实现多租户场景下的精细化资源治理。总结SHOW USAGE RESOURCE GROUPS 以零权限、零参数的形式将资源组粒度的 CPU、内存与运行中查询数直接呈现在 SQL 终端中。其数据源于 BE 端ReportResourceUsageTaskWorkerPool按report_resource_usage_interval_ms默认 1 秒周期上报的TResourceUsage/TResourceGroupUsage快照。理解这一采集与上报链路后运维人员便能准确解读命令输出并将其作为资源组配额调整与负载均衡排查的有效依据。赞分享数据库OLAP数据仓库大数据湖仓一体数据分析【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址https://gitcode.com/GitHub_Trending/st/starrocks点击查看免费下载相关推荐StarRocks SHOW PROCESSLIST 使用指南查询集群会话与执行状态StarRocks SHOW PROCESSLIST 使用指南查询集群会话与执行状态 本篇指南围绕 StarRocks 的 SHOW PROCESSLIST数据库OLAP数据仓库大数据湖仓一体数据分析推荐开源项目Jupyter Resource Usage —— 智能监控你的Jupyter资源推荐开源项目Jupyter Resource Usage —— 智能监控你的Jupyter资源 在数据科学和机器学习领域高效监控资源消耗是保持项目高效运行的Jupyter Resource Usage 开源项目安装与使用指南Jupyter Resource Usage 开源项目安装与使用指南 本指南将引导您了解并使用 Jupyter Resource Usage https://g创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考