Thanks Michail.
I am unable to locate bottleneck so far. Will try jstack and other tools.
On 8/25/16 11:40 PM, Mikhail Khludnev wrote:
Rough sampling under load makes sense as usual. JMC is one of the suitable
tools for this.
Sometimes even just jstack or looking at SolrAdmin/Threads is enough
Rough sampling under load makes sense as usual. JMC is one of the suitable
tools for this.
Sometimes even just jstack or looking at SolrAdmin/Threads is enough.
If the only small ratio of documents is updated and a bottleneck is
filterCache you can experiment with segmened filters which suite more
Follow up update ...
Set autowarm count to zero for caches for NRT and I could negotiate
latency from 2 min to 5 min :)
However, still seeing high QTimes and wondering where else can I look?
Should I debug the code or run some tools to isolate bottlenecks (disk
I/O, CPU or Query itself). Loo
And, I might add, you should look through your old logs
and see how long it takes to open a searcher. Let's
say Shawn's lower bound is what you see, i.e.
it takes a minute each to execute all the autowarming
in filterCache and queryResultCache... So you're current
latency is _at least_ 2 minutes be
On 7/26/16 5:46 AM, Shawn Heisey wrote:
On 7/22/2016 10:15 AM, Rallavagu wrote:
As Erick indicated, these settings are incompatible with Near Real Time
updates.
With those settings, every time you commit and create a new searcher,
Solr will execute up to 1000 queries (potentia
On 7/22/2016 10:15 AM, Rallavagu wrote:
> size="5000"
> initialSize="5000"
> autowarmCount="500"/>
>
> size="2"
> initialSize="2"
> autowarmCount="500"/>
As Erick in
On 7/22/16 9:56 AM, Erick Erickson wrote:
OK, scratch autowarming. In fact your autowarm counts
are quite high, I suspect far past "diminishing returns".
I usually see autowarm counts < 64, but YMMV.
Are you seeing actual hit ratios that are decent on
those caches (admin UI>>plugins/stats>>cac
Also, here is the link to screenshot.
https://dl.dropboxusercontent.com/u/39813705/Screen%20Shot%202016-07-22%20at%2010.40.21%20AM.png
Thanks
On 7/21/16 11:22 PM, Shawn Heisey wrote:
On 7/21/2016 11:25 PM, Rallavagu wrote:
There is no other software running on the system and it is completely
Here is the snapshot of memory usage from "top" as you mentioned. First
row is "solr" process. Thanks.
PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+
COMMAND
29468 solr 20 0 27.536g 0.013t 3.297g S 45.7 27.6 4251:45 java
21366 root 20 0 14.499g 217824
OK, scratch autowarming. In fact your autowarm counts
are quite high, I suspect far past "diminishing returns".
I usually see autowarm counts < 64, but YMMV.
Are you seeing actual hit ratios that are decent on
those caches (admin UI>>plugins/stats>>cache>>...)
And your cache sizes are also quite h
On 7/22/16 8:34 AM, Erick Erickson wrote:
Mostly this sounds like a problem that could be cured with
autowarming. But two things are conflicting here:
1> you say "We have a requirement to have updates available immediately (NRT)"
2> your docs aren't available for 120 seconds given your autoSoft
Mostly this sounds like a problem that could be cured with
autowarming. But two things are conflicting here:
1> you say "We have a requirement to have updates available immediately (NRT)"
2> your docs aren't available for 120 seconds given your autoSoftCommit
settings unless you're specifying
-Dsol
On 7/21/2016 11:25 PM, Rallavagu wrote:
> There is no other software running on the system and it is completely
> dedicated to Solr. It is running on Linux. Here is the full version.
>
> Linux version 3.8.13-55.1.6.el7uek.x86_64
> (mockbu...@ca-build56.us.oracle.com) (gcc version 4.8.3 20140911 (Re
On 7/21/16 9:16 PM, Shawn Heisey wrote:
On 7/21/2016 9:37 AM, Rallavagu wrote:
I suspect swapping as well. But, for my understanding - are the index
files from disk memory mapped automatically at the startup time?
They are *mapped* at startup time, but they are not *read* at startup.
The map
On 7/21/2016 9:37 AM, Rallavagu wrote:
> I suspect swapping as well. But, for my understanding - are the index
> files from disk memory mapped automatically at the startup time?
They are *mapped* at startup time, but they are not *read* at startup.
The mapping just sets up a virtual address space
:18 AM, Rallavagu wrote:
Solr 5.4.1 with embedded jetty with cloud enabled
We have a Solr deployment (approximately 3 million documents) with both
write and search operations happening. We have a requirement to have updates
available immediately (NRT). Configured with default
"solr.NRTCach
write and search operations happening. We have a requirement to have updates
> available immediately (NRT). Configured with default
> "solr.NRTCachingDirectoryFactory" for directory factory. Considering the
> fact that every time there is an update, caches are invalidated and re-
Solr 5.4.1 with embedded jetty with cloud enabled
We have a Solr deployment (approximately 3 million documents) with both
write and search operations happening. We have a requirement to have
updates available immediately (NRT). Configured with default
"solr.NRTCachingDirectoryFactory
18 matches
Mail list logo
