thanks for the information. Up-to-date hive. Cluster on the smallish side.
And, well, sure looks like a memory issue. :)  rather than an inherent hive
limitation that is.

So.  I can only speak as a user (ie. not a hive developer) but what i'd be
interested in knowing next is is this via running hive in local mode,
correct? (eg. not through hiveserver1/2).  And it looks like it boinks on
array processing which i assume to be internal code arrays and not hive
data arrays - your 15K columns are all scalar/simple types, correct?  Its
clearly fetching results and looks be trying to store them in a java array
- and not just one row but a *set* of rows (ArrayList)

two things to try.

1. boost the heap-size. try 8192. And I don't know if HADOOP_HEAPSIZE is
the controller of that. I woulda hoped it was called something like
"HIVE_HEAPSIZE". :)  Anyway, can't hurt to try.

2. trim down the number of columns and see where the breaking point is.  is
it 10K? is it 5K?   The idea is to confirm its _the number of columns_ that
is causing the memory to blow and not some other artifact unbeknownst to us.

3. Google around the Hive namespace for something that might limit or
otherwise control the number of rows stored at once in Hive's internal
buffer. I snoop around too.
That's all i got for now and maybe we'll get lucky and someone on this list
will know something or another about this. :)


On Thu, Jan 30, 2014 at 2:32 AM, David Gayou <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB