The speed benefits of SSDs as benchmarked would seem incredible. Can anybody
comment on SSD benefits and problems in real life use?
I maintain some 100 databases on 3 servers, with 32 GB of RAM each and an
extremely rich, complex schema. (300+ normalized tables)
I was wondering if anybody her
On 04/13/11 9:19 PM, Benjamin Smith wrote:
The speed benefits of SSDs as benchmarked would seem incredible. Can
anybody comment on SSD benefits and problems in real life use?
I maintain some 100 databases on 3 servers, with 32 GB of RAM each and
an extremely rich, complex schema. (300+ norm
On Thu, April 14, 2011 06:19, Benjamin Smith wrote:
> The speed benefits of SSDs as benchmarked would seem incredible. Can anybody
> comment on SSD benefits and problems in real life use?
>
> I maintain some 100 databases on 3 servers, with 32 GB of RAM each and an
> extremely rich, complex schema
On 14/04/2011 4:35 PM, Henry C. wrote:
There is no going back. Hint: don't use cheap SSDs - cough up and use Intel.
The server-grade SLC stuff with a supercap, I hope, not the scary
consumer-oriented MLC "pray you weren't writing anything during
power-loss" devices?
--
Craig Ringer
Tech-
On 04/14/11 1:35 AM, Henry C. wrote:
Hint: don't use cheap SSDs - cough up and use Intel.
aren't most of the Intel SSD's still MLC, and still have performance and
reliability issues with sustained small block random writes such as are
generated by database servers? the enterprise grade SLC
have a look at
http://postgresql.1045698.n5.nabble.com/Intel-SSDs-that-may-not-suck-td4268261.html
It looks like those are "safe" to use with a db, and aren't that expensive.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://w
On Thu, April 14, 2011 10:51, Craig Ringer wrote:
> On 14/04/2011 4:35 PM, Henry C. wrote:
>
>
>> There is no going back. Hint: don't use cheap SSDs - cough up and use
>> Intel.
>>
>
> The server-grade SLC stuff with a supercap, I hope, not the scary
> consumer-oriented MLC "pray you weren't writ
Le 14/04/2011 10:54, John R Pierce a écrit :
On 04/14/11 1:35 AM, Henry C. wrote:
Hint: don't use cheap SSDs - cough up and use Intel.
aren't most of the Intel SSD's still MLC, and still have performance and
reliability issues with sustained small block random writes such as are
generated by
On Thu, April 14, 2011 11:30, Leonardo Francalanci wrote:
> have a look at
>
> http://postgresql.1045698.n5.nabble.com/Intel-SSDs-that-may-not-suck-td426826
> 1.html
>
>
>
> It looks like those are "safe" to use with a db, and aren't that expensive.
The new SSDs look great. From our experience,
Le 14/04/2011 11:40, Henry C. a écrit :
You have a valid point about using SLC if that's what you need though.
However, MLC works just fine provided you stick them into RAID1. In fact, we
use a bunch of them in RAID0 on top of RAID1.
AFAIK, you won't have TRIM support on RAID-arrayed SSDs.
Tha
On Thu, 14 Apr 2011 11:46:12 +0200, Henry C. wrote:
On Thu, April 14, 2011 11:30, Leonardo Francalanci wrote:
have a look at
http://postgresql.1045698.n5.nabble.com/Intel-SSDs-that-may-not-suck-td426826
1.html
It looks like those are "safe" to use with a db, and aren't that
expensive.
Th
> I believe this perception that SSDs are less "safe" than failure-prone
> mechanical hard drives will eventually change.
By "safe" I mean they won't corrupt data in case of crash of the machine.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subs
On 14/04/2011 5:40 PM, Henry C. wrote:
The server-grade SLC stuff with a supercap, I hope, not the scary
consumer-oriented MLC "pray you weren't writing anything during power-loss"
devices?
That's what a UPS and genset are for. Who writes critical stuff to *any*
drive without power backup?
On Thu, Apr 14, 2011 at 12:19 AM, Benjamin Smith
wrote:
> I was wondering if anybody here could comment on the benefits of SSD in
> similar, high-demand rich schema situations?
>
>
For the last several months, I've been using Texas Memory Systems RamSAN 620
drives on my main DB servers. Having ne
At 06:07 PM 4/14/2011, RadosÅaw Smogura wrote:
One thing you should care about is such called
write endurance - number of writes to one memory
region before it will be destroyed - if your SSD
driver do not have transparent allocation, then
you may destroy it really fast, because write of
ea
After a glowing review at AnandTech (including DB benchmarks!) I decided to
spring for an OCX Vertex 3 Pro 120 for evaluation purposes. It cost about $300
with shipping, etc and at this point, won't be putting any
Considering that I sprang for 96 GB of ECC RAM last spring for around $5000,
eve
On Thu, Apr 14, 2011 at 3:40 AM, Henry C. wrote:
>
> On Thu, April 14, 2011 10:51, Craig Ringer wrote:
>> On 14/04/2011 4:35 PM, Henry C. wrote:
>>
>>
>>> There is no going back. Hint: don't use cheap SSDs - cough up and use
>>> Intel.
>>>
>>
>> The server-grade SLC stuff with a supercap, I hope,
On Thu, Apr 14, 2011 at 12:27:34PM -0600, Scott Marlowe wrote:
> > That's what a UPS and genset are for. Who writes critical stuff to *any*
> > drive without power backup?
>
> Because power supply systems with UPS never fail.
Right, there's obviously a trade-off here. Some of this has to do
wit
Henry C. wrote:
I believe this perception that SSDs are less "safe" than failure-prone
mechanical hard drives will eventually change.
Only because the manufacturers are starting to care about write
durability enough to include the right hardware for it. Many of them
are less safe right no
On Thu, Apr 14, 2011 at 1:14 PM, Greg Smith wrote:
> And the idea that a UPS is sufficient to protect against that even happening
> in
> wildly optimistic.
Note that the real danger in relying on a UPS is that most power
conditioning / UPS setups tend to fail in total, not in parts. The
two t
On Thu, April 14, 2011 18:56, Benjamin Smith wrote:
> After a glowing review at AnandTech (including DB benchmarks!) I decided to
> spring for an OCX Vertex 3 Pro 120 for evaluation purposes. It cost about $300
> with shipping, etc and at this point, won't be putting any
>
> Considering that I sp
On Thu, April 14, 2011 20:54, Andrew Sullivan wrote:
> On Thu, Apr 14, 2011 at 12:27:34PM -0600, Scott Marlowe wrote:
>
>>> That's what a UPS and genset are for. Â Who writes critical stuff to
>>> *any*
>>> drive without power backup?
>>
>> Because power supply systems with UPS never fail.
>>
>
> R
On Sun, Apr 17, 2011 at 5:17 AM, Henry C. wrote:
> When the super-fast SSD-based machine fails, switching to a (slower)
> standard
> hard-drive based machine provides continuity and buys time while we get the
> primary machine back online.
>
The question you should ask yourself is: can my busine
On Sunday, April 17, 2011 01:55:02 AM Henry C. wrote:
> On Thu, April 14, 2011 18:56, Benjamin Smith wrote:
> > After a glowing review at AnandTech (including DB benchmarks!) I decided
> > to spring for an OCX Vertex 3 Pro 120 for evaluation purposes. It cost
> > about $300
> >
> > with shipping,
On 2011-04-19 19:07, Benjamin Smith wrote:
On Sunday, April 17, 2011 01:55:02 AM Henry C. wrote:
>
> Exactly. Be aware of the risks, plan for failure and reap the rewards.
Just curious what your thoughts are with respect to buying SSDs and
mirroring them with software RAID 1. (I use Linux/C
On 20/04/11 04:28, Yeb Havinga wrote:
On 2011-04-19 19:07, Benjamin Smith wrote:
On Sunday, April 17, 2011 01:55:02 AM Henry C. wrote:
>
> Exactly. Be aware of the risks, plan for failure and reap the rewards.
Just curious what your thoughts are with respect to buying SSDs and
mirroring the
On 14/04/11 23:25, Vick Khera wrote:
On Thu, Apr 14, 2011 at 12:19 AM, Benjamin Smith
mailto:li...@benjamindsmith.com>> wrote:
I was wondering if anybody here could comment on the benefits of SSD
in similar, high-demand rich schema situations?
For the last several months, I've been usi
On 04/20/2011 01:50 AM, Toby Corkindale wrote:
Also, the number of erase cycles you can get, over the whole disk, is
quite large on modern disks!
So large that you'll probably go decades before you wear the disk out,
even with continual writes.
Don't buy into the SSD FUD myths..
There is n
* Greg Smith:
> The fact that every row update can temporarily use more than 8K means
> that actual write throughput on the WAL can be shockingly large. The
> smallest customer I work with regularly has a 50GB database, yet they
> write 20GB of WAL every day. You can imagine how much WAL is
> ge
On Thursday, April 21, 2011 8:33:45 am Florian Weimer wrote:
> * Greg Smith:
> > The fact that every row update can temporarily use more than 8K means
> > that actual write throughput on the WAL can be shockingly large. The
> > smallest customer I work with regularly has a 50GB database, yet they
* Adrian Klaver:
>> Interesting. Is there an easy way to monitor WAL traffic in away? It
>> does not have to be finegrained, but it might be helpful to know if
>> we're doing 10 GB, 100 GB or 1 TB of WAL traffic on a particular
>> database, should the question of SSDs ever come up.
>
> They are
On Apr 21, 2011, at 9:44 AM, Florian Weimer wrote:
> But log files are recycled, so looking at the directory alone does not
> seem particularly helpful.
You have to look at the file timestamps. From that you can get an idea of
traffic.
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.eleva
On 04/21/2011 11:33 AM, Florian Weimer wrote:
Is there an easy way to monitor WAL traffic in away? It
does not have to be finegrained, but it might be helpful to know if
we're doing 10 GB, 100 GB or 1 TB of WAL traffic on a particular
database, should the question of SSDs ever come up.
You
Florian Weimer writes:
> * Adrian Klaver:
>>> Interesting. Is there an easy way to monitor WAL traffic in away?
>> They are found in $DATA/pg_xlog so checking the size of that
>> directory regularly would get you the information.
> But log files are recycled, so looking at the directory alone d
On Thu, Apr 21, 2011 at 11:22 AM, Tom Lane wrote:
> Florian Weimer writes:
>> * Adrian Klaver:
Interesting. Is there an easy way to monitor WAL traffic in away?
>
>>> They are found in $DATA/pg_xlog so checking the size of that
>>> directory regularly would get you the information.
>
>> But
- Original Message -
> From: "Greg Smith"
> To: pgsql-general@postgresql.org
> Sent: Friday, 22 April, 2011 12:49:28 AM
> Subject: Re: [GENERAL] SSDs with Postgresql?
> On 04/20/2011 01:50 AM, Toby Corkindale wrote:
> > Also, the number of erase cycles y
On Thu, Apr 21, 2011 at 10:33 AM, Florian Weimer wrote:
> * Greg Smith:
>
> > The fact that every row update can temporarily use more than 8K means
> > that actual write throughput on the WAL can be shockingly large. The
> > smallest customer I work with regularly has a 50GB database, yet they
>
* Michael Nolan:
> If you archive your WAL files, wouldn't that give you a pretty good
> indication of write activity?
WAL archiving may increase WAL traffic considerably, I think. Fresh
table contents (after CREATE TABLE or TRUNCATE) is written to the log
if WAL archiving is active. This would
* Greg Smith:
> To convert the internal numbers returned by that into bytes, you'll
> need to do some math on them. Examples showing how that works and
> code in a few languages:
Thanks for the pointers.
Those examples are slightly incongruent, but I think I've distilled
something that should b
One thing to remember in this discussion about SSD longevity is that the
underlying value of interest is the total number of erase cycles, per
block, on the flash devices. Vendors quote lifetime as a number of
bytes, but this is calculated using an assumed write amplification
factor. That const
On Apr 28, 2011, at 7:21 AM, David Boreham wrote:
> I don't think you can simply say that I am writing so many Gb WAL files,
> therefore according to the vendor's spec
Also, I fully expect the vendors lie about erase cycles as baldly as they lie
about MTBF, so I would divide by a very healthy s
On 4/28/2011 8:20 AM, Scott Ribe wrote:
I don't think you can simply say that I am writing so many Gb WAL files,
therefore according to the vendor's spec
Also, I fully expect the vendors lie about erase cycles as baldly as they lie
about MTBF, so I would divide by a very healthy skepticism fac
On Apr 28, 2011, at 8:48 AM, David Boreham wrote:
> As a former card-carrying semiconductor company employee, I'm not so sure
> about this.
Well, yes, you have a good point that in many, if not all, cases we're dealing
with different companies. That really should have occurred to me, that
manu
On Thu, Apr 21, 2011 at 12:10 PM, Greg Smith wrote:
> On 04/21/2011 11:33 AM, Florian Weimer wrote:
>>
>> Is there an easy way to monitor WAL traffic in away? It
>> does not have to be finegrained, but it might be helpful to know if
>> we're doing 10 GB, 100 GB or 1 TB of WAL traffic on a particul
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 moni
Instead of the usual SSD, you may want to consider the 'ioDrive' products from
"Fusion-io".
http://www.fusionio.com/
This company makes enterprise-class storage on a board populated with flash and
managed by their own supposedly-sophisticated drivers. The board + drivers are
meant to get around
On Thu, 28 Apr 2011 17:27:04 -0500, Basil Bourque
wrote:
So, while I can't specifically recommend their products, I certainly
suggest considering them.
Customer of ours is probably lurking on here. We host their servers in our
datacenter -- we had a UPS go "pop" after an amazing surge an
On 22/04/11 01:33, Florian Weimer wrote:
* Greg Smith:
The fact that every row update can temporarily use more than 8K means
that actual write throughput on the WAL can be shockingly large. The
smallest customer I work with regularly has a 50GB database, yet they
write 20GB of WAL every day.
On 04/26/2011 10:30 AM, Toby Corkindale wrote:
I see Intel is/was claiming their SLC SSDs had a *minimum* lifetime of
2PB in writes for their 64GB disks; for your customer with a 50GB db
and 20GB/day of WAL, that would work out at a minimum lifetime of a
million days, or about 273 years!
The c
On 29/04/11 16:35, Greg Smith wrote:
On 04/26/2011 10:30 AM, Toby Corkindale wrote:
I see Intel is/was claiming their SLC SSDs had a *minimum* lifetime of
2PB in writes for their 64GB disks; for your customer with a 50GB db
and 20GB/day of WAL, that would work out at a minimum lifetime of a
mill
On Fri, Apr 29, 2011 at 1:23 AM, Toby Corkindale
wrote:
> On 29/04/11 16:35, Greg Smith wrote:
>>
>> On 04/26/2011 10:30 AM, Toby Corkindale wrote:
>>>
>>> I see Intel is/was claiming their SLC SSDs had a *minimum* lifetime of
>>> 2PB in writes for their 64GB disks; for your customer with a 50GB d
On Thu, Apr 28, 2011 at 7:00 PM, Mark Felder wrote:
> On Thu, 28 Apr 2011 17:27:04 -0500, Basil Bourque wrote:
>
>> So, while I can't specifically recommend their products, I certainly
>> suggest considering them.
>
> Customer of ours is probably lurking on here. We host their servers in our
> da
On 04/29/2011 06:42 AM, Scott Marlowe wrote:
I think you misunderstood. He's not storing 480GB on the drives,
that's how much WAL is moving across it. It could easily be a single
80GB SSD drive or something like that.
Right; that's why you don't necessarily get saved by the fact that
lar
53 matches
Mail list logo
