One more stack trace which is active during indexing. This call task is also
executed on the same single threaded executor as registering new searcher:
"searcherExecutor-48-thread-1" prio=10 tid=0x7f24c0715000 nid=0x3de6
runnable [0x7f24b096d000]
java.lang.Thread.State: RUNNABLE
I took a few thread dumps and here and the results:
- service which are indexing stuck on this stack trace:
"cmdDistribExecutor-3-thread-17669" prio=10 tid=0x7f1aae4a6800
nid=0x44a9 runnable [0x7f1a6c0f6000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRe
On Mon, 2013-12-09 at 11:29 +0100, michallos wrote:
> "on production" - no I can't profile it (because of huge overhead) ... Maybe
> with dynamic tracing but we can't do it right now.
https://blogs.oracle.com/nbprofiler/entry/visualvm_1_3_released
First section: "Sampler In The Core Tool".
> Afte
"on production" - no I can't profile it (because of huge overhead) ... Maybe
with dynamic tracing but we can't do it right now.
After server restart, delta time reset to 15-20 seconds so it is not caused
by the mergeFactor.
We have SSD and 70GB RAM (it is enough for us).
--
View this message in
On Tue, 2013-12-03 at 17:09 +0100, michallos wrote:
> This occurs only on production environment so I can't profile it :-)
Sure you can [Smiley]
If you use jvisualvm and stay away from the "Profiler"-tab, then you
should be fine. The "Sampler" performs non-intrusive profiling. Not as
thorough as
This occurs only on production environment so I can't profile it :-) Any
clues?
DirectUpdateHandler2 config:
15000
false
${solr.ulog.dir:}
--
View this message in context:
http://lucene.472066.n3.nabble.com/Constantly-increasing-time-of-full-data-import-tp4103873p4104722.htm
Michal,
I don't have much experience with DIH so I'll leave that to someone else
but I would suggest you profile Solr during imports. That might show you
where the bottleneck is.
Generally, it's reasonable to think Solr updates will get slower the larger
the indexes get and the more load you put
Update: I can see that times increases when the search load is higher. During
nights and weekends full load times doesn't increase. So it is not caused by
the number of documents being loaded (during weekends we have the same
number of new documents) but number of queries / minute.
Anyone observe
One more info that may be important: this index is divided into 64 logical
shards (4 replica factor).
--
View this message in context:
http://lucene.472066.n3.nabble.com/Constantly-increasing-time-of-full-data-import-tp4103873p4103874.html
Sent from the Solr - User mailing list archive at Nabbl
