Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of dotsid@gmail.com designates
 209.85.215.48 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
Subject: Re: RAM or SSD...
From: Denis Bazhenov <dotsid@gmail.com>
In-Reply-To: <BLU164-W36A5154D0F1029E10272BBB9D80@phx.gbl>
Date: Sat, 28 Jul 2012 09:51:59 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C308372-B7F9-469D-A0DC-CB773735B51A@gmail.com>
References: <BLU164-W481D7E36EBEFC05F7C6FACB9DA0@phx.gbl>
 <1342676367.12618.45.camel@te-prime>,<CAK9GPcTdux+=ymJqja1koDohPjiDpzL7fDEi+ThC1Ehp4DhSFw@mail.gmail.com>,<CALr4HzrADbwOpQ7cZp9C8GeOWKqXViBQ9ZKiAF2M+HmnaciHCw@mail.gmail.com>
 <BLU164-W10164AA6C9AF13D0DC2059B9D90@phx.gbl>,<CAM21Rt-8RrDodbD4Db6WHkKDEZbu_h57KiJ0VvoPG_R0S2g98A@mail.gmail.com>
 <BLU164-W36A5154D0F1029E10272BBB9D80@phx.gbl>
To: java-user@lucene.apache.org

Another option is to use tmpfs (memory driven file system) as a backing =
storage for index. This allows to minimize disc access latency. In =
average case this doesn't make sense, because OS will cache file system =
access quite effective if you have enough memory. But in worst case (if =
you measure response time 99 percentile or higher, for example) this =
method can give you more stable performance.

On Jul 20, 2012, at 10:32 PM, Dragon Fly <dragon-fly999@hotmail.com> =
wrote:

>=20
> Thank you.
>=20
>> From: dawid.weiss@gmail.com
>> Date: Thu, 19 Jul 2012 13:34:26 +0200
>> Subject: Re: RAM or SSD...
>> To: java-user@lucene.apache.org
>>=20
>> Read this:
>> =
http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html
>>=20
>> Dawid
>>=20
>> On Thu, Jul 19, 2012 at 1:32 PM, Dragon Fly =
<dragon-fly999@hotmail.com> wrote:
>>>=20
>>> The slowest part of my application is to read the search hits from =
disk.  I was hoping that using an SSD or RAMDirectory/MMapDirectory =
would speed that up.  I read the JavaDoc for MMapDirectory but didn't =
really understand how that differs from RAMDirectory.  Could someone =
please explain?
>>>=20
>>>> Date: Wed, 18 Jul 2012 23:46:51 -0700
>>>> Subject: Re: RAM or SSD...
>>>> From: vfunstein@gmail.com
>>>> To: java-user@lucene.apache.org
>>>>=20
>>>> I was referring to *RAMDirectory*.
>>>>=20
>>>> On Wed, Jul 18, 2012 at 11:04 PM, Lance Norskog <goksron@gmail.com> =
wrote:
>>>>>> You do not want to store 30 G of data in the JVM heap, no matter =
what
>>>> library does this.
>>>>> MMapDirectory does not store data in the JVM heap. It lets the
>>>>> operating system manage the disk buffer space. Even if the JVM =
says "I
>>>>> have 30G of memory space", it really does not. It only has address
>>>>> space allocated by the  OS but no memory.
>>>>>=20
>>>>> On Wed, Jul 18, 2012 at 10:39 PM, Toke Eskildsen =
<te@statsbiblioteket.dk>
>>>> wrote:
>>>>>> On Wed, 2012-07-18 at 17:50 +0200, Dragon Fly wrote:
>>>>>>> If I want to improve performance, which of the following is =
better and
>>>> why?
>>>>>>>=20
>>>>>>> 1. Buy a machine with a lot of RAM and use a RAMDirectory for =
the index.
>>>>>>=20
>>>>>> As others has pointed out, MMapDirectory should work better than
>>>>>> RAMDirectory. I am sure it will work fine with a relative small =
index
>>>>>> such as yours. However, it does not scale that well with index =
size.
>>>>>>=20
>>>>>>> 2. Put the index on a solid state drive.
>>>>>>=20
>>>>>> Why anyone buys computers without SSD's is a mystery to me. Use =
SSDs for
>>>>>> the small low-latency stuff and a secondary spinning drive for =
the large
>>>>>> slow stuff. Nowadays, a 30GB index (or 100GB for that matter) =
falls into
>>>>>> the small low-latency bucket. SSDs speeds up almost everything, =
saves
>>>>>> RAM and spares a lot of work hours optimizing I/O-speed.
>>>>>>=20
>>>>>> Regards,
>>>>>> Toke Eskildsen
>>>>>>=20
>>>>>>=20
>>>>>> =
---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> --
>>>>> Lance Norskog
>>>>> goksron@gmail.com
>>>>>=20
>>>>> =
---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>>>>=20
>>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>=20
> 		 	   		 =20

---
Denis Bazhenov <dotsid@gmail.com>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org