8000
db: space amp due to virtual tables not accounted in Pebble metrics · Issue #4574 · cockroachdb/pebble · GitHub
More Web Proxy on the site http://driver.im/
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We compute an estimated size for each virtual sst based on the blocks it references in the backing sst. And we correctly use the backing sst size when computing the aggregate size of the DB (for all the metrics that are used in the calculation of Metrics.DiskSpaceUsage()).
But we don't account for the space amp e.g. if backing sst0 has size 100 and is referenced by sst1 and sst2 that have size 10 and 20 respectively, then 100-(10+20)=70 is garbage. When we see higher than expected size of a DB, being able to put an exact number to such space amp is useful. Came up in the context of https://github.com/cockroachlabs/support/issues/3264
We compute an estimated size for each virtual sst based on the blocks it references in the backing sst. And we correctly use the backing sst size when computing the aggregate size of the DB (for all the metrics that are used in the calculation of
Metrics.DiskSpaceUsage()).But we don't account for the space amp e.g. if backing sst0 has size 100 and is referenced by sst1 and sst2 that have size 10 and 20 respectively, then 100-(10+20)=70 is garbage. When we see higher than expected size of a DB, being able to put an exact number to such space amp is useful. Came up in the context of https://github.com/cockroachlabs/support/issues/3264
Jira issue: PEBBLE-410
The text was updated successfully, but these errors were encountered: