-
Notifications
You must be signed in to change notification settings - Fork 64
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
Fixes write benchmarks #111
Conversation
Adding a sleep after the sync fixes the issue. So it seems that Sync() does not properly wait for all writes. |
Adding some logs seems like we don't get the latest transaction even after a table Sync
|
I added the wait as recommended but still missing data with 100 workers. |
Could you add a metric for aborts? Then we could see if potentially for some reason there are aborted writes. If not then this is very likely a correctness issue that we haven't fixed yet. cc @thorfour |
Yes I will |
It doesn't seems like it's an abort.
However sounds like I'm hitting |
Sounds like the issue was duplicate rows. What I'm not sure to understand is why inserting duplicates with concurrency of 10 was fine (accepting all duplicates) but not 100 (rejecting some duplicates). Anyway now we can benchmark insert. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense now! rand
is pseudorandom and when on the same microsecond (or maybe even millisecond, I don't remember) tick, then it produces the same value, so increasing concurrency increases the chances for collisions.
{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1}, | ||
{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2}, | ||
}, | ||
Timestamp: rand.Int63(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably fine for a start, but this isn't really representative of our typical workloads, inserts don't happen with random, but roughly monotonically increasing timestamps. Probably good to optimize these cases as well, but we'll probably see CPU time spent in things that a real workload we use FrostDB for doesn't.
This fixes the write benchmarks with new change in the code and some wrong expectations.
However running it seems to show that we are missing data when running insert in parallel but not when we run sequentially.