Investigating Kallithea performance issues

[Mads Kiilerich]

On 03/29/2017 07:48 AM, Jan Heylen wrote:
> On Wed, Mar 29, 2017 at 3:25 AM, Mads Kiilerich <mads at kiilerich.com> 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