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.
Perhaps try rerunning it regularly and see if the execution time varies?
As far as I understand it now, these queries are the result of updated
repositories from 'outside' kallithea and the accompanied repo-'cache
invalidation' trigger.
If this is really hitting us that would mean:
* requests to kallithea webgui have to wait until these queries are over?
* we need to find a way to have these repos updated without the need
of the cache invalidation, so instead of doing an 'outside pull',
would a 'push to kallithea' prevent the need of invalidating the
cache?
No, pushes are also invalidating the cache. The problem is that it
should take that much time. But also: How do you invalidate cache after
external pushes?
/Mads
_______________________________________________
kallithea-general mailing list
[email protected]
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
