public inbox for [email protected]  

help / color / mirror / Atom feed

Re: Poor performance after restoring database from snapshot on AWS RDS
2+ messages / 2 participants
[nested] [flat]

* Re: Poor performance after restoring database from snapshot on AWS RDS
@ 2024-06-05 12:09  Jeremy Smith <[email protected]>
  0 siblings, 1 reply; 2+ messages in thread

From: Jeremy Smith @ 2024-06-05 12:09 UTC (permalink / raw)
  To: Sam Kidman <[email protected]>; +Cc: [email protected]

On Wed, Jun 5, 2024 at 4:23 AM Sam Kidman <[email protected]> wrote:

> We get very poor performance in the staging environment after this
> restore takes place - after some usage it seems to get better perhaps
> because of caching.
>

This is due to the way that RDS restores snapshots.

From the docs (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RestoreFromSnapshot.html):

You can use the restored DB instance as soon as its status is
available. The DB instance continues to load data in the background.
This is known as lazy loading.

If you access data that hasn't been loaded yet, the DB instance
immediately downloads the requested data from Amazon S3, and then
continues loading the rest of the data in the background.



  -Jeremy






^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: Poor performance after restoring database from snapshot on AWS RDS
@ 2024-06-06 04:40  Sam Kidman <[email protected]>
  parent: Jeremy Smith <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Sam Kidman @ 2024-06-06 04:40 UTC (permalink / raw)
  To: Jeremy Smith <[email protected]>; +Cc: [email protected]

> This is due to the way that RDS restores snapshots.

Thanks, I never would have guessed. Would vacuum analyze be sufficient
to defeat the lazy loading or would we need to do something more
specific to our application? (for example. select(*) on some commonly
used tables)

I think vacuum full would certainly defeat the lazy loading since it
would copy all of the table data, but that may take a very long time
to run. I think vacuum analyze only scans a subset of rows but I might
be wrong about that.

Best, Sam

On Wed, Jun 5, 2024 at 10:09 PM Jeremy Smith <[email protected]> wrote:
>
> On Wed, Jun 5, 2024 at 4:23 AM Sam Kidman <[email protected]> wrote:
>
> > We get very poor performance in the staging environment after this
> > restore takes place - after some usage it seems to get better perhaps
> > because of caching.
> >
>
> This is due to the way that RDS restores snapshots.
>
> From the docs (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RestoreFromSnapshot.html):
>
> You can use the restored DB instance as soon as its status is
> available. The DB instance continues to load data in the background.
> This is known as lazy loading.
>
> If you access data that hasn't been loaded yet, the DB instance
> immediately downloads the requested data from Amazon S3, and then
> continues loading the rest of the data in the background.
>
>
>
>   -Jeremy






^ permalink  raw  reply  [nested|flat] 2+ messages in thread

end of thread, other threads:[~2024-06-06 04:40 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-06-05 12:09 Re: Poor performance after restoring database from snapshot on AWS RDS Jeremy Smith <[email protected]>
2024-06-06 04:40 ` Sam Kidman <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox