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
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) |