Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need IO record and replay facility #2403

Open
xemul opened this issue Aug 24, 2024 · 2 comments
Open

Need IO record and replay facility #2403

xemul opened this issue Aug 24, 2024 · 2 comments

Comments

@xemul
Copy link
Contributor

xemul commented Aug 24, 2024

When checking IO-related issues on prod. nodes we only have metrics and some Linux tooling at hand. Metrics show averaged over several minutes counters, while Linux tooling shows the result of IO scheduler's work. To get better understanding of what's going on with seastar IO stack, we need to understand how the requests are submitted by uppoer code (read -- Scylla code) to seastar, not by seastar to Linux/disk.

One of the tools to help that can be IO tracer, that collects info about requests that are queued to IO scheduler. Very important parameter here is submission timestamp, because currently IO scheduler is built with the idea of uniform workloads in mind. Non-uniform input is handled, but the understanding of how exactly "non-uniform" it is is missing.

@avikivity
Copy link
Member

Isn't the input to the I/O scheduler dependent on the output? For example, a sequential workload's submit timestamps will depend on when the requests are completed (even with read-ahead or write-behind).

@xemul
Copy link
Contributor Author

xemul commented Aug 26, 2024

Isn't the input to the I/O scheduler dependent on the output?

Well, in math sense yes, scheduler defines output = sched_fn(input) so in theory we could deduce a reverse function for input = ~sched_fn(output), but I don't have good ideas how to do it.

For example, a sequential workload's submit timestamps will depend on when the requests are completed (even with read-ahead or write-behind).

No, to get submit timestamp from complete timestamp, we need execution time, but it's not cut in stone. Quite opposite, we measure execution from from submit and complete timestamps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants