You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Rich Cariens <ri...@gmail.com> on 2011/08/22 18:49:24 UTC
SSD Experience
(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!
Re: SSD Experience
Posted by Karl Wettin <ka...@gmail.com>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Isaias alves <is...@gmail.com>.
>> 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.
Yes, it is on-topic. Tks for all informations.
>> 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.
Good... the speed is not a most important parameter always. The merge of SSD
and NON-SSD ( backup? low relevance/old records? etc.. ). for me, is a
example of complete solution ( fast and secure ) using lucene.
--
I$@I@$
Re: SSD Experience (on developer machine)
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
On Wed, 2011-08-24 at 11:46 +0200, David Nemeskey wrote:
> 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.
A fine idea. Of course it is not guaranteed that data remains static,
but the probability if high.
> Do SSDs (or some one them) implement a similar
> functionality? Or alternatively, are there tools that do this?
I am sorry, but I have no idea if this is the case.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
On Wed, 2011-08-24 at 13:42 +0200, Federico Fissore wrote:
> I add a question. Toke you said that "the current state of wear can be
> queried". How?
With a S.M.A.R.T.-tool, preferably up-to-date to get it to display the
vendor-specific properties in an easy to understand manner.
On my Ubuntu-box with a 160GB Intel X25-M G2,
sudo smartctl -A /dev/sdb1
gives me (abbreviated by me)
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
9 Power_On_Hours [...] 9372
12 Power_Cycle_Count [...] 50
225 Host_Writes_Count [...] 176888
233 Media_Wearout_Indicator [...] 0
and
http://forums.storagereview.com/index.php/topic/28649-intel-x25-interpreting-smart-values/
tells me that I'll have to divide the raw value from #225 with 29,8,
resulting in 5,8TB written in total (about 15GB/day).
Some vendors provide specific software that makes it much easier.
Intel makes the Intels SSD Toolbox that unfortunately is Windows only.
> AFAIK, cells target for a write are chosen just randomly between the
> free ones, ignoring other factors
That would be a very bad wear-leveling strategy. Keeping a counter for
each cell and selecting the free cell with the lowest count is trivial.
However, given the bumpy road to great SSDs, I am sure that some vendors
has done it this way.
Regards,
Toke Eskildsen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Federico Fissore <fe...@fissore.org>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by David Nemeskey <ne...@sztaki.hu>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Federico Fissore <fe...@fissore.org>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Paul Libbrecht <pa...@hoplahup.net>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Paul Libbrecht <pa...@hoplahup.net>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Federico Fissore <fe...@fissore.org>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Marvin Humphrey <ma...@rectangular.com>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience (on developer machine)
Posted by Federico Fissore <fe...@fissore.org>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience
Posted by Paul Libbrecht <pa...@hoplahup.net>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience
Posted by Dawid Weiss <da...@gmail.com>.
>
>
> 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
Re: SSD Experience
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: SSD Experience
Posted by Dawid Weiss <da...@gmail.com>.
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 <te...@statsbiblioteket.dk>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: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
Re: SSD Experience
Posted by Toke Eskildsen <te...@statsbiblioteket.dk>.
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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org