#31672 rpc: add cpu_load to getpeerinfo

ReviewabilityReviewsAgreementSize
#31672 vasild rpc: add cpu_load to getpeerinfoAuthor silent 186d1 (+1) -1Blocked159 + 1 tests
  • Help node operators identify resource-intensive or abusive peers
  • Track and expose message processing CPU usage per peer in getpeerinfo and -netinfo
  • Lay groundwork for future peer-prioritization and anti-DoS measures
  • Author silent for 180 days; review may wait a long time for a response
  • Wide concept support for peer CPU tracking to combat DoS (jonatack, laanwj, mzumsande, hodlinator)
  • Verified in testing on signet IBD and -netinfo (jonatack, BrandonOdiwuor, yuvicc)
  • Unaddressed objection: metrics are non-actionable, flame graphs or wall time are better (ajtowns)
  • Nonblocking objection: exploratory metrics should not go into production getpeerinfo (sipa)
  • Suggested using a decaying average instead of connection-wide average (sipa)
  • 159 lines added or modified outside tests
  • 1 lines added or modified in tests
  • 4 lines removed in total
  • 8 files, 2 commits
RPC / REST / ZMQ#45 of 55
P3 · new feature
  • P3 because exploratory peer monitoring metrics without external demand offer modest value
  • Provides diagnostic value during DoS investigation but remains marginal
  • Ranking pass: Moved down 14: exploratory per-peer metric, its own card calls the value marginal and no external demand is cited.
Ranking notes
Utilities (logging, arguments, libraries)#44 of 59
P3 · new feature
  • P3 because cross-platform thread CPU timing utilities are incremental internal infrastructure
  • Utility benefit is limited to supporting exploratory diagnostics
  • Ranking pass: Moved up slightly: new cross-platform thread CPU timing is reusable and feeds peer-prioritization work.
Ranking notes
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.

Goal

Track CPU time spent by the message processing thread on each peer and expose it as a normalized `cpu_load` metric in `getpeerinfo` and `bitcoin-cli -netinfo`. The metric is calculated in per milles (‰) of connection duration using thread CPU time clocks on POSIX and Windows.

Problem: Node operators cannot see which peers consume disproportionate CPU time during message processing, making it difficult to detect resource-intensive or abusive peers and evaluate peer-scheduling policies.

Evidence of importance:

  • Author description: "Monitoring CPU usage is useful on its own. Also related to https://github.com/bitcoin/bitcoin/issues/31033 [Prioritize processing of peers based on their CPU usage]."

Scope: Adds cross-platform per-thread CPU timing utilities in `src/util/time.{h,cpp}` using `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` on POSIX and `GetThreadTimes()` on Windows.

Reviewability

Stale · Author silent 186d

No author activity for 186 days; a review may wait a long time for a response.

Waiting on (from the thread read):

  • author: address standing objections from sipa regarding production RPC exposure and ajtowns regarding utility and methodology 2026-08-11

Agreement

Blocked

objection that needs a change, nobody has replied (ajtowns)

Thread notes: Added Concept ACK from hodlinator. The PR remains waiting on the author to address standing objections from sipa regarding the RPC interface and ajtowns regarding the metric design.

Objections, suggestions, and questions:

ReviewerTypeHarm, request, or questionStatusMust beAuthor repliedQuote
fanquake (member)question, usefulnessShow usage data indicating that the changes are useful before changing the APIanswered · author shared local testing results showing 65x difference between peersansweredyes2025-01-17: 'Before changing our API, it'd be good to atleast show some usage that indicates that the changes here are useful. I assume you've already been running this locally, and collecting the data, so it'd be'
Status from: 2025-01-17: vasild: 'Yes, I have been running this locally - there is like 65x difference between the least and most demanding peers.'
maflcko (member)objection, maintenanceThe metric will silently break if message processing becomes multi-threaded in the futureaccepted · reviewer acknowledged it is fine if current work is minimal and future changes can handle multi-threadingansweredyes2025-01-23: 'The code here assumes that Bitcoin Core is single threaded, which may be true right now, but could change in the future.'
Status from: 2025-02-05: maflcko: 'I guess that is fine if the work is minimal, or code could be added to do the additional accounting if the work is subst'
yuvicc (contributor)question, correctnessAsks why cpu_load reports null in getpeerinfo outputaccepted · author explained field is omitted within first second of connection before measurement; reviewer acknowledgedansweredyes2025-01-26: 'Also, during my observations I found value null as well... Any idea why is it null? maybe it is about to get disconnected.'
Status from: 2025-01-27: yuvicc: 'Got it, thanks!'
rebroad (contributor)suggestion, usefulnessDivide CPU load by transactions accepted into the chain or mempool, as CPU load alone is uselessanswered · author agreed that would be useful but stated CPU load is needed first and TXs accepted can be added separatelyansweredyes2025-07-28: 'NACK. cpu load alone is a useless metric. However, CPU load divided by TXs accepted into the chain (or mempool) could be a useful metric.'
Status from: 2026-04-29: vasild: 'I agree that would be useful. But for this we need the CPU load. "TXs accepted", if possible, can be added separately.'
ajtowns (member)question, approachWhy monitor CPU time rather than real time given disk access delays and OS-specific complexity?contested · author defended measuring CPU time; reviewer later reiterated preference for raw-clock time in c:5247453912answeredyes2025-10-29: 'Why monitor cpu time rather than real time? Isn't time spent waiting for disk access while looking up the utxo set equally problematic?'
Status from: 2026-08-11: ajtowns: 'I still think raw-clock-time would be simpler and pretty much equally accurate'
sipa (member)objection, interfaceExposes an exploratory metric in production getpeerinfo instead of an experimental RPCopenansweredno2026-05-26: 'I'm not sure about making it part of the "production" RPC getpeerinfo however... better to create an explicitly experimental "resource usage dump info" RPC'
sipa (member)suggestion, approachUse a decaying average rather than an overall averageopenansweredno2026-05-26: 'Also, I think this should be a decaying average rather than an overall average. Maybe a time factor of 1 hour or so?'
ajtowns (member)objection, approachIntroduces per-peer CPU metrics that are not actionable, not comparable between peers, and less appropriate than raw wall-clock time or flame graphsopenchangedno2026-08-11: 'I think the idea of adding better performance monitoring could be valuable, but I don't think this is the right way of doing that... it doesn't seem to result in actionable metrics'

Support:

  • jonatack (member) (Concept ACK, 2025-01-16): Useful if reliable and helps pave the path to peer resource prioritization in #31033
  • sipa (member) (Concept ACK, 2025-01-16): (no reason given) [not substantive]
  • theStack (member) (Concept ACK, 2025-01-16): (no reason given) [not substantive]
  • BrandonOdiwuor (contributor) (Concept ACK, 2025-01-16): (no reason given) [not substantive]
  • yuvicc (contributor) (Concept ACK, 2025-01-26) [read]: Clean way to get peer CPU usage where tracepoints lack cross-platform support and paves the way for #31033
  • yuvicc (contributor) (Tested ACK, 2025-01-27) [tested]: (no reason given) [not substantive]
  • laanwj (member) (Concept ACK, 2025-04-09): Useful as a first step for anti-DoS measures
  • mzumsande (member) (Concept ACK, 2025-04-14): Useful for detecting attackers in an actual DoS attack, though high cpu_load is not inherently bad
  • jonatack (member) (Tested ACK, 2025-04-16) [tested: -netinfo, getpeerinfo]: Tested RPC getpeerinfo and live dashboard with -netinfo
  • yuvicc (contributor) (ACK, 2025-04-16): (no reason given) [not substantive]
  • yuvicc (contributor) (ACK, 2026-05-25) [both]: Code looks good and tested on macOS
  • BrandonOdiwuor (contributor) (Tested ACK, 2026-08-21) [tested]: Tested on Ubuntu during Signet IBD; found metric responsive and useful for identifying expensive connections
  • hodlinator (member) (Concept ACK, 2026-10-26): Working towards accomplishing #31033 seems like a good step to improve general DoS resistance.

Participants:

  • BrandonOdiwuor (contributor, support, 2 statements 2025-01-16 to 2026-08-21): Concept ACK and tested ACK during Signet IBD
  • jonatack (member, support, 7 statements 2025-01-16 to 2025-04-19): Concept ACK and tested ACK; proposed netinfo integration
  • sipa (member, objection, 2 statements 2025-01-16 to 2026-05-26): Concept ACK on exploratory monitoring, but objects to adding un-decayed metric to production getpeerinfo
  • theStack (member, support, 1 statements 2025-01-16 to 2025-01-16): Concept ACK, noted Windows support gap originally
  • fanquake (member, neutral, 7 statements 2025-01-17 to 2025-04-17): Questioned API change vs tracepoints, reviewed build and doc comments
  • maflcko (member, neutral, 6 statements 2025-01-23 to 2025-04-09): Noted single-threaded message processing assumptions and chrono nits
  • luke-jr (contributor, question, 1 statements 2025-01-25 to 2025-01-25): Asked maflcko about thread-specific timers
  • yuvicc (contributor, support, 6 statements 2025-01-26 to 2026-05-25): Concept ACK, tested ACK, and code-review ACK
  • laanwj (member, support, 1 statements 2025-04-09 to 2025-04-09): Concept ACK, finds per-peer CPU usage useful for anti-DoS measures
  • mzumsande (member, support, 2 statements 2025-04-14 to 2025-04-14): Concept ACK with caveat that high cpu_load is not inherently bad
  • rebroad (contributor, objection, 1 statements 2025-07-28 to 2025-07-28): NACK; argued cpu load alone is useless without transaction acceptance context
  • ajtowns (member, objection, 3 statements 2025-10-29 to 2026-08-13): Argues cpu load per peer is non-actionable, not comparable, and clock time or flame graphs are preferable
  • 0xB10C (member, neutral, 1 statements 2026-01-26 to 2026-01-26): Shared metrics and peer data from running node
  • sedited (member, neutral, 2 statements 2026-05-02 to 2026-10-02): Pinged reviewers and asked author about unaddressed feedback
  • hodlinator (member, support, 1 statements 2026-10-26 to 2026-10-26): Concept ACK, noting work towards #31033 improves DoS resistance

Files

1 lines under test/bench/ci.

  • src/util/time.cpp +56/-0
  • src/util/time.h +44/-0
  • src/bitcoin-cli.cpp +31/-4
  • doc/release-notes-31672.md +9/-0
  • src/rpc/net.cpp +9/-0
  • src/net.h +6/-0
  • src/net.cpp +4/-0
  • test/functional/rpc_net.py +1/-0

Card

The short text the ranking pass compares across PRs.

Adds a cpu_load field to getpeerinfo and a cpu column to bitcoin-cli -netinfo, reporting the CPU time spent in message handling per peer as a proportion of connection duration in per milles. Node operators currently lack visibility into which peers consume the most CPU processing time. The author notes peer CPU monitoring is useful on its own and aids work on peer processing prioritization (#31033). It introduces OS-level thread CPU time measurement on POSIX and Windows.

Data

dossier JSON · extract JSON · model ledger, generated 2026-10-27T01:25, confidence high, input hash 02dffe5046ea72fe
thread read through 2026-10-26 (74 statements), head 52f1efc06a
labels: RPC/REST/ZMQ

Categories

RPC / REST / ZMQ

P3 · new feature (ranking pass: Moved down 14: exploratory per-peer metric, its own card calls the value marginal and no external demand is cited.)

Adds a normalized cpu_load metric to getpeerinfo and bitcoin-cli -netinfo to help operators monitor peer resource usage. Reviewers note its diagnostic value during DoS investigation, but new exploratory metrics without explicit external consumer demand are P3.

Membership: Labeled RPC/REST/ZMQ; modifies src/rpc/net.cpp to add cpu_load to getpeerinfo and updates bitcoin-cli -netinfo.

Factors: security/stability 1, bug 0, performance 0, user value 1, leverage 1

Utilities (logging, arguments, libraries)

P3 · new feature (ranking pass: Moved up slightly: new cross-platform thread CPU timing is reusable and feeds peer-prioritization work.)

Introduces cross-platform thread CPU timing utilities using clock_gettime on POSIX and GetThreadTimes on Windows. The utilities are a clean, functional addition to the time library, but represent incremental internal infrastructure.

Membership: Adds thread CPU timing implementations in src/util/time.h and src/util/time.cpp.

Factors: security/stability 1, bug 0, performance 0, user value 1, leverage 1