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
Trace analyzer space usage #29
Comments
no, it is not common, can you show the command you use? |
A few other comments:
I hope this helps. |
I ran the following command:
But if I used --reuse instead of --all, I saw the same pattern. The command completed on a 308MB trace after generating a 132GB file <>..csv.reuseWindow_w300_rt, but the <>.csv.reuse file has zero bytes in it, as do .csv.accessRtime, .csv.accessVtime, .csv.popularity and .csv.size |
I am not able to reproduce this problem, do you mind sharing a few lines of the input file?
:) |
Here are a few lines of my csv file: 1695337878208738,4096,4096 |
Here is the entire gzipped trace: https://people.ece.ubc.ca/~sasha/TMP/evict-btree.csv.gz |
Thank you for sharing the trace!
After sorting the data, the analysis can finish without any issue. One minor suggestion, when using csv traces, if the object id (e.g., block address) is numeric, adding I hope this helps. Thank you for reporting the issue! |
Hi folks, I am using the trace analyzer for reuse distance on a 371MB trace. The analyzer keeps running, but can never finish, because it runs out of disk space. For example, last time I tried my .reuseWindow_w300_rt file grew to 91GB, filling out the remaining space in my file system. At that point, trace analyzer hung, not quitting or producing any info messages.
Is it normal to generate 91GB+ of .reuseWindow_w300_rt for a 371MB trace? Is there a way to run the trace analyzer differently so that it actually completes?
The text was updated successfully, but these errors were encountered: