Am 23.02.2012 21:57, schrieb Greg Smith:
On 02/22/2012 05:31 PM, james wrote:
Has anyone considered managing a system like the DragonFLY swapcache for
a DBMS like PostgreSQL?
ie where the admin can assign drives with good random read behaviour
(but perhaps also-ran random write) such as SSDs to provide a cache for
blocks that were dirtied, with async write that hopefully writes them
out before they are forcibly discarded.
We know that battery-backed write caches are extremely effective for
PostgreSQL writes. I see most of these tiered storage ideas as acting
like a big one of those, which seems to hold in things like SAN storage
that have adopted this sort of technique already. A SSD is quite large
relative to a typical BBWC.
[...]
-Ultimately all this data needs to make it out to real disk. The funny
thing about caches is that no matter how big they are, you can easily
fill them up if doing something faster than the underlying storage can
handle.
[...]
I don't think the idea of a swapcache is without merit; there's surely
some applications that will benefit from it. It's got a lot of potential
as a way to absorb short-term bursts of write activity. And there are
some applications that could benefit from having a second tier of read
cache, not as fast as RAM but larger and faster than real disk seeks. In
all of those potential win cases, though, I don't see why the OS
couldn't just manage the whole thing for us.
First off, thank's very much for mentioning DragonFly's swapcache on
this mailing list, which takes the burden off me/us to self-advertise
this feature :)
But swapcache is clearly not meant or designed to speed up any write
activity by caching writes and delaying the write to the "target
storage" to a later point in time. Swapcache does not affect writes in
any way, actually.
Swapcache does its writing when a clean VM page hits the inactive VM
page queue. VM pages related to filesystem writes are dirty, the write
occurs normally, then they become clean. But they still have to cycle
into the VM page inactive queue before swapcache will touch them (write
them out to swap).
So, basically it is designed to speed up Metadata reads, and if
configured to do so, data reads.
So, it can take some read load burden of the disk subsystem and free the
disk subsystem for more write activity, but that would be just a side
effect, not a design goal.
And, yes.. it does effect pgsql performance on read loads seriously.
See BSD Mag 5/2011
http://bsdmag.org/magazine/1691-embedded-bsd-freebsd-alix
and
http://www.shiningsilence.com/dbsdlog/2011/04/12/7586.html
Jan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
