Re: SSDs with Postgresql?

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: Robert Treat <rob(at)xzilla(dot)net>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, Florian Weimer <fweimer(at)bfk(dot)de>, pgsql-general(at)postgresql(dot)org
Subject: Re: SSDs with Postgresql?
Date: 2011-04-28 20:25:46
Message-ID: 4DB9CD4A.7050903@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2011-04-28 21:34, Robert Treat wrote:
>
> We have an open task to work on this same problem. What we had cobbled
> together so far was some sql which converted the xlog value into an
> integer (it's pretty ugly, but I could send it over if you think it
> would help), which we could then stick in a monitoring system and
> graph. To get an idea of traffic, I just multiplied this by 16MB. End
> result ended up looking like this:
> https://circonus.com/shared/graphs/9497d906-4c5b-e6d2-bf91-d8869e7c1668/OnxdZG
>
> Couldn't decide on exactly where to go from there. That's graphing
> MB/sec, which does map easily in my mind, since xlogs streams are in
> 16mb bursts. It would make more sense for wal streaming though (but in
> that case we'd probably want to measure it more precisely).
If the goal is predicting the EOL of the SSD, graphing IO to the
disk/partition, or perhaps graphing the smart values containing write
cycles/GBs written/lifetime curve could work. Both monitoring disk IO
(and iops) as well as smart values can be done with Symon: example
picture with smart attributes graphed at http://i.imgur.com/T4NAq.png -
the actual smart values for a SSD firmware would have to be configured
though, since they vary a lot.

(*) http://www.xs4all.nl/~wpd/symon/

--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Merlin Moncure 2011-04-28 20:39:19 Re: pervasiveness of surrogate (also called synthetic) keys
Previous Message John DeSoi 2011-04-28 20:08:26 Re: "OLD." || myColumnNameVar (How to generically access columns in a trigger's OLD or NEW records)