[ 
https://issues.apache.org/jira/browse/FLUME-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16137008#comment-16137008
 ] 

Bessenyei Balázs Donát commented on FLUME-3149:
-----------------------------------------------

Hi [~zyfo2],

Thank you for the issue report and the information!

In case it is not too much of an effort, can you please share the patch you 
have made?
That would allow the community to review the impact of the change and see if we 
can merge it. The idea of improving performance does sound great to me.

If you need any help with creating a pull request or anything like that, please 
let me know.


Thank you,

Donat

> reduce cpu cost for file source transfer while still maintaining reliability
> ----------------------------------------------------------------------------
>
>                 Key: FLUME-3149
>                 URL: https://issues.apache.org/jira/browse/FLUME-3149
>             Project: Flume
>          Issue Type: Improvement
>          Components: File Channel
>            Reporter: will zhang
>
> File channel tracks transferred events and use transnational mechanism to 
> make transfer recoverable. However, it increases CPU cost due to frequent 
> system calls like write, read, etc. The Cpu cost could be very high if the 
> transfer rate is high. In contrast, Memory channel  has no such issue which 
> requires only about 10% of CPU cost  in the same environment but it's not 
> recovered if the system is down accidentally.
> For sources like taildir/spooldir, I propose we could track offsets of file 
> and store them locally to achieve reliability while still using memory 
> channel to reduce CPU cost. Actually, I have already implemented this feature 
> by storing the offsets in event headers and passing it to my own 
> "offsetMemoryChannel" and store theses offsets in local disk in our 
> production which reduces CPU cost by about 90 percent.
> Please let me know if it's worthwhile to have this feature in community 
> version. Thank you.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to