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

Split events emitted at once to multi chunks #1062

Merged
merged 16 commits into from
Jul 20, 2016

Conversation

tagomoris
Copy link
Member

This change make it possible to emit large event stream into some chunks.
It can't be done at v0.10/v0.12, but it should be done to remove warnings about chunks larger than chunk limit size.

When I was writing this change, I found some problems about locking chunks and buffer global lock.
I also improved it because the buffer with this change will operate much more chunks than ever.

@tagomoris
Copy link
Member Author

@repeatedly Please review this change!

@tagomoris tagomoris force-pushed the split-events-emitted-at-once-to-multi-chunks branch from e960f94 to 8985883 Compare June 21, 2016 01:39
@repeatedly
Copy link
Member

@sonots Could you review this change first?

@repeatedly
Copy link
Member

BTW, tests are filed on Mac environment. Is this known issue?

@@ -70,6 +88,10 @@ def repeatable?
true
end

def slice(index, num)
self.dup
Copy link
Member

@repeatedly repeatedly Jun 21, 2016

Choose a reason for hiding this comment

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

If slice(1, 1) is called, slice should return same content, not empty stream?

Copy link
Member Author

@tagomoris tagomoris Jun 22, 2016

Choose a reason for hiding this comment

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

I can't understand what you mean.
But, I think that OneEventStream#slice should return empty stream for first argument >=1.
I'll fix this code so.

@tagomoris
Copy link
Member Author

@repeatedly That's a know one, I'm investigating it continuously.

if splits_count > data.size
splits_count = data.size
end
slice_size = if splits_count > data.size
Copy link
Member Author

Choose a reason for hiding this comment

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

The first condition is nonsense.

@tagomoris tagomoris force-pushed the split-events-emitted-at-once-to-multi-chunks branch from 8985883 to 9ae7d1b Compare June 27, 2016 04:25
@tagomoris
Copy link
Member Author

I pushed some commits to fixes along with some comments on this thread, and rebased on current master HEAD.

@tagomoris
Copy link
Member Author

AppVeyor's one task is still failing (maybe file handle leak or something else), but I'll merge this later.
@repeatedly Any other review comments?

@repeatedly
Copy link
Member

I need more time to review multi-threaded part and benchmark.
For safety v0.14.1 release, merging this patch is better in v0.14.2.

@tagomoris
Copy link
Member Author

Memo: I found that this change miss to update Fluent::Compat::BufferedOutput#handle_stream_simple.

@tagomoris tagomoris force-pushed the split-events-emitted-at-once-to-multi-chunks branch from 9ae7d1b to 5e051e2 Compare July 4, 2016 02:13
@tagomoris
Copy link
Member Author

I rebased changes on master HEAD, and added a fix for compat layer.

@tagomoris
Copy link
Member Author

@repeatedly Please review the changes. I'll take a look for test failures in osx environments.

@tagomoris tagomoris force-pushed the split-events-emitted-at-once-to-multi-chunks branch from 14c7719 to 164fa09 Compare July 4, 2016 05:50
end
# @size should be updated always right after unpack.
# The real size of unpacked objects are correct, rather than given size.
@size = @unpacked_times.size
Copy link
Member

Choose a reason for hiding this comment

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

After unpacked, @data should be set to nil for GC?

Copy link
Member

@repeatedly repeatedly Jul 7, 2016

Choose a reason for hiding this comment

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

Hmm... @data is used in empty?.

Copy link
Member Author

Choose a reason for hiding this comment

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

@data should be kept as is, because #to_msgpack_stream returns @data itself.

@tagomoris
Copy link
Member Author

@repeatedly Please check this change with latest commits.

@tagomoris
Copy link
Member Author

@repeatedly ping?

end
end

unless stored
# try step-by-step appending if data can't be stored into existing a chunk in non-bulk mode
write_step_by_step(metadata, data, data.size / 3, &block)
write_step_by_step(metadata, data, format, 10, &block)
Copy link
Member

@repeatedly repeatedly Jul 13, 2016

Choose a reason for hiding this comment

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

Is this 10 heuristic value?
If so, comment is good for why we choose 10.

Copy link
Member Author

Choose a reason for hiding this comment

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

I added a comment for it.

@tagomoris tagomoris force-pushed the split-events-emitted-at-once-to-multi-chunks branch from 136678b to fe3a860 Compare July 19, 2016 06:25
@tagomoris
Copy link
Member Author

@repeatedly I added a commit to add code comment. Is that all for your review comment?

@tagomoris tagomoris merged commit 19b6e05 into master Jul 20, 2016
@tagomoris tagomoris deleted the split-events-emitted-at-once-to-multi-chunks branch July 20, 2016 07:59
@repeatedly
Copy link
Member

I tested split case CPU usage on 2 c3.8xlarge instances.
Here is the result with 100k / sec.
From the result, if the incoming events are larger than buffer_chunk_limit, CPU usage is high.

fluentd-benchmark one_forward based configuration

flush_interval 0s. No split chunks.

  • Forwarder CPU: 78%
  • Aggregator CPU: 15%

Baseline: v0.12.27

  • Fowarder CPU: 69%
  • Aggregator CPU: 10.5%

Use tdlog instead of flowcounter_simple for buffer test

Forwarder (buffer_chunk_limit 32m)

  • CPU: 72%

Aggregator (tdlog + buffer_chunk_limit 65m)

No split chunks because aggregator's buffer_chunk_limit is larger than forwarder's chunk.

  • CPU: 45% - 70%

Aggregator (tdlog + buffer_chunk_limit 8m)

Split 32mb chunks into smaller chunks.

  • CPU: 65% - 85% (average 75%)

@tagomoris
Copy link
Member Author

tagomoris commented Aug 8, 2016

It is in my design - we can't help to consume CPU usage for splitting a chunk into chunks. We get safer chunking in exchange for additional CPU usage.
@repeatedly How do you think about it?

@repeatedly
Copy link
Member

@tagomoris Yeah, hard to reduce CPU usage for it.
But we should mention CPU usage issue in the announcement and fluentd-docs because
it may degrade the pipeline performance on aggregator node.

@tagomoris
Copy link
Member Author

I agree about it.

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

Successfully merging this pull request may close these issues.

2 participants