trafodion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Birdsall <dave.birds...@esgyn.com>
Subject RE: Tables left over from regression test runs
Date Wed, 02 May 2018 00:03:00 GMT
Hi,

Regarding why stopping hbase takes a long time: I was watching the HBase log today while doing
a swstophbase. It was doing individual region closes on each table. It took a long time to
get through all of them. Of course, one can always just kill the HMaster process (I sometimes
do this) but that sometimes results in not being able to bring the instance up again, with
loss of any working data. So that's risky.

Regarding time to drop tables: I'm noticing that many of the tests that don't drop tables
at the end do so at the beginning. If they are run on a clean instance, that's fast (because
it fails fast or it has "drop if exists"). If they are run on an instance where they have
been run before, we pay the cost of dropping the table anyway. Agreed, for Jenkins it's better
because we just throw the instance away after one run. For developers who are keeping test
tables around, it's not so good.

Regarding the convenience of having objects around when there's a need to debug something:
I've been unlucky at this. Almost always, the particular object I need is in a test that cleans
up its objects. So I end up having to recreate it from a stripped down version of the test
script. I suspect this is true more often than not. So I haven't found this particular argument
persuasive.

Regarding speeding up HBase drop: Yes, that would be a great idea.

Dave

-----Original Message-----
From: Anoop Sharma <anoop.sharma@esgyn.com> 
Sent: Tuesday, May 1, 2018 4:51 PM
To: dev@trafodion.apache.org
Subject: RE: Tables left over from regression test runs

yes, it is true that some tests do not drop all the tables that are created as part of that
test. 
This is not always intentional and at times it is because one missed cleaning them up.

But there are some advantages of not dropping tables at the end of a test run.

- drop hbase tables take a non-trivial amount of time.  dropping all tables will increase
the time it takes to run a test. 
  This will also impact Jenkins as it runs tests after init traf which cleans up everything
- is there a way to make dropping of table or dropping of whole schema faster? Using concurrent
drops? Or drop without disable(disable is where most of the time is spent due to mem flush).
There is an hbase jira on drop issue but no one has volunteered to fix it.
- some tables are permanent (like from QAT) that should not be cleaned up
- many tests drop tables at the beginning of the test or have an 'if not exists' clause. 
- one advantage of not dropping a table at the end is that sometimes an issue could be diagnosed
without having to recreate the table and associated dependent objects.
- if the only objects on a dev instance are regression tests, then doing ilh_trafinit will
be much faster to clean up everything after full regressions.
  But this would also nuke any non-regression traf objects so one need to be careful about
it
- should we also find out why stopping hbase takes a long time. Is there something that can
be done to 'stop abrupt' on dev platform?

anoop

-----Original Message-----
From: Dave Birdsall <dave.birdsall@esgyn.com>
Sent: Tuesday, May 1, 2018 3:57 PM
To: dev@trafodion.apache.org
Subject: Tables left over from regression test runs

Hi,

I've noticed after running full regressions that there are a boatload of tables that don't
get cleaned up.

These tables occupy regions in our instance's region server and I think may cause excessive
memory usage and/or increasingly long times when stopping HBase.

So, I'm thinking about cleaning up some of our regression tests to drop these tables when
they finish.

Does anyone object to this? Or is there some pressing need to keep any of these tables around
after regressions complete?

Thanks,

Dave

Mime
View raw message