ScyllaDB Nodetool getstreamthroughput 详解查看 SSTables 流式传输吞吐上限【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladbnodetool getstreamthroughput是 ScyllaDB 运维中用于查询当前节点 SSTables 流式传输streaming吞吐上限的命令。它直接读取节点上stream_io_throughput_mb_per_sec配置项的实时值帮助运维人员确认限速是否生效、是否已按预期关闭并可与setstreamthroughput配套完成查询—调整—复验的完整链路。读完本文你将掌握该命令的语法、--mib选项背后的单位换算原理以及从 nodetool 客户端到 REST API、再到流管理器与配置系统的完整调用链。命令用途确认流式传输的限速状态在 ScyllaDB 中streaming 指节点之间传输 SSTables 数据的过程典型场景包括新节点加入集群bootstrap时的数据迁移节点退役decommission、移除节点removenode等拓扑变更repair修复过程中跨节点的数据对账与补齐。这些操作会进行大量顺序 I/O可能占满网络带宽从而影响客户端 RPC 性能。为此ScyllaDB 允许为 streaming 设置吞吐上限throughput cap。getstreamthroughput的作用就是打印系统中当前生效的 SSTables 流式传输吞吐上限If zero is printed, it means throughput is uncapped 如果输出为 0表示吞吐未设置上限也就是说输出0是正常的、合法的状态——它表示限速被禁用streaming 不受吞吐约束而非错误结果。这一设计保证运维人员可以通过返回值直观判断节点当前处于限速还是不限速状态。语法与参数nodetool [options] getstreamthroughput [--mib]其中[options]为 nodetool 通用选项如指定连接主机、端口、认证信息等[--mib]是该命令唯一的专属选项。--mib选项切换输出单位选项作用输出示例当上限为 100 MiB/s 时不带选项以**兆比特每秒megabits per second, Mbit/s**打印838--mib以MiB/s每秒 Mebibyte即 2^20 字节打印100从源码 tools/scylla-nodetool.cc 可以清晰地看到两种输出路径的实现void getstreamthroughput_operation(scylla_rest_client client, const bpo::variables_map vm) { auto res client.get(/storage_service/stream_throughput); uint32_t throughput_mb_per_sec res.GetInt64(); if (vm.contains(mib)) { fmt::print({}\n, throughput_mb_per_sec); } else { fmt::print({}\n, (((uint64_t)throughput_mb_per_sec) 23) / 1000000); } }单位换算原理值得注意REST API/storage_service/stream_throughput返回的内部值throughput_mb_per_sec始终是MiB/s单位见下文源码分析。命令输出时指定--mib直接原样打印内部值即 MiB/s不指定--mib执行value * 2^23 / 1_000_000转换为兆比特每秒。其中左移 23 位相当于乘以 2^23即 1 MiB 2^20 字节 2^23 位把 MiB/s 换算成 bit/s再除以 1,000,000 得到十进制兆位Mbit/s。因此两者不是简单的 8 倍关系而是二进制前缀MiB2^23 bit与十进制前缀Mbit10^6 bit之间的换算。实际使用中若想直接得到与配置文件一致的数值推荐加--mib参数查看若习惯网络带宽的 Mbit/s 口径则可不加参数。该命令在 nodetool 中的注册信息位于 tools/scylla-nodetool.cc帮助文本为 Print throughput cap for streaming in the system in megabits其typed_option(mib, ...)描述为 Print the throughput cap for streaming in MiB/s。调用链源码剖析从命令到配置的完整路径getstreamthroughput虽然只是一条查询命令但其背后贯穿了 nodetool 客户端、HTTP REST API、流管理器stream_manager和配置系统四个层面理解这条链路有助于排查查询值与实际限速不符的问题。第一层nodetool 客户端发起 REST 请求如上所示getstreamthroughput_operation通过 scylla_rest_client 向本地节点的/storage_service/stream_throughput端点发起 HTTP GET 请求并解析返回的整数值。第二层REST API 处理器读取流管理器状态该端点的 GET 处理器定义在 api/stream_manager.ccss::get_stream_throughput_mb_per_sec.set(r, sm { auto value sm.local().throughput_mbs(); return make_ready_futurejson::json_return_type(value); });它调用本 shard 上stream_manager的throughput_mbs()方法获取当前限速值。对应的 API 描述含 GET/POST 两种方法、type: long记录在 api/api-doc/storage_service.json 中nickname 为get_stream_throughput_mb_per_sec。第三层stream_manager 持有可热更新的配置值stream_manager在构造时从数据库配置中取得初始值并保存为一个支持热更新的值对象构造处streaming/stream_manager.cc_io_throughput_mbs(cfg.stream_io_throughput_mb_per_sec)读取方法streaming/stream_manager.hhuint32_t throughput_mbs() const noexcept { return _io_throughput_mbs.get(); }_io_throughput_mbs的类型是utils::updateable_valueuint32_t见 streaming/stream_manager.hh意味着当配置在运行时被修改后这里读到的值会同步更新——这正是getstreamthroughput总是返回当前实时生效值的原因。第四层配置项与运行时更新入口底层配置项定义在 db/config.cc, stream_io_throughput_mb_per_sec(this, stream_io_throughput_mb_per_sec, liveness::LiveUpdate, value_status::Used, 0, Throttles streaming I/O to the specified total throughput (in MiBs/s) across the entire system. Streaming I/O includes the one performed by repair and both RBNO and legacy topology operations such as adding or removing a node. Setting the value to 0 disables stream throttling. It is recommended to set the value for this parameter to be 75% of network bandwidth)关键事实默认值为0即默认不限速该配置为liveness::LiveUpdate支持运行时热更新限速范围覆盖整个系统的 streaming I/O包括 repair以及 RBNO 与 legacy旧式拓扑操作如增删节点中的流式传输配置注释明确建议该参数值设置为网络带宽的 75%较为合适。而setstreamthroughput之所以能热更新限速值正是因为它的 REST 处理器api/config.cc会将新值写回配置系统ss::set_stream_throughput_mb_per_sec.set(r, cfg mutable { api::req_paramuint32_t value(*req, value, 0); cfg.stream_io_throughput_mb_per_sec(value.value, utils::config_file::config_source::API); return make_ready_futurejson::json_return_type(json::json_void()); });由此形成完整闭环setstreamthroughput写入配置 →stream_manager的值对象热更新 →getstreamthroughput读出最新值。典型使用场景场景一确认限速是否生效$ nodetool getstreamthroughput --mib 0输出0表示当前未限速。若此前通过setstreamthroughput设置了限速此处应输出对应数值。场景二以网络带宽口径查看$ nodetool getstreamthroughput 838当内部限速为 100 MiB/s 时不带--mib输出约838100 × 2^23 / 10^6 ≈ 838.86表示约 838 Mbit/s。场景三与 setstreamthroughput 配套使用getstreamthroughput与setstreamthroughput是一对配套命令。设置命令的语法为详见 setstreamthroughput 文档nodetool [options] setstreamthroughput value_in_mb设置0同样表示禁用限速。典型运维流程为# 1. 查看当前限速状态 nodetool getstreamthroughput --mib # 2. 设置限速假设 200 MiB/s nodetool setstreamthroughput 200 # 3. 复验是否生效 nodetool getstreamthroughput --mib 200两条命令均作用于同一底层配置stream_io_throughput_mb_per_sec因此getstreamthroughput是验证setstreamthroughput是否生效的最直接手段。注意事项与最佳实践0 的含义输出0代表未设置上限不是故障。若希望为 streaming 限速以保护客户端 RPC 性能需主动通过setstreamthroughput或配置stream_io_throughput_mb_per_sec设置非零值。单位口径默认输出为 Mbit/s十进制兆位--mib输出为 MiB/s两者换算系数为 2^23 / 10^6而非简单的 8 倍。与配置文件数值对比时建议使用--mib。限速范围该限速覆盖整个系统的 streaming I/Orepair、RBNO 及 legacy 拓扑变更属于节点级全局限速。推荐取值官方配置注释建议将stream_io_throughput_mb_per_sec设置为网络带宽的 75%可作为初始调优参考实际应结合集群网络状况观察客户端延迟后微调。运行时生效由于配置支持热更新LiveUpdategetstreamthroughput查询到的始终是当前实时值无需重启节点。相关文档Nodetool setstreamthroughput配套的设置命令Nodetool 命令总索引原文档通过 include 引入命令列表底层配置项定义db/config.ccnodetool 客户端实现tools/scylla-nodetool.ccREST API 处理器api/stream_manager.cc、api/config.cc流管理器实现streaming/stream_manager.cc、streaming/stream_manager.hhAPI 描述文件api/api-doc/storage_service.json【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考