[
https://issues.apache.org/jira/browse/HADOOP-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583126#action_12583126
]
Pete Wyckoff commented on HADOOP-3110:
--------------------------------------
I meant by my last comment that if 11 microseconds per logged call + 1
microsecond per non logged call (e.g. log.debug) is small enough slice of the
time that the NameNode typically spends in a critical section then this isn't a
problem.
Of course, I think it is worthwhile to open a JIRA around the general issue
that critical sections are not treated as such in many places. Javas
syncronized methods are a bad way to write critical sections. And maybe going
forward we should think about taking more care. It's not just the logging - if
you want, I'm sure I can find extraneous processing in critical sections that
could be done outside. Yes, may not be the lowest hanging fruit, but it's
something that going forward need not happen.
Lot's of low hanging fruit, but if we could at least do more concurrently, some
of that could be masked.
> NameNode does logging in critical sections just about everywhere
> ----------------------------------------------------------------
>
> Key: HADOOP-3110
> URL: https://issues.apache.org/jira/browse/HADOOP-3110
> Project: Hadoop Core
> Issue Type: Improvement
> Components: dfs
> Affects Versions: 0.14.0, 0.14.1, 0.14.2, 0.14.3, 0.14.4, 0.15.0, 0.15.1,
> 0.15.2, 0.15.3, 0.16.0, 0.16.1
> Environment: All
> Reporter: Pete Wyckoff
>
> e.g., FSNameSystem.addStoredBlock (but almost every method has logging in its
> critical sections)
> This method is synchronized and it's spitting something out to Log.info every
> block stored. Normally not a big deal, but since this is in the name node and
> these are critical sections...
> We shouldn't even do any logging at all in critical sections, so even the
> info and warn are bad. But, in many places in the code, it would be hard to
> tease these out (although eventually they really should be), but the system
> could start using something like an AsyncAppender and see how it improves
> performance.
> Even though the log may have a buffer, the writing and doing the formatting
> and stuff cause a drag on performance with 100s/1000s of machines trying to
> talk to the name node.
> At a minimum, the most often triggered Log.info could be changed to
> Log.debug.
> for reference:
> http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/AsyncAppender.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
