[DOC] Dump/Restore of the Buffer Pool makes little sense with flash

Bug #1097260 reported by Aurimas Mikalauskas
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Status tracked in 5.7
5.1
Won't Fix
Undecided
Unassigned
5.5
Triaged
Low
Unassigned
5.6
Opinion
Undecided
Unassigned
5.7
Opinion
Undecided
Unassigned

Bug Description

[In:Percona Server Documentation]

Correct me if I'm wrong, but using buffer pool restore is not all that useful on flash storage since random/sequential makes little difference here. The only application with flash that I think still makes a good case is when you want the restore to be blocking i.e. restore buffer pool to the state it was, before you even allow any queries to hit MySQL.

Tags: doc
Revision history for this message
Alexey Kopytov (akopytov) wrote :

I don't understand the question. What's wrong with a non-blocking buffer pool restore on flash? Yes, LRU dump files are sorted for sequential reads on restore, which doesn't make much sense for flash storage, but it doesn't hurt either?

Changed in percona-server:
status: New → Incomplete
Revision history for this message
Stewart Smith (stewart) wrote : Re: [Bug 1097260] Re: [DOC] Dump/Restore of the Buffer Pool makes little sense with flash

Alexey Kopytov <email address hidden> writes:
> I don't understand the question. What's wrong with a non-blocking buffer
> pool restore on flash? Yes, LRU dump files are sorted for sequential
> reads on restore, which doesn't make much sense for flash storage, but
> it doesn't hurt either?

It probably does make some sense though, as random IO is still slower
than sequential, it's just not as many orders of magnitude slower (and
everything is much faster anyway).

--
Stewart Smith

Revision history for this message
Vadim Tkachenko (vadim-tk) wrote :

Actually loading LRU dump into memory still helps.

Say, on HDD buffer gets warm in 60 mins,
on SSD in 6 mins,
but we can load LRU in 30 sec.

So the the server is fully warm ~5 min earlier, which is still good to have.

On Tue, Jan 8, 2013 at 2:54 PM, Stewart Smith <email address hidden>wrote:

> Alexey Kopytov <email address hidden> writes:
> > I don't understand the question. What's wrong with a non-blocking buffer
> > pool restore on flash? Yes, LRU dump files are sorted for sequential
> > reads on restore, which doesn't make much sense for flash storage, but
> > it doesn't hurt either?
>
> It probably does make some sense though, as random IO is still slower
> than sequential, it's just not as many orders of magnitude slower (and
> everything is much faster anyway).
>
>
> --
> Stewart Smith
>
> --
> You received this bug notification because you are a member of Percona
> core, which is subscribed to Percona Server.
> https://bugs.launchpad.net/bugs/1097260
>
> Title:
> [DOC] Dump/Restore of the Buffer Pool makes little sense with flash
>
> Status in Percona Server with XtraDB:
> Incomplete
>
> Bug description:
> [In:Percona Server Documentation]
>
> Correct me if I'm wrong, but using buffer pool restore is not all that
> useful on flash storage since random/sequential makes little
> difference here. The only application with flash that I think still
> makes a good case is when you want the restore to be blocking i.e.
> restore buffer pool to the state it was, before you even allow any
> queries to hit MySQL.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/percona-server/+bug/1097260/+subscriptions
>

--
Vadim Tkachenko, CTO, Percona LLC
Phone +1-925-400-7377, Skype: vadimtk153
Schedule meeting: http://meetme.so/VadimTkachenko

Looking for Replication with Data Consistency?
Try Percona XtraDB Cluster!

Revision history for this message
Stewart Smith (stewart) wrote :

Vadim Tkachenko <email address hidden> writes:
> Actually loading LRU dump into memory still helps.
>
> Say, on HDD buffer gets warm in 60 mins,
> on SSD in 6 mins,
> but we can load LRU in 30 sec.
>
> So the the server is fully warm ~5 min earlier, which is still good to
> have.

more to the point, we don't execute queries that are going to take an
unusually long amount of time to run.

--
Stewart Smith

Revision history for this message
Aurimas Mikalauskas (aurimas-mikalauskas) wrote :

Tanks for feedback everyone, I'm glad we discussed this here. I fully agree that warm up in general is a good idea even with flash, though I didn't realize that there's any difference between random and sequential IO on flash. Avoiding unusually long time to run queries sounds like a good case to me, so I guess we can scratch that.

Revision history for this message
Stewart Smith (stewart) wrote :

Aurimas Mikalauskas <email address hidden> writes:
> Tanks for feedback everyone, I'm glad we discussed this here. I fully
> agree that warm up in general is a good idea even with flash, though I
> didn't realize that there's any difference between random and sequential
> IO on flash. Avoiding unusually long time to run queries sounds like a
> good case to me, so I guess we can scratch that.

I'll turn this into a documentation request, and it'd be great if
somebody did some benchmarks to go with it (and blog post :)
--
Stewart Smith

Revision history for this message
Stewart Smith (stewart) wrote :

Basically, we should document on why it does help even with flash.

Changed in percona-server:
status: Incomplete → Triaged
importance: Undecided → Low
Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-2871

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.