Re: High disk write usage

2017-07-11 Thread Antonio De Miguel
Thanks Shawn! I will try to change the values of those parameters 2017-07-10 14:57 GMT+02:00 Shawn Heisey : > On 7/10/2017 2:57 AM, Antonio De Miguel wrote: > > I continue deeping inside this problem... high writing rates continues. > > > > Searching in logs i see this:

Re: High disk write usage

2017-07-10 Thread Shawn Heisey
On 7/10/2017 2:57 AM, Antonio De Miguel wrote: > I continue deeping inside this problem... high writing rates continues. > > Searching in logs i see this: > > 2017-07-10 08:46:18.888 INFO (commitScheduler-11-thread-1) [c:ads s:shard2 > r:core_node47 x:ads_shard2_replica3]

Re: High disk write usage

2017-07-10 Thread Antonio De Miguel
shards, but >> >> system >> >> > goes more inconsistent than with the current topology (5x10). I dont >> know >> >> > why... too many traffic perhaps? >> >> > >> >> > About merge factor.. we set default configuration

Re: High disk write usage

2017-07-05 Thread Antonio De Miguel
e current topology (5x10). I dont > know > >> > why... too many traffic perhaps? > >> > > >> > About merge factor.. we set default configuration for some days... but > >> when > >> > a merge occurs system overload. We probed with mer

Re: High disk write usage

2017-07-05 Thread Erick Erickson
e probed with mergefactor of 4 to >> improbe >> > query times and trying to have smaller merges. >> > >> > 2017-07-05 16:51 GMT+02:00 Markus Jelsma <markus.jel...@openindex.io>: >> > >> >> Try mergeFactor of 10 (default) which should be fine in m

Re: High disk write usage

2017-07-05 Thread Antonio De Miguel
e more shards and consider better > hardware > >> (SSD's) > >> > >> -Original message- > >> > From:Antonio De Miguel <deveto...@gmail.com> > >> > Sent: Wednesday 5th July 2017 16:48 > >> > To: solr-user@lucene

Re: High disk write usage

2017-07-05 Thread Erick Erickson
sage- >> > From:Antonio De Miguel <deveto...@gmail.com> >> > Sent: Wednesday 5th July 2017 16:48 >> > To: solr-user@lucene.apache.org >> > Subject: Re: High disk write usage >> > >> > Thnaks a lot alessandro! >> > &g

Re: High disk write usage

2017-07-05 Thread Antonio De Miguel
case, either create more shards and consider better hardware > (SSD's) > > -Original message- > > From:Antonio De Miguel <deveto...@gmail.com> > > Sent: Wednesday 5th July 2017 16:48 > > To: solr-user@lucene.apache.org > > Subject: Re: High disk write

RE: High disk write usage

2017-07-05 Thread Markus Jelsma
; To: solr-user@lucene.apache.org > Subject: Re: High disk write usage > > Thnaks a lot alessandro! > > Yes, we have very big physical dedicated machines, with a topology of 5 > shards and10 replicas each shard. > > > 1. transaction log files are increasing but not with th

Re: High disk write usage

2017-07-05 Thread Antonio De Miguel
Thnaks a lot alessandro! Yes, we have very big physical dedicated machines, with a topology of 5 shards and10 replicas each shard. 1. transaction log files are increasing but not with this rate 2. we 've probed with values between 300 and 2000 MB... without any visible results 3. We don't

Re: High disk write usage

2017-07-05 Thread alessandro.benedetti
Point 2 was the ram Buffer size : *ramBufferSizeMB* sets the amount of RAM that may be used by Lucene indexing for buffering added documents and deletions before they are flushed to the Directory. maxBufferedDocs sets a limit on the number of documents buffered

Re: High disk write usage

2017-07-05 Thread alessandro.benedetti
Is the phisical machine dedicated ? Is a dedicated VM on shared metal ? Apart from this operational checks I will assume the machine is dedicated. In Solr a write to the disk does not happen only on commit, I can think to other scenarios : 1) *Transaction log* [1] 2) 3) Spellcheck