is this method equivalent to set vm.swappiness which is global? or it can set the swappiness for jvm process?
On Tue, Jun 12, 2012 at 5:11 AM, Mikhail Khludnev <mkhlud...@griddynamics.com> wrote: > Point about premature optimization makes sense for me. However some time > ago I've bookmarked potentially useful approach > http://lucene.472066.n3.nabble.com/High-response-time-after-being-idle-tp3616599p3617604.html. > > On Mon, Jun 11, 2012 at 3:02 PM, Toke Eskildsen > <t...@statsbiblioteket.dk>wrote: > >> On Mon, 2012-06-11 at 11:38 +0200, Li Li wrote: >> > yes, I need average query time less than 10 ms. The faster the better. >> > I have enough memory for lucene because I know there are not too much >> > data. there are not many modifications. every day there are about >> > hundreds of document update. if indexes are not in physical memory, >> > then IO operations will cost a few ms. >> >> I'm with Michael on this one: It seems that you're doing a premature >> optimization. Guessing that your final index will be < 5GB in size with >> 1 million documents (give or take 900.000:-), relatively simple queries >> and so on, an average response time of 10 ms should be attainable even >> on spinning drives. One hundred document updates per day are not many, >> so again I would not expect problems. >> >> As is often the case on this mailing list, the advice is "try it". Using >> a normal on-disk index and doing some warm up is the easy solution to >> implement and nearly all of your work on this will be usable for a >> RAM-based solution, if you are not satisfied with the speed. Or you >> could buy a small & cheap SSD and have no more worries... >> >> Regards, >> Toke Eskildsen >> >> > > > -- > Sincerely yours > Mikhail Khludnev > Tech Lead > Grid Dynamics > > <http://www.griddynamics.com> > <mkhlud...@griddynamics.com>
