flume-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "will zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLUME-3149) reduce cpu cost for file source transfer while still maintaining reliability
Date Sat, 26 Aug 2017 09:11:00 GMT

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

will zhang commented on FLUME-3149:

Btw, just to mention it, for sinks like hdfs when using taildir, we can pass offsets without
actual message body to sink side to take advantage of zeroCopy to further reduce CPU cost,
which is probably another issue.

> 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

This message was sent by Atlassian JIRA

View raw message