[
https://issues.apache.org/jira/browse/FLUME-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16142822#comment-16142822
]
will zhang commented on FLUME-3149:
-----------------------------------
Hi [~fszabo],
1. Some of our use cases don't include kafka, some may only use hdfs sink, so
kafka channel is not an option for general purpose.
2. I tried increase batch size (from 500 to 200,000) and use buffered output
stream in file channel at the first place, however, it helped a little but not
good enough still due to system calls like seek/read/write, which I analyzed by
visualvm. For 1 Mb/s file transfer using file channel, the cpu cost is still
more than 10% overall (before increasing batch size, it's about 13%), while
using memory channel cost only about 3% at the same transfer rate.
3. IMO, file transfer is a very common use case, however, none of the channels
is suitable enough to achieve both high performance and low cost. And
reliability is often of critical importance in production. So file channel seem
to be the only option. But we actually don't really need to store the events
again in files since they come from local files originally. So maybe a separate
channel specifically for file transfer is a better choice?
Please correct me if I got something wrong. Thank you.
> 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)
