hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liyin Tang (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-3693) isMajorCompaction() check triggers lots of listStatus DFS RPC calls from HBase
Date Fri, 25 Mar 2011 00:24:05 GMT

     [ https://issues.apache.org/jira/browse/HBASE-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Liyin Tang updated HBASE-3693:

    Attachment: Hbase-3693[r1085306].patch

Cache the modification time in the StoreFile. So no need to keep checking modification time.

> isMajorCompaction() check triggers lots of listStatus DFS RPC calls from HBase
> ------------------------------------------------------------------------------
>                 Key: HBASE-3693
>                 URL: https://issues.apache.org/jira/browse/HBASE-3693
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Kannan Muthukkaruppan
>            Assignee: Liyin Tang
>         Attachments: Hbase-3693[r1085306].patch
> We noticed that there are lots of listStatus calls on the ColumnFamily directories within
each region, coming from this codepath:
> {code}
> compactionSelection()
>  --> isMajorCompaction 
>     --> getLowestTimestamp()
>        -->  FileStatus[] stats = fs.listStatus(p);
> {code}
> So on every compactionSelection() we're taking this hit. While not immediately an issue,
just from log inspection, this accounts for quite a large number of RPCs to namenode at the
moment and seems like an unnecessary load to be sending to the namenode.
> Seems like it would be easy to cache the timestamp for each opened/created StoreFile,
in memory, in the region server, and avoid going to DFS each time for this information.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message