On Mon, Aug 15, 2022 at 10:49:50AM -0700, Kevin Fenzi wrote: > 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
