SSD Experience

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

SSD Experience

rcariens
(Cross-posted from solr-users)

Ahoy ahoy!

Does anyone have any experiences or stories they can share about how SSDs
impacted search performance for better or worse?

I found a Lucene SSD performance benchmark
doc<http://wiki.apache.org/lucene-java/SSD_performance?action=AttachFile&do=view&target=combined-disk-ssd.pdf>but
the wiki engine is refusing to let me view the attachment (I get "You
are not allowed to do AttachFile on this page.").

Thanks in advance!
Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience

Karl Wettin

22 aug 2011 kl. 18.49 skrev Rich Cariens:

> I found a Lucene SSD performance benchmark
> doc<http://wiki.apache.org/lucene-java/SSD_performance?action=AttachFile&do=view&target=combined-disk-ssd.pdf>but
> the wiki engine is refusing to let me view the attachment (I get "You
> are not allowed to do AttachFile on this page.").

http://web.archive.org/web/20080920145828/http://wiki.apache.org/lucene-java-data/attachments/SSD_performance/attachments/combined-disk-ssd.pdf



        karl




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience

Toke Eskildsen
In reply to this post by rcariens
On Mon, 2011-08-22 at 18:49 +0200, Rich Cariens wrote:
> Does anyone have any experiences or stories they can share about how SSDs
> impacted search performance for better or worse?

Our measurements are getting old, but since spinning disks hasn't
improved and SSDs has improved substantially since then, the conclusion
should be about the same: Buy SSDs. They offer performance rivaling RAM
with the obvious advantages of being persistent in case of power loss.

Details at http://wiki.statsbiblioteket.dk/summa/Hardware


Just be sure that IO really is your bottleneck before you improve on
that part.





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience

Dawid Weiss-2
This one is humorous (watch for foul language though). It does get to the
point, however, and Bergman is a clever guy:
http://www.livestream.com/oreillyconfs/video?clipId=pla_3beec3a2-54f5-4a19-8aaf-35a839b6ecaa

Dawid

On Tue, Aug 23, 2011 at 10:00 AM, Toke Eskildsen <[hidden email]>wrote:

> On Mon, 2011-08-22 at 18:49 +0200, Rich Cariens wrote:
> > Does anyone have any experiences or stories they can share about how SSDs
> > impacted search performance for better or worse?
>
> Our measurements are getting old, but since spinning disks hasn't
> improved and SSDs has improved substantially since then, the conclusion
> should be about the same: Buy SSDs. They offer performance rivaling RAM
> with the obvious advantages of being persistent in case of power loss.
>
> Details at http://wiki.statsbiblioteket.dk/summa/Hardware
>
>
> Just be sure that IO really is your bottleneck before you improve on
> that part.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience

Toke Eskildsen
On Tue, 2011-08-23 at 10:23 +0200, Dawid Weiss wrote:
> This one is humorous (watch for foul language though). It does get to
> the point, however, and Bergman is a clever guy:
>
http://www.livestream.com/oreillyconfs/video?clipId=pla_3beec3a2-54f5-4a19-8aaf-35a839b6ecaa

We installed SSDs in all developer machines in 2009 (Intel X25) and
haven't looked back. They are now default for new laptops, most desktops
and all search server machines (okay, except for a rusty old test
machine, but that is mostly used for index building).

I think one of the important points that Bergman states is that SSDs are
cheaper than harddrives, if we're looking at performance instead of disk
space. The gut reaction is "but they are so expensive" but when we're
comparing to the alternative of RAIDing and bulking up on RAM, this
often turns out to be wrong. For developer machines, the advantage of a
more responsive machine is obvious.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience

Dawid Weiss-2
>
>
> We installed SSDs in all developer machines in 2009 (Intel X25) and
> haven't looked back.
>
>
I can confirm this from my own experience. Once you have a (fast) SSD on
your development machine you are not likely to go back to a spinning
drive...

Dawid
Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience

Paul Libbrecht-4
In reply to this post by Toke Eskildsen
I think we're getting out of topic about Lucene usage for SSDs but I fully acknowledge that below mail: SSDs are faster than normal disk for development.
Actually, one of the things that got real faster with the SSD is IntelliJ indexing and reboot; I could not tell if it is using Lucene sadly.

It's been so much a difference that I prefer my old laptop than my newer one (2 y differences, both macbooks).

paul



Le 23 août 2011 à 11:04, Toke Eskildsen a écrit :

> On Tue, 2011-08-23 at 10:23 +0200, Dawid Weiss wrote:
>> This one is humorous (watch for foul language though). It does get to
>> the point, however, and Bergman is a clever guy:
>>
> http://www.livestream.com/oreillyconfs/video?clipId=pla_3beec3a2-54f5-4a19-8aaf-35a839b6ecaa
>
> We installed SSDs in all developer machines in 2009 (Intel X25) and
> haven't looked back. They are now default for new laptops, most desktops
> and all search server machines (okay, except for a rusty old test
> machine, but that is mostly used for index building).
>
> I think one of the important points that Bergman states is that SSDs are
> cheaper than harddrives, if we're looking at performance instead of disk
> space. The gut reaction is "but they are so expensive" but when we're
> comparing to the alternative of RAIDing and bulking up on RAM, this
> often turns out to be wrong. For developer machines, the advantage of a
> more responsive machine is obvious.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience (on developer machine)

Federico Fissore
we are probably running out of topic here, but for the record, there is
also someone lamenting about ssd

http://www.codinghorror.com/blog/2011/05/the-hot-crazy-solid-state-drive-scale.html

the underlying point is correct: SSD offer much less re-writes of the
same "sector" than disk based

so, as far as developer machines are involved, you should go for OSes
that use the disk efficiently and basically avoid windows (which I think
is the OS that Jeff Atwood uses): one of my friend W7 keeps on
reading/writing even when there is no application running, ageing the
disk too fast imho

fede

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience (on developer machine)

Toke Eskildsen
On Tue, 2011-08-23 at 11:52 +0200, Federico Fissore wrote:
> we are probably running out of topic here, but for the record, there is
> also someone lamenting about ssd

I find all of this highly on-topic. SSD reliability is an important
issue. We use customer-grade SSDs (Intel 510 were the latest ones
bought) in our servers as we see no point in enterprise-grade
reliability when we are mirroring machines.

> http://www.codinghorror.com/blog/2011/05/the-hot-crazy-solid-state-drive-scale.html
>
> the underlying point is correct: SSD offer much less re-writes of the
> same "sector" than disk based

Please, can't we kill this misconception once and for all?

Yes, the first generation of SSDs had bad wear-leveling and there has
been some exceptionally bad eggs along the way, but we're long past that
point now. All brand name SSDs use wear leveling and unless you set up
pathological destruction cases (fill the drive to 99% and keep
re-writing the last 1% ) the drive will be obsolete before it wears out.

What kills modern SSDs are either non-rewrite-related errors or server
use that requires a full to-hardware flushes after all small changes.
Even the author of the article you link to does not blame the failures
on re-writes.

Regarding that, it would be nice with an analysis of SSD failure rates
that wasn't anecdotally based. I'm certainly interested.

> so, as far as developer machines are involved, you should go for OSes
> that use the disk efficiently [...]

Efficiently as speed, yes. Efficiently as minimizing writes, no. On the
contrary, disk swapping is much faster on SSDs along with temporary
files and all the other secondary writes that are done throughout the
day. Hit them hard. They're designed for it.

An backup? Why yes, we all do that anyway. Right?


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience (on developer machine)

Marvin Humphrey
On Tue, Aug 23, 2011 at 01:37:06PM +0200, Toke Eskildsen wrote:
> Yes, the first generation of SSDs had bad wear-leveling and there has
> been some exceptionally bad eggs along the way, but we're long past that
> point now. All brand name SSDs use wear leveling and unless you set up
> pathological destruction cases (fill the drive to 99% and keep
> re-writing the last 1% ) the drive will be obsolete before it wears out.
>
> What kills modern SSDs are either non-rewrite-related errors or server
> use that requires a full to-hardware flushes after all small changes.

I'm a little confused.  What do you mean by a "full to-hardware flush" and how
is that different from the sync()/fsync() calls that Lucene makes by default
on each IndexWriter commit()?  

Marvin Humphrey


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience (on developer machine)

Toke Eskildsen
On Tue, 2011-08-23 at 14:07 +0200, Marvin Humphrey wrote:
> I'm a little confused.  What do you mean by a "full to-hardware flush"
> and how is that different from the sync()/fsync() calls that Lucene
> makes by default on each IndexWriter commit()?  

A standard flush from the operating system flushes all OS write caches
to storage. That does not guarantee that the storage hardware has
flushed to persistent storage - it can still be in RAM on the device.
If the operating system flushes 1000 times/second, the SSD might still
only perform a single write to a solid state cell.

Now, running an important database with a lot of small updates, the "not
sure if it is really written"-approach might not be what the admin
wants. Disabling the on-SSD write cache ensures that all writes are
flushed. Since SSDs writes in blocks and not individual bits, this means
that a block will be written for each write from the OS. Couple that
with thousands of writes/second and the expected life of the SSD drops
drastically.

(one obvious solution to me is to buy a SSD with a battery that
guarantees that the SSD-cache can be flushed in case of power failure,
but then again I am not a database admin so there might be problems with
this approach)

All of this is not a problem when building Lucene indexes. It is just a
standard flush and even if the SSD disk cache is disabled, we're talking
about "real" updates with substantial data, not just single bits
flipping, so the wear on the cells will be in the same ballpark as
standard SSD use.

NB: Sorry about the private email at first. I pressed the wrong button.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience (on developer machine)

Federico Fissore
In reply to this post by Toke Eskildsen
Toke Eskildsen, il 23/08/2011 13:37, ha scritto:
[...]
> Yes, the first generation of SSDs had bad wear-leveling and there has
> been some exceptionally bad eggs along the way, but we're long past that
> point now. All brand name SSDs use wear leveling and unless you set up
> pathological destruction cases (fill the drive to 99% and keep
> re-writing the last 1% ) the drive will be obsolete before it wears out.


Maybe this still is a point, thinking at how easy is today to fill your
local storage: for example, a "common" user will store video files. I
don't because that one and other articles have scared me (and here
definitely fear = lack of information)

So me too will like a more technical analysis if available

How long past that point do you think we are? Can you give some minimum
"model" age? Say, OCZ Vertex since 2 and Intel since 320 ?


> Efficiently as speed, yes. Efficiently as minimizing writes, no. On the
> contrary, disk swapping is much faster on SSDs along with temporary
> files and all the other secondary writes that are done throughout the
> day. Hit them hard. They're designed for it.


ok for the swap speed, but in using the ssd with swap and temp files
enabled, you are saying the opposite of articles around such as
http://www.howtogeek.com/62761/how-to-tweak-your-ssd-in-ubuntu-for-better-performance/

btw, if less free disk space = more destructive scenario, then the
bigger the safer, and here the price/size ratio suggest a conservative
use of SSD. Mine is 120GB and is 60% filled and I'd like not to go
beyond that point, to avoid surprises

best regards

federico

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience (on developer machine)

Toke Eskildsen
On Tue, 2011-08-23 at 16:10 +0200, Federico Fissore wrote:

[Toke: Re-writes is not a problem now]
> Maybe this still is a point, thinking at how easy is today to fill your
> local storage: for example, a "common" user will store video files.

It is only a problem if the SSD is stored to the brim (and don't have
hidden cells to counter the problem). If you store to the brim, you will
have problems working actively with the device - temporary files,
logging and whatnot tends to require that a non-trivial amount of
storage is free. If you are not working actively with the device, the
wear on the cells is not a problem. This brings us back to my initial
point: Yes, you can construct cases where there will be problems. But
they tend to be artificial:

Let's say you have a drive with just 5GB left. Let's say that the cells
can handle 10,000 writes. Doing constant rewrites of the 5GB gives you
10,000 * 5GB = 50TB before the drive gives up. I asked my drive about my
daily write average some time ago. It was 13GB/day. With that scenario,
the drive would live 10+ years.

Admittedly this is just back-of-the-envelope and it ignores a lot of
factors, but it does provides an idea of the amount of punishment they
can take.

> I don't because that one and other articles have scared me (and here
> definitely fear = lack of information)

I suggest AnandTech. They provide some excellent articles where they do
in-depth analysis and cut through many of the misconceptions as well as
hyperbole that has surrounded SSDs.

> How long past that point do you think we are? Can you give some minimum
> "model" age? Say, OCZ Vertex since 2 and Intel since 320 ?

I consider Intel X25 kind of a turning point in the history of SSDs.
That drive provided most of the features that modern SSDs has. Later
drives added better bulk speed, better maximum latency and better
TRIMming. Nice things but not as game-changing as the introduction of a
(relatively) cheap, reliable, wear-leveling drive with high performance
for both reads & writes.

[Toke: Use the SSD for tmp files and swap]

> ok for the swap speed, but in using the ssd with swap and temp files
> enabled, you are saying the opposite of articles around such as
> http://www.howtogeek.com/62761/how-to-tweak-your-ssd-in-ubuntu-for-better-performance/

The OCZ Onyx that they test is a pretty old drive, but ignoring that,
they do make statements such as "You can help increase the life of your
SSD by reducing how much the OS write to disk" which is technically
correct, but of no real value as I argued above.

They disable atime which I find is a fine idea, but since the OCZ sucks
at random writes (relatively to other SSDs) I guess they gain a fair
deal of performance there.

They put tmp in RAM without any explanation (although it fits well with
the atime-thing), but it does not matter since none of their tests use
tmp. For that matter, none of their tests use swap either. They might
claim that their article is based on testing but that is only true for a
subset of their tweaks. The wear due to tmp/noatime is just a claim they
make, without any explanation or calculations.

> btw, if less free disk space = more destructive scenario, then the
> bigger the safer, and here the price/size ratio suggest a conservative
> use of SSD. Mine is 120GB and is 60% filled and I'd like not to go
> beyond that point, to avoid surprises

With 10,000 writes you've got around 720 TB of writes. That is 200GB/day
for the next 10 years. I would suggest checking with S.M.A.R.T-tool to
see if it provides you with write-statistics. I would be surprised if
they were that high.

Regards,
Toke Eskildsen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience (on developer machine)

Paul Libbrecht-4
Funnily, I had such an experience: an SSD on the laptop of the brand SanDisk, guaranteed for 80 TB of writes.
Well, I had it twice changed under guarantee. Then the shop provided me an OCZ.
Maybe that lasts longer... I'm still in guarantee.

paul


Le 23 août 2011 à 17:11, Toke Eskildsen a écrit :

> On Tue, 2011-08-23 at 16:10 +0200, Federico Fissore wrote:
>
> [Toke: Re-writes is not a problem now]
>> Maybe this still is a point, thinking at how easy is today to fill your
>> local storage: for example, a "common" user will store video files.
>
> It is only a problem if the SSD is stored to the brim (and don't have
> hidden cells to counter the problem). If you store to the brim, you will
> have problems working actively with the device - temporary files,
> logging and whatnot tends to require that a non-trivial amount of
> storage is free. If you are not working actively with the device, the
> wear on the cells is not a problem. This brings us back to my initial
> point: Yes, you can construct cases where there will be problems. But
> they tend to be artificial:
>
> Let's say you have a drive with just 5GB left. Let's say that the cells
> can handle 10,000 writes. Doing constant rewrites of the 5GB gives you
> 10,000 * 5GB = 50TB before the drive gives up. I asked my drive about my
> daily write average some time ago. It was 13GB/day. With that scenario,
> the drive would live 10+ years.
>
> Admittedly this is just back-of-the-envelope and it ignores a lot of
> factors, but it does provides an idea of the amount of punishment they
> can take.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience (on developer machine)

Federico Fissore
In reply to this post by Toke Eskildsen
Great reply, thank you. Will re-read it and re-evaluate my position

Just one comment

Toke Eskildsen, il 23/08/2011 17:11, ha scritto:
[...]
>
> Let's say you have a drive with just 5GB left. Let's say that the cells
> can handle 10,000 writes. Doing constant rewrites of the 5GB gives you
> 10,000 * 5GB = 50TB before the drive gives up.
[...]


50TB before _every single cell in the drive_ gives up. You will change
the drive much sooner, probably at the first two occasions of corrupted
data.

Thanks again for the hints

fede

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience (on developer machine)

Toke Eskildsen
In reply to this post by Paul Libbrecht-4
On Tue, 2011-08-23 at 17:20 +0200, Paul Libbrecht wrote:
> Funnily, I had such an experience: an SSD on the laptop of the brand SanDisk, guaranteed for 80 TB of writes.
> Well, I had it twice changed under guarantee. Then the shop provided me an OCZ.
> Maybe that lasts longer... I'm still in guarantee.

Do you know if it was wear that broke the drive or some other defect?
There seems to be a strong tendency to attribute failing SSDs to wear,
while there can be a number of reasons. I am not claiming that SSDs are
unfailable, but I do claim that the fear of wearing them out is
unfounded.

Regards,
Toke Eskildsen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience (on developer machine)

Toke Eskildsen
In reply to this post by Federico Fissore
On Tue, 2011-08-23 at 17:56 +0200, Federico Fissore wrote:
> Great reply, thank you. Will re-read it and re-evaluate my position

Thanks for having an open mind.

Toke:
> > Let's say you have a drive with just 5GB left. Let's say that the cells
> > can handle 10,000 writes. Doing constant rewrites of the 5GB gives you
> > 10,000 * 5GB = 50TB before the drive gives up.
> [...]
>
> 50TB before _every single cell in the drive_ gives up. You will change
> the drive much sooner, probably at the first two occasions of corrupted
> data.

50TB for the 5GB of cells. The rest of the cells will be fine since
they've only ever been written to once in this artificial
destroy-the-drive test case. Of course that still leaves the drive
unusable. But oh well, I am firmly in the "this is so hot that I will
accept an astonishing amount of insane"-camp, so I tend focus a lot on
the positive things about SSDs.

As for corrupted data then at least some SSDs (Intel comes to mind) will
just stop accepting new data if they ever reach the point of being worn
out. They can still be read. The really great thing, seen from a server
perspective, is that the current state of wear can be queried: If it is
used for some special setup which requires an insane amount of small
writes, then it is a great help for the admin to be warned about pending
death.

Of course nothing guarantees that everything works as advertised. This
is where some real statistics on models and recalls would come in handy.

> fede

Heh. I'm sorry, but in danish "fede" means "fatty". On the other hand, I
also know what "Toke" means in english.

Regards,
Toke Eskildsen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience (on developer machine)

Paul Libbrecht-4
In reply to this post by Toke Eskildsen
Sorry Toke, I do not know.
The service shop replaced it fairly blindly.

paul


Le 23 août 2011 à 20:46, Toke Eskildsen a écrit :

> On Tue, 2011-08-23 at 17:20 +0200, Paul Libbrecht wrote:
>> Funnily, I had such an experience: an SSD on the laptop of the brand SanDisk, guaranteed for 80 TB of writes.
>> Well, I had it twice changed under guarantee. Then the shop provided me an OCZ.
>> Maybe that lasts longer... I'm still in guarantee.
>
> Do you know if it was wear that broke the drive or some other defect?
> There seems to be a strong tendency to attribute failing SSDs to wear,
> while there can be a number of reasons. I am not claiming that SSDs are
> unfailable, but I do claim that the fear of wearing them out is
> unfounded.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience (on developer machine)

David Nemeskey
In reply to this post by Toke Eskildsen
Hi,

interesting discussion about SSDs.

On 2011 August 23, Tuesday 20:56:44 Toke Eskildsen wrote:
> > 50TB before _every single cell in the drive_ gives up. You will change
> > the drive much sooner, probably at the first two occasions of corrupted
> > data.
>
> 50TB for the 5GB of cells. The rest of the cells will be fine since
> they've only ever been written to once in this artificial
> destroy-the-drive test case. Of course that still leaves the drive
> unusable.
Theoretically, in the case described above, it would be possible to move
'static' data (data of cells that have not been written to for a long time) to
the 5GB in question and use the 'fresher' cells as free space; this could be
done in a round-robin fashion. Do SSDs (or some one them) implement a similar
functionality? Or alternatively, are there tools that do this?

Regards,
David Nemeskey

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSD Experience (on developer machine)

Federico Fissore
David Nemeskey, il 24/08/2011 11:46, ha scritto:
[...]
> Theoretically, in the case described above, it would be possible to move
> 'static' data (data of cells that have not been written to for a long time) to
> the 5GB in question and use the 'fresher' cells as free space; this could be
> done in a round-robin fashion. Do SSDs (or some one them) implement a similar
> functionality? Or alternatively, are there tools that do this?


I add a question. Toke you said that "the current state of wear can be
queried". How?

AFAIK, cells target for a write are chosen just randomly between the
free ones, ignoring other factors

federico

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12