On 03/29/2017 07:48 AM, Jan Heylen wrote:
On Wed, Mar 29, 2017 at 3:25 AM, Mads Kiilerich <[email protected]> wrote:
On 03/23/2017 06:26 AM, Jan Heylen wrote:
What I do see as queries running long on the database are these, (But I
haven't correlated these directly with the above peeks yet (but it could
well be).)
47362 kallithea kallithea 127.0.0.1 0.0 0.0
0.00B 0.00B 00:47.10 N N SELECT cache_invalidation.cache_id AS
cache_invalidation_cache_id, cache_invalidation.cache_key AS
cache_invalidation_cache_key, cache_invalidation.cache_args AS
cache_invalidation_cache_args, cache_invalidation.cache_active AS
cache_invalidation_cache_active FROM cache_invalidation WHERE
cache_invalidation.cache_key = 'devws048-32241review/ms/sw-review'
As you see, that query runs for 47 seconds at the moment I catch it.
How fast is it when you rerun the query?
I doubt any other queries or updates could slow it down ... unless
cache_invalidation has a lot of entries.
And what fills it?
Anything that access a repository ... and might use a cached version.
I'm asking to understand which table we would need to 'clean up'. If any.
It is just cache_invalidation ... if that is the problem. How many
entries does it have?
/Mads
_______________________________________________
kallithea-general mailing list
[email protected]
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
