如何用 multinode-demo 搭建本地单节点测试网并运行 bench-tps 压测？

如何用 multinode-demo 搭建本地单节点测试网并运行 bench-tps 压测？

【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana

如果你需要在改动 Solana 交易管线代码后量化验证吞吐量，官方仓库提供了multinode-demo/目录下的脚本，可以在本地起一个单节点（singlenode）测试网，并用solana-bench-tps客户端对其发起压测、读出实际处理 TPS。docs/src/clusters/benchmark.md 明确区分了四种演示变体：开发智能合约等高层功能时用 Rust-only 的 singlenode 演示即可；做交易管线性能优化用 enhanced singlenode 演示；共识工作需要至少 Rust-only multinode 演示；要复现官方 TPS 指标则用 enhanced multinode 演示。本文覆盖的是最简单的 Rust-only singlenode 路径：本地单机、无 GPU 依赖，从初始化账本、启动 faucet、启动引导验证节点到跑完一轮bench-tps。

准备条件

文档给出的前提只有两条：

1. 安装 Rust 工具链：按 README.md 第 1 节安装 rustc、cargo 和 rustfmt：

curl https://sh.rustup.rs -sSf | sh source $HOME/.cargo/env rustup component add rustfmt

构建 master 分支时用rustup update保证是最新 stable 版本；构建某个 release 分支时，按 README 的说明查看ci/rust-version.sh中的版本并用rustup install VERSION安装对应工具链（本仓库根目录的 rust-toolchain.toml 中写的是channel = "1.76.0"）。

2. 系统依赖包：在 Linux 上可能需要额外安装系统包。README 给出的 Ubuntu 命令是：

sudo apt-get update sudo apt-get install libssl-dev libudev-dev pkg-config zlib1g-dev llvm clang cmake make libprotobuf-dev protobuf-compiler

Fedora 对应：

sudo dnf install openssl-devel systemd-devel pkg-config zlib-devel llvm clang cmake make protobuf-devel protobuf-compiler perl-core

3. 源码：git clone 仓库后进入solana目录。文档特别提醒：demo 代码在 release 之间可能随新特性加入而损坏，第一次跑 demo 时建议先检出最新 release 再执行后续步骤：

TAG=$(git describe --tags $(git rev-list --tags --max-count=1)) git checkout $TAG

编译：为什么必须用 release 构建

文档强调要先确保 vote program 等关键程序在节点启动前构建完成，并说明这里使用 release 构建以获得好的性能：

cargo build --release

如果想用 debug 构建，直接cargo build并省略脚本里的NDEBUG=1前缀即可（见 multinode-demo/common.sh：NDEBUG非空时脚本会以--release调用 cargo，否则用 debug 构建）。本文后续所有命令都按文档推荐保留NDEBUG=1。

初始化 genesis ledger

NDEBUG=1 ./multinode-demo/setup.sh

这条命令会生成网络初始化所需的 genesis ledger。查看 multinode-demo/setup.sh 源码可以确认它做了什么，也帮你理解后续脚本的依赖：

• 删除并重建config/bootstrap-validator目录——注意副作用：如果该目录里已有旧的 ledger 和身份/投票/质押密钥，会被清掉重新生成，首次使用没有问题，重复使用会重置本地测试网状态；
• 生成 faucet 钱包config/faucet.json，以及 bootstrap validator 的identity.json、stake-account.json、vote-account.json；
• 调用fetch-spl.sh获取 SPL 配置，若生成了spl-genesis-args.sh则将其内容并入 genesis 参数；
• 最后以默认参数调用solana-genesis，其中--faucet-lamports默认500000000000000000，--cluster-type development。

启动 faucet

验证节点和客户端需要 faucet 发放测试代币（文档称之为 "air drops"），faucet 监听在127.0.0.1:9900：

NDEBUG=1 ./multinode-demo/faucet.sh

multinode-demo/faucet.sh 会检查config/faucet.json是否存在，不存在会提示你先运行setup.sh并退出。faucet 只需要在验证节点第一次启动时运行：验证节点若自己没有代币会主动向 faucet 申请，之后的重启不需要再开着它。

启动 bootstrap validator

启动前先确认两件事（来自 docs/src/clusters/benchmark.md）：

• 知道本机 IP 地址（单节点场景即本机）；
• UDP 端口8000-10000已开放。

在另一个 shell中执行：

NDEBUG=1 ./multinode-demo/bootstrap-validator.sh

等待几秒钟让服务端初始化，日志打印出leader ready...说明它已准备好接收交易。

关于这个脚本，multinode-demo/bootstrap-validator.sh 里有几个行为值得知道：

• 固定使用--rpc-port 8899、--gossip-port 8001，ledger 目录即config/bootstrap-validator，并内置--rpc-faucet-address 127.0.0.1:9900；
• 默认会自动重启：脚本用trap捕获退出并循环拉起进程，如果验证节点进程死亡会打印validator exited, restarting；加--no-restart参数可关闭该行为；
• 支持透传的参数有限（--init-complete-file、--gossip-host、--dev-halt-at-slot、--limit-ledger-size、--log等白名单），传未列出的参数会打印Unknown argument并退出。

如果脚本一启动就报Testnet requires GPUs, but none were found! Aborting...，说明SOLANA_GPU_MISSING=1，即运行环境被检测到需要 GPU 却没有——Rust-only 单节点路径不带SOLANA_CUDA时应不会出现这个检查，出现时先检查环境是否残留了 GPU 相关环境变量。

运行 bench-tps 压测

测试网就绪后，在第三个 shell 中：

NDEBUG=1 ./multinode-demo/bench-tps.sh # runs against localhost by default

multinode-demo/bench-tps.sh 只是solana-bench-tps的一层封装，未显式给出的参数使用以下默认值：

脚本会把额外参数原样透传给solana-bench-tps，所以想缩短一轮压测时间，可以直接：

NDEBUG=1 ./multinode-demo/bench-tps.sh --duration 30 --tx-count 1000

文档对压测过程的说明：客户端会启动多个线程尽快向测试网发送 500,000 笔交易，然后周期性 ping 测试网统计这段时间内处理了多少笔。demo 会故意用 UDP 包洪泛网络，网络几乎必然丢弃其中一部分包，这恰好让测试网有机会逼近 710k TPS 的上限条件。客户端在自己判定"测试网不会再处理更多交易"后结束运行。多节点变体下每个验证节点也会各自打印 TPS 测量值。

结果验证与调试

判断压测是否成功的标准就是终端输出：文档写明 "You should see several TPS measurements printed to the screen"，即屏幕应出现若干轮 TPS 测量读数。如果完全没有任何 TPS 输出，先核对leader ready...是否打印过、--url是否指向了本机的 8899 端口。

文档还给出了两个排查手段，都只服务于"看节点内部发生了什么"：

1. 按模块开启日志：在运行 leader 或 validator之前设置RUST_LOG：

export RUST_LOG=solana=info,solana::banking_stage=debug

文档说明：debug用于低频调试信息，trace用于可能高频的信息，info用于性能相关日志；开启 SBF 程序日志则用export RUST_LOG=solana_bpf_loader=trace。

2. 用 GDB 附加运行中的进程（进程名是solana-validator）：

sudo gdb attach <PID> set logging on thread apply all bt

这会把所有线程的栈回溯 dump 到gdb.txt。该命令需要 root 权限并会附加到正在运行的验证节点进程，确认<PID>是本机的验证节点进程后再执行。

限制与边界

• 单节点演示只覆盖 Rust-only 场景。要复现官方 TPS 指标需要 enhanced multinode 演示；Linux 上要跑性能增强（CUDA）验证节点必须先安装 CUDA 10.0，并按文档执行./fetch-perf-libs.sh，然后带SOLANA_CUDA=1运行bootstrap-validator.sh/validator.sh（SOLANA_CUDA在非 Linux 平台上会被common.sh直接清除并告警）。
• demo 代码在 release 之间可能损坏，首次运行建议检出最新 release（见准备条件）。
• 本文所有NDEBUG=1命令对应 release 构建；改跑 debug 构建时省略NDEBUG=1，但性能数据不具备与 release 构建可比性。

下一步

完成单节点基线后，文档给出的延伸路径：在同一测试网上追加节点组成多节点网络（NDEBUG=1 ./multinode-demo/validator-x.sh，在独立 shell 中逐个启动），或直接面向公共 devnet 做客户端验证，这些在 docs/src/clusters/benchmark.md 的 Multinode Testnet 与 Developer Testnet 小节有对应说明。

【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana