Skip to content

chore: prepare release 2.10.4 - #992

Open
github-actions[bot] wants to merge 1 commit into
masterfrom
release
Open

chore: prepare release 2.10.4#992
github-actions[bot] wants to merge 1 commit into
masterfrom
release

Conversation

@github-actions

@github-actions github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

This PR was created automatically. Merging it will finalize the changelog for 2.10.4

Fixes

  • Allow concurrent database reads
  • Fix high CPU usage during sector pruning
  • Reverted back to encoding/json from sonic.

Fix the merkle cache bloating the stored sectors table

The cache kept 32 KiB of subtree roots inline on every sector row, which slowed
sector reads, pruning and contract root lookups. Cached roots are discarded on
upgrade and rebuilt on the next read.

@github-project-automation github-project-automation Bot moved this to In Progress in Sia Sep 3, 2026
@github-actions
github-actions Bot force-pushed the release branch 2 times, most recently from 3e0faa6 to 5fd0553 Compare September 4, 2026 15:06
@FloGerl

FloGerl commented Sep 7, 2026

Copy link
Copy Markdown

Just adding an operational data point in case it helps prioritize this release: on v2.10.3 my host is currently becoming effectively unusable after some runtime. The Web UI becomes inaccessible and restarting only resets the problem temporarily.

The hostd SQLite DB is already on a Micron 5210 SATA SSD. During the failure state I'm seeing roughly 3,300–4,600 × 4–5 KiB reads/s, 70–83% SSD utilization, around 22% Linux I/O PSI full avg60, and hostd's Linux OS thread count growing from around 17 after restart to 1,800+; the previous instance reached 5,467 threads.

The workload has also been remarkably consistent, reading around 72–74 GB/hour. Given that #993 is included in this 2.10.4 release PR and appears directly relevant to the SQLite access pattern, this looks like a very strong candidate for the issue I'm seeing.

Based on the symptoms and the storage profile, I strongly suspect the fix in #993 will resolve the situation. Since the corresponding code is already merged and included in this release PR, I'd very much appreciate it if v2.10.4 could be released as soon as reasonably possible so I can verify that in production.

Happy to provide additional measurements or test a build if useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

2 participants