Investigating Kallithea performance issues

[Mads Kiilerich]

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