From 37ae0ce51a56c1e657b90bf44677f06a642d93c3 Mon Sep 17 00:00:00 2001 From: Seebs Date: Tue, 25 Oct 2022 13:12:18 -0500 Subject: [PATCH] don't obtain stack traces on rbf.Tx creation We thought stack traces were mildly expensive. We were very wrong. Due to a complicated issue in the Go runtime, simultaneous requests for stack traces end up contending on a lock even when they're not actually contending on any resources. I've filed a ticket in the Go issue tracker for this: https://github.com/golang/go/issues/56400 In the mean time: Under some workloads, we were seeing 85% of all CPU time go into the stack backtraces, of which 81% went into the contention on those locks. But even if you take away the contention, that leaves us with 4/19 of all CPU time in our code going into building those stack backtraces. That's a lot of overhead for a feature we virtually never use. We might consider adding a backtrace functionality here, possibly using `runtime.Callers` which is much lower overhead, and allows us to generate a backtrace on demand (no argument values available, but then, we never read those because they're unformatted hex values), but I don't think it's actually very informative to know what the stack traces were of the Tx; they don't necessarily reflect the current state of any ongoing use of the Tx, so we can't necessarily correlate them to goroutine stack dumps, and so on. --- rbf/db.go | 2 -- 1 file changed, 2 deletions(-) diff --git a/rbf/db.go b/rbf/db.go index 5f5f24088..fa5d32b1f 100644 --- a/rbf/db.go +++ b/rbf/db.go @@ -6,7 +6,6 @@ import ( "io" "os" "path/filepath" - "runtime/debug" "sort" "sync" "syscall" @@ -668,7 +667,6 @@ func (db *DB) Begin(writable bool) (_ *Tx, err error) { pageMap: db.pageMap, walPageN: db.walPageN, writable: writable, - stack: debug.Stack(), // DEBUG DeleteEmptyContainer: true, }