I agree Bryan. I am trying both routes in going to provide some more detailed
monitor at the customer site as well as working on trying to simulate the same
access pattern and hopefully get something reproducible.
So more insight. This table would have had a high insert rate and probably
Hi Brett,
Cache cleaning in general is a very I/O intensive activity, so I agree that
it is odd that your system appeared to be CPU busy during that time.
It's interesting that whatever it was, persisted for such a long time.
In the past, I have developed small operator scripts which collect
Thanks Bryan. I am looking at all things :) The fact that it is not
reproducible with a copy of the database is a hinderance but also can indicate
something external.
The interesting thing is that the same query with the same parameters was run
40 times over about an 8 hour period with
Hi Brett?
What's the underlying storage system like? In particular, is it an SSD
storage system? Is there any chance that you happened to hit a spot
in time where there was some non-Derby event which was causing the
storage system to misbehave?
I understand that certain SSD implementations, and
Thanks Katherine, I will look into that.
It is interesting that this one query had the issue repeatedly over about a 12
hour period whereas others querying performing the same query with different
time periods during the same time did not experience any issue. One would
think if the
Hi Brett,
I just happened to see your post on my phone and what came to mind was I wonder
how the automatic statistics update is implemented and if that might somehow be
at play here. I may be totally off base but remember at one point this was
implemented and there was discussion of how and
Background:
* A large database approximately 750G
* derby.storage.pageCacheSize=64000
* Inserts going into the database about 125/second
* Other database updates and deletes are being performed at a lower
rate.
A query is run by the customer that does not
