/prombench main

⏱️ Welcome to Prometheus Benchmarking Tool. ⏱️

Compared versions: PR-15365 and main

After successful deployment, the benchmarking results can be viewed at:

• Prometheus Meta
• Prombench Dashboard
• Grafana Explorer, Loki logs
• Parca profiles (e.g. in-use memory)

Other Commands:
To stop benchmark: /prombench cancel
To restart benchmark: /prombench restart main

/prombench cancel

Benchmark cancel is in progress.

/prombench main

⏱️ Welcome to Prometheus Benchmarking Tool. ⏱️

Compared versions: PR-15365 and main

After successful deployment, the benchmarking results can be viewed at:

• Prometheus Meta
• Prombench Dashboard
• Grafana Explorer, Loki logs
• Parca profiles (e.g. in-use memory)

Other Commands:
To stop benchmark: /prombench cancel
To restart benchmark: /prombench restart main

/prombench cancel

Benchmark cancel is in progress.

/prombench main

⏱️ Welcome to Prometheus Benchmarking Tool. ⏱️

Compared versions: PR-15365 and main

After successful deployment, the benchmarking results can be viewed at:

• Prometheus Meta
• Prombench Dashboard
• Grafana Explorer, Loki logs
• Parca profiles (e.g. in-use memory)

Other Commands:
To stop benchmark: /prombench cancel
To restart benchmark: /prombench restart main

/prombench cancel

Benchmark cancel is in progress.

/prombench main

⏱️ Welcome to Prometheus Benchmarking Tool. ⏱️

Compared versions: PR-15365 and main

After successful deployment, the benchmarking results can be viewed at:

• Prometheus Meta
• Prombench Dashboard
• Grafana Explorer, Loki logs
• Parca profiles (e.g. in-use memory)

Other Commands:
To stop benchmark: /prombench cancel
To restart benchmark: /prombench restart main

Benchmark tests are running for 3 days! If this is intended ignore this message otherwise you can cancel it by commenting: /prombench cancel

Benchmark tests are running for 5 days! If this is intended ignore this message otherwise you can cancel it by commenting: /prombench cancel

Might be useful for other operations (WAL writing?

Would this require holding WAL records in memory until there is 4KB to write?
That gives me mixed feelings.

Might be useful for other operations (WAL writing?

Would this require holding WAL records in memory until there is 4KB to write? That gives me mixed feelings.

Yes, theoretically we could omit writing up to "offsetAlign-1" of data, we could work around that, but it might result in unwanted side effects like write amplification, bloat, and switching between direct and buffered I/O...

That being said, we already write in blocks of pageSize=32KB, so the alignment should be ensured in most cases.

I'll need to look into this in more detail to see if it's really worth it.

Adding the metric container_memory_usage_bytes, which a lot of people look at, to the Prombench dashboard we see that it is significantly lower with Direct IO.

Adding the metric container_memory_usage_bytes, which a lot of people look at

Cool. What happens if you plot just file cache memory?

Another thing that DIO can buy is placing less pressure on page cache evictions and thus reducing the number of major page faults occurring in the places using mapped IO. Could be another useful metric to look at.

What happens if you plot just file cache memory?

There is one in here https://github.com/prometheus/proposals/pull/45/files
Yes, less page cache should/will imply less page cache eviction.

force push + rebase, the diff wouldn't be helpful :(

without checking the conflicts, I'd say that a new feature flag was added, again.
I'll resolve them, hope it's the last time.