What version of HBase are you using? sorting and grouping based on the regions the rows is going to help for sure. I don't think you should focus too much in the locality side of the problem unless your HDFS input set is too large (100s or 1000s of MBs per task), otherwise it might be faster to load in-memory the input dataset and do the batched calls. As discussed in this mailing list recently there are too many factors that might be involved in the performance: number of threads or tasks, size of the row, RS resources, configurations, etc. so any additional info would be very helpful.
cheers, esteban. Cloudera, Inc.
On Thu, Aug 14, 2014 at 10:32 AM, Thomas Kwan <[EMAIL PROTECTED]> wrote:
If not set in hbase-site.xml both tcpnodelay and tcpkeepalive are set to true (thats the default behavior since 0.95/0.96)
Have you noticed if the call processing times or the call queue is too high? How does IO look like when you do try to this random gets? are those gets going 100% of the time to disk or do you see in the metrics a good utilization of the block cache? (e.g. the hit ratio is high) if you think region servers are looking good, maybe double check if any of the nodes in the cluster has dropped the nic speed rate or make sure your client is not the bottleneck by itself. Sometimes users change the blocksize in the schema for a specific CF and that also helps.
On Thu, Aug 14, 2014 at 12:21 PM, Ted Yu <[EMAIL PROTECTED]> wrote: