Yeah... It looks OK. Maybe 2G of heap is a bit low when dealing with 200.000 column rows.
If you can I'd like to know how busy your regionservers are during these operations. That would be an indication on whether the parallelization is good or not. -- Lars ----- Original Message ----- From: Stack <[email protected]> To: [email protected] Cc: Sent: Wednesday, August 15, 2012 3:13 PM Subject: Re: Slow full-table scans On Mon, Aug 13, 2012 at 6:10 PM, Gurjeet Singh <[email protected]> wrote: > I am beginning to think that this is a configuration issue on my > cluster. Do the following configuration files seem sane ? > > hbase-env.sh https://gist.github.com/3345338 > Nothing wrong w/ this (Remove the -ea, you don't want asserts in production, and the -XX:+CMSIncrementalMode flag if >= 2 cores). > hbase-site.xml https://gist.github.com/3345356 > This is all defaults effectively. I don't see any of the configs. recommended by the performance section of the reference guide and/or those suggested by the GBIF blog. You don't answer LarsH's query about where you see the 4% difference. How many regions in your table? Whats the HBase Master UI look like when this scan is running? St.Ack
