On Thu, Aug 11, 2022 at 09:51:06AM +0200, Aurelien Bompard wrote:
> Hey folks!
>
> There's been a report of queries long enough to cause a timeout in
> datagrepper:
>
https://github.com/fedora-infra/datagrepper/issues/467
> I don't think those queries should take so much time, and I'd like to debug
> this performance issue, possibly try a couple new indexes on the tables,
> etc. However, I can't reproduce the issue on staging, probably because the
> datanommer database there is much smaller.
> So I was wondering what is the best course of action. I see the following
> options:
>
> 1. Sync the prod DB to staging. This looks like an obvious first choice,
> but the messages in the staging DB actually come from the staging
> environment and are used by other contributors to check that their service
> is behaving properly on staging. Also, the topic prefix of the messages is
> different on staging and on prod, so syncing the DB with prod messages and
> then adding staging ones may cause a mess.
I think it might work, but not sure we have anyplace off hand with
enough disk space. We might. I can look more if this is the way we want
to go.
> 2. Having a second datanommer DB in prod, and syncing them. The problem
> here is of course the disk space required. I don't know if that's even
> possible with the hardware we have.
It might be possible, but it's not a good way to go I don't think.
> 3. Something else?
Perhaps a aws instance? Just restore the db snapshot from prod and then
spin up a small datagrepper instance to talk to it?
In the past we've imported the prod DB instance into an aws instance when we
needed to play around with it (that's also how ARC investigated the db changes
when it looked at datanommer/datagrepper).
Pierre