It would also be helpful to see raw fs performance for the same 11 nodes. I'm worried that the read pattern is worse than it should be when not cached causing additional issues. If we know that solo readers 764 or whatever it was is 90% of physical performance that is very than if it is 60% of physical performance.
On Jul 25, 2016 10:59 AM, "Parth Chandra (JIRA)" <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/DRILL-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392388#comment-15392388 > ] > > Parth Chandra commented on DRILL-4800: > -------------------------------------- > > Good point. I'll include that in the benchmarking phase after making the > first set of changes. > > > Improve parquet reader performance > > ---------------------------------- > > > > Key: DRILL-4800 > > URL: https://issues.apache.org/jira/browse/DRILL-4800 > > Project: Apache Drill > > Issue Type: Improvement > > Reporter: Parth Chandra > > > > Reported by a user in the field - > > We're generally getting read speeds of about 100-150 MB/s/node on > PARQUET scan operator. This seems a little low given the number of drives > on the node - 24. We're looking for options we can improve the performance > of this operator as most of our queries are I/O bound. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) >
