Charlie

Small correction, related to https://github.com/blockstack/stacks-blockchain/issues/2813, not 2183. :)

@igorsyl Yes, but I've confirmed that there was no movement in the stacks-node via `/v2/info` as well. So I don't feel `kubectl logs` is freezing here.

@igorsyl Confirmed it's not slow disk access, but noticed the CPU spiked and stayed at max usage, while memory usage stays relatively the same as it was before. Jude mentioned...

[atlas_stuck_stack_trace.log](https://github.com/stacks-network/stacks-blockchain/files/9209980/atlas_stuck_stack_trace.log) @jcnelson It seemed to happen again, stack trace is attached. Although this time it was after starting back up after a crash (https://github.com/stacks-network/stacks-blockchain/issues/3227), but it appears to be stuck...

@wileyj Would you mind keeping this issue open until there's a release cut with the fix in it? It could be misleading otherwise.

> @wileyj @CharlieC3 Wondering what your thoughts are on the response type in `handle_get_health` (in `rpc.rs`). Would you prefer > > 1. always getting a HttpResponseType of GetHealth, with a...

Jude mentioned in the weekly blockchain meeting that there may be a few configurations we can tweak for the stacks-node miner to reduce stalling during a bitcoin blockstorm. IIRC, those...

Thanks, I've applied these config changes. Let's see how it performs during the next BTC block storm.

There's a tBTC storm occurring right now, and our testnet miner hasn't produced a block since the storm started about 16 hours ago. So it seems the above settings do...

@jcnelson On average it seems about one tBTC/minute ([checking here](https://www.blockchain.com/btc-testnet/blocks?page=1)). The timeouts listed [here](https://github.com/stacks-network/stacks-blockchain/issues/3173#issuecomment-1167675840) should already be much smaller than the number of tBTC blocks being produced.