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

bug(snapshot): on journal write entry with opcode COMMAND and MULTI_C… #662

Merged
merged 3 commits into from
Jan 12, 2023

Conversation

adiholden
Copy link
Collaborator

Signed-off-by: adi_holden [email protected]

@adiholden adiholden requested a review from dranikpg January 10, 2023 09:18
Comment on lines 436 to 452
command_count = 0
while True:
cmds = await queue.get()
if cmds is None:
queue.task_done()
break

pipe = client.pipeline(transaction=False)
is_multi_transaction = False
if command_count == self.multi_transaction_ratio:
is_multi_transaction = True
pipe = client.pipeline(transaction=is_multi_transaction)
for cmd in cmds:
pipe.execute_command(cmd)

await pipe.execute()
queue.task_done()
++command_count
await client.connection_pool.disconnect()
Copy link
Contributor

@dranikpg dranikpg Jan 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adi, there is no pre-increment in Python 😄

Those are batches generated by the generator - with a default size of 1000 there are usually just a few on the tests. I've seen you reduced the size, so there are more, probably a few dozens. If you run the tests with -s it prints how many batches were submitted.

That doesn't include the runs with a target number of batches, i.e. target_times. Lets rename it to target_ops then and make it calculate the number of batches. If you want, I can do it quickly.

Now you could would run this only one if command_count whould've ever reached self.multi_transaction_ratio. Instead, we can do it probabilistic, i.e. if run it if random.random() < transaction_prob

Also one more small nit, in the snapshot_tests, set it to a zero value, so they don't spend time on filling it with tx

Copy link
Contributor

@dranikpg dranikpg Jan 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more issue, lets encode this on the producer, inside _generator_task, so it can print in in the file as well, where one tx started and where it ended, and instead of sending just the command we'll send a tuple, that indicates whether this is a tx or not

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont understand the comment about set it to 0 in snapshot_tests? what is "they" and "it" when you say "so they don't spend time on filling it with tx"
Isnt it good to test the multi flow in the snapshot tests as well?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The snapshots don't have journal mode enabled. I suppose that the basic snapshot functionality works reliably enough regardless of execution type

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also did not understand this:
That doesn't include the runs with a target number of batches, i.e. target_times. Lets rename it to target_ops then and make it calculate the number of batches.

From what I understand when calling run with target_times, we call the client.pipeline target_times times. Each call will execute batch_size commands (default 100).
What I want to do now is with probability of multi_transaction_probability make the call to client.pipeline with transaction=true. This will execute this batch_size commands in one multi transaction.
This is the logic in the PR, I just commited a fix. are you suggesting something else?

Signed-off-by: adi_holden <[email protected]>
dranikpg
dranikpg previously approved these changes Jan 10, 2023
@@ -408,13 +409,22 @@ def should_run():
while should_run():
start_time = time.time()
blob, deviation = self.gen.generate()
is_multi_transaction = False
if random.random() < self.multi_transaction_probability:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could've been done in just one line with is_tx = random() < prob

@adiholden adiholden requested a review from dranikpg January 10, 2023 14:15
@dranikpg
Copy link
Contributor

dranikpg commented Jan 10, 2023 via email

@@ -325,8 +325,8 @@ OpStatus DflyCmd::StartFullSyncInThread(FlowInfo* flow, Context* cntx, EngineSha
};

// Shard can be null for io thread.
CHECK(!sf_->journal()->OpenInThread(false, ""sv)); // can only happen in persistent mode.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a bug that the shard unique count was not calculated in case the transaction was on non shard thread.
SetMultiUniqueShardCount is not called if ServerState::tlocal()->journal() = null

@adiholden adiholden merged commit 50e14db into main Jan 12, 2023
@romange romange deleted the test_multi_trans branch February 18, 2023 16:07
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

Successfully merging this pull request may close these issues.

2 participants