Run VACUUM ANALYZE on the resultsdb database for staging and later, prod.
VACUUM ANALYZE
This could solve some performance issues and request timeouts.
I get good performance on my local development instance with "all" the prod data from the public db-dump (from 2018/06/05). As soon as I do request to staging instance, e.g: https://taskotron.stg.fedoraproject.org/resultsdb_api/api/v2.0/results?item=FEDORA-2018-a13691074b&limit=1000 (locally it takes few ~300 milliseconds)
When do you need this? (YYYY/MM/DD)
When is this no longer needed or useful? (YYYY/MM/DD)
If we cannot complete your request, what is the impact?
Greenwave times out when doing some requests to resultsdb (which affects Bodhi).
This was suggested by @ralph. Would be great if it helps the performance.
just FYI: The main issue with staging ResultsDB is the machine it runs on. The main reason staging/dev is usually slow are not really dead tuples, but IO. The various datasets get in and out of memory, and it takes quite a lot of time to load the data from the rotary drives.
This can easily be observed by checking IO on the machine whilst requests are being made on development and staging instance in close succession.
Not saying the vacuum could not help a bit, but this really is 99% IO bound, so the comparison with local dev instance does not mean much.
14:45:15 up 62 days, 13:14, 1 user, load average: 54.84, 51.99, 58.17
The box is overloaded. I don't think I could get a VACUUM without some downtime of other sources.
Metadata Update from @smooge: - Issue assigned to smooge
FYI, we are going to move this vm tomorrow night to a bigger/faster virthost... and also do the vacuum.
Metadata Update from @kevin: - Issue priority set to: Waiting on External (was: Needs Review)
The vm was moved, cpu and memory added, and the vacuum done.
Let us know if there's anything further we can do.
:arrows_counterclockwise:
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Hurray! It's really snappy now, thanks!
\ó/