triedb/pathdb, eth: introduce Double-Buffer Mechanism in PathDB #30464
Conversation
rjl493456442
force-pushed
the
multibuffer
branch
from
569b961
to
b48c0c9
Compare
Previously, PathDB used a single buffer to aggregate database writes, which needed to be flushed atomically. However, flushing large amounts of data (e.g., 256MB) caused significant overhead, often blocking the system for around 3 seconds during the flush. To mitigate this overhead and reduce performance spikes, a double-buffer mechanism is introduced. When the active buffer fills up, it is marked as frozen and a background flushing process is triggered. Meanwhile, a new buffer is allocated for incoming writes, allowing operations to continue uninterrupted. This approach reduces system blocking times and provides flexibility in adjusting buffer parameters for improved performance.
rjl493456442
force-pushed
the
multibuffer
branch
from
b48c0c9
to
20b4ffd
Compare
| nodes := writeNodes(batch, b.nodes, clean) | ||
| rawdb.WritePersistentStateID(batch, id) | ||
|
|
||
| // Flush all mutations in a single batch |
There was a problem hiding this comment.
Note: at this point, mutations were already applied on the clean, i.e, dl.cleans cache. That happened during writeNodes. I've tried to figure out if that is a problem, but come to the conclusion that it's fine, but just wanted to raise it so you can also give it a think.
Regarding "flush all mutations in a single batch" -- is that important only because of crash-safety, or some other more subtle reason?
There was a problem hiding this comment.
How about this
in disklayer.go, function node(), we lookup a node. Order:
- buffer
- frozen
- cleans
- database
- And if found, write to cleans
if dl.cleans != nil && len(blob) > 0 {
dl.cleans.Set(key, blob)
cleanWriteMeter.Mark(int64(len(blob)))
}I'm trying to think of a case where this write-to-cleans conflicts with the write-to-cleans in the background committer writeNodes method.
There was a problem hiding this comment.
- if it's found in buffer/frozen => return and no interaction with cache
- if it's found in cache => return
- if it's found in disk (it implicitly means the item is not in these places above, even the item is marked as deleted, it will still be caught in buffer/frozen/cache), load it from db and add it into the cache
so, no conflict should happen
But i have to say it's a really good point, i haven't thought about it
There was a problem hiding this comment.
Regarding "flush all mutations in a single batch" -- is that important only because of crash-safety, or some other more subtle reason?
Only because of crash-safety
Previously, PathDB used a single buffer to aggregate database writes, which needed to be flushed atomically. However, flushing large amounts of data (e.g., 256MB) caused significant overhead, often blocking the system for around 3 seconds during the flush.
To mitigate this overhead and reduce performance spikes, a double-buffer mechanism is introduced. When the active buffer fills up, it is marked as frozen and a background flushing process is triggered. Meanwhile, a new buffer is allocated for incoming writes, allowing operations to continue uninterrupted.
This approach reduces system blocking times and provides flexibility in adjusting buffer parameters for improved performance.