Re: unified highlighter performance in solr 8.5.1
Here's my PR, which includes some edits to the ref guide docs where I tried to clarify these settings a little too. https://github.com/apache/lucene-solr/pull/1651 ~ David On Sat, Jul 4, 2020 at 8:44 AM Nándor Mátravölgyi wrote: > I guess that's fair. Let's have hl.fragsizeIsMinimum=true as default. > > On 7/4/20, David Smiley wrote: > > I doubt that WORD mode is impacted much by hl.fragsizeIsMinimum in terms > of > > quality of the highlight since there are vastly more breaks to pick from. > > I think that setting is more useful in SENTENCE mode if you can stand the > > perf hit. If you agree, then why not just let this one default to > "true"? > > > > We agree on better documenting the perf trade-off. > > > > Thanks again for working on these settings, BTW. > > > > ~ David > > > > > > On Fri, Jul 3, 2020 at 1:25 PM Nándor Mátravölgyi < > nandor.ma...@gmail.com> > > wrote: > > > >> Since the issue seems to be affecting the highlighter differently > >> based on which mode it is using, having different defaults for the > >> modes could be explored. > >> > >> WORD may have the new defaults as it has little effect on performance > >> and it creates nicer highlights. > >> SENTENCE should have the defaults that produce reasonable performance. > >> The docs could document this while also mentioning that the UH's > >> performance is highly dependent on the underlying Java String/Text? > >> Iterator. > >> > >> One can argue that having different defaults based on mode is > >> confusing. In this case I think the defaults should be changed to have > >> the SENTENCE mode perform better. Maybe the options for nice > >> highlights with WORD mode could be put into the docs in this case as > >> some form of an example. > >> > >> As long as I can use the UH with nicely aligned snippets in WORD mode > >> I'm fine with any defaults. I explicitly set them in the config and in > >> the queries most of the time anyways. > >> > > >
Re: Time-out errors while indexing (Solr 7.7.1)
Thank a lot for your inputs and suggestions, even I was thinking similar like creating another collection of the same ( hot and cold), and moving documents which are older than certain days like 180 days from original collection (hot) to new collection(cold). Thanks, Madhava Sent from my iPhone > On 4 Jul 2020, at 14:37, Erick Erickson wrote: > > You need more shards. And, I’m pretty certain, more hardware. > > You say you have 13 billion documents and 6 shards. Solr/Lucene has an > absolute upper limit of 2B (2^31) docs per shard. I don’t quite know how > you’re running at all unless that 13B is a round number. If you keep adding > documents, your installation will shortly, at best, stop accepting new > documents for indexing. At worst you’ll start seeing weird errors and > possibly corrupt indexes and have to re-index everything from scratch. > > You’ve backed yourself in to a pretty tight corner here. You either have to > re-index to a properly-sized cluster or use SPLITSHARD. This latter will > double the index-on-disk size (it creates two child indexes per replica and > keeps the old one for safety’s sake that you have to clean up later). I > strongly recommend you stop ingesting more data while you do this. > > You say you have 6 VMs with 2 nodes running on each. If those VMs are > co-located with anything else, the physical hardware is going to be stressed. > VMs themselves aren’t bad, but somewhere there’s physical hardware that runs > it… > > In fact, I urge you to stop ingesting data immediately and address this > issue. You have a cluster that’s mis-configured, and you must address that > before Bad Things Happen. > > Best, > Erick > >> On Jul 4, 2020, at 5:09 AM, Mad have wrote: >> >> Hi Eric, >> >> There are total 6 VM’s in Solr clusters and 2 nodes are running on each VM. >> Total number of shards are 6 with 3 replicas. I can see the index size is >> more than 220GB on each node for the collection where we are facing the >> performance issue. >> >> The more documents we add to the collection the indexing become slow and I >> also have same impression that the size of the collection is creating this >> issue. Appreciate if you can suggests any solution on this. >> >> >> Regards, >> Madhava >> Sent from my iPhone >> On 3 Jul 2020, at 23:30, Erick Erickson wrote: >>> >>> Oops, I transposed that. If your index is a terabyte and your RAM is 128M, >>> _that’s_ a red flag. >>> On Jul 3, 2020, at 5:53 PM, Erick Erickson wrote: You haven’t said how many _shards_ are present. Nor how many replicas of the collection you’re hosting per physical machine. Nor how large the indexes are on disk. Those are the numbers that count. The latter is somewhat fuzzy, but if your aggregate index size on a machine with, say, 128G of memory is a terabyte, that’s a red flag. Short form, though is yes. Subject to the questions above, this is what I’d be looking at first. And, as I said, if you’ve been steadily increasing the total number of documents, you’ll reach a tipping point sometime. Best, Erick >> On Jul 3, 2020, at 5:32 PM, Mad have wrote: > > Hi Eric, > > The collection has almost 13billion documents with each document around > 5kb size, all the columns around 150 are the indexed. Do you think that > number of documents in the collection causing this issue. Appreciate your > response. > > Regards, > Madhava > > Sent from my iPhone > >> On 3 Jul 2020, at 12:42, Erick Erickson wrote: >> >> If you’re seeing low CPU utilization at the same time, you probably >> just have too much data on too little hardware. Check your >> swapping, how much of your I/O is just because Lucene can’t >> hold all the parts of the index it needs in memory at once? Lucene >> uses MMapDirectory to hold the index and you may well be >> swapping, see: >> >> https://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html >> >> But my guess is that you’ve just reached a tipping point. You say: >> >> "From last 2-3 weeks we have been noticing either slow indexing or >> timeout errors while indexing” >> >> So have you been continually adding more documents to your >> collections for more than the 2-3 weeks? If so you may have just >> put so much data on the same boxes that you’ve gone over >> the capacity of your hardware. As Toke says, adding physical >> memory for the OS to use to hold relevant parts of the index may >> alleviate the problem (again, refer to Uwe’s article for why). >> >> All that said, if you’re going to keep adding document you need to >> seriously think about adding new machines and moving some of >> your replicas to them. >> >> Best, >> Erick >> >>> On Jul 3, 2020, at 7:
Re: Almost nodes in Solrcloud dead suddently
*total thread is 25.6k when solr hang. On Sunday, July 5, 2020, 2:55:26 AM GMT+7, Tran Van Hoan wrote: All server only run Solr, zookeeper, exporters (node-exporter, process-exporter, solr-exporter, zoo-exporter). - network: no package loss, TCP no issue before incident, TCP drop around 100-200/s when incident and overflow ~100 in somaxcon. - total mem Avalilable is greater 25G (Solr's XMX = 30G)- CPU < 10%, no high load average 5, 15 (except when solr hang, high load average is high)- Normally total process is around ~2k, when incident occurs, total thread is 25.6 (solr out of cluster but still running)- low TCP contrack- Swapiness = 0 and no use swap;- Solr cloud has 2 collections, only one collection down causes node down (the remain collection is still green) On Sunday, July 5, 2020, 1:30:59 AM GMT+7, Rodrigo Oliveira wrote: Network it's ok? Between nodes? The use? Swap it's disabled? Swapiness rhe value it's 0? Em sáb, 4 de jul de 2020 15:19, Tran Van Hoan escreveu: > I used physical servers, and IO wait is small :(!!!I saw that iptables > dropped all ACK message from clients (not only client solr, prometheus > scape metric from exporter was dropped too).all when i check netstat > -anp|grep 8983, all socket are TIME_WAIT state.Only restart solrs, the > incident was resolved. Total request around 2.5k request per second per > node. > > On Sunday, July 5, 2020, 1:11:38 AM GMT+7, Rodrigo Oliveira < > adamantina.rodr...@gmail.com> wrote: > > Hi, > > I had this problem. In my case was the wait/io in vm. I migrate my > environment to another place and solved. > > Actually it's problem wirh wait/io at host physical (until backup it's a > problem over veeam). > > Regards > > Em sáb, 4 de jul de 2020 12:30, Tran Van Hoan > escreveu: > > > The problem reoccurs repeatly in recent days. > > To day i tried dump heap and thread. Only dumping thread, heap can not > > because solr instance was hang. > > Almost thread was blocked. > > > > On Tuesday, June 23, 2020, 10:42:36 PM GMT+7, Tran Van Hoan > > wrote: > > > > > > I checked node exporter metrics and saw network no problem > > > > On Tuesday, June 23, 2020, 8:37:41 PM GMT+7, Tran Van Hoan < > > tranvanhoan...@yahoo.com> wrote: > > > > > > I check node exporter, no problem with OS, hardware and network. > > I attached images about solr metrics 7 days and 12h. > > > > On Tuesday, June 23, 2020, 2:23:05 PM GMT+7, Dario Rigolin < > > dario.rigo...@comperio.it> wrote: > > > > > > What about a network issue? > > > > Il giorno mar 23 giu 2020 alle ore 01:37 Tran Van Hoan > > ha scritto: > > > > > > > > > > dear all, > > > > > > I have a solr cloud 8.2.0 with 6 instance per 6 server (64G RAM), each > > > instance has xmx = xms = 30G. > > > > > > Today almost nodes in the solrcloud were dead 2 times from 8:00AM (5/6 > > > nodes were down) and 1:00PM (2/6 nodes were down). yesterday, One > node > > > were down. almost metrics didn't increase too much except threads. > > > > > > Performance in one week ago: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > performace 12h ago: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I go to the admin UI, some node dead some node too long to response. > When > > > checking logfile, they generate too much (log level warning), here are > > logs > > > which appears in the solr cloud: > > > > > > Log before server 4 and 6 down > > > > > > - Server 4 before it dead: > > > > > > + o.a.s.h.RequestHandlerBase java.io.IOException: > > > java.util.concurrent.TimeoutException: Idle timeout expired: > > 12/12 > > > ms > > > > > > +org.apache.solr.client.solrj.SolrServerException: Timeout occured > while > > > waiting response from server at: > > > http://server6:8983/solr/mycollection_shard3_replica_n5/select > > > > > > > > > > > > at > > > > > > org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:406) > > > > > > at > > > > > > org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:746) > > > > > > at > > > org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1274) > > > > > > at > > > > > > org.apache.solr.handler.component.HttpShardHandler.request(HttpShardHandler.java:238) > > > > > > at > > > > > > org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:199) > > > > > > at > > java.util.concurrent.FutureTask.run(FutureTask.java:266) > > > > > > at > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > > > > > > at > > java.util.concurrent.FutureTask.run(FutureTask.java:266) > > > > > > at
Re: Almost nodes in Solrcloud dead suddently
All server only run Solr, zookeeper, exporters (node-exporter, process-exporter, solr-exporter, zoo-exporter). - network: no package loss, TCP no issue before incident, TCP drop around 100-200/s when incident and overflow ~100 in somaxcon. - total mem Avalilable is greater 25G (Solr's XMX = 30G)- CPU < 10%, no high load average 5, 15 (except when solr hang, high load average is high)- Normally total process is around ~2k, when incident occurs, total thread is 25.6 (solr out of cluster but still running)- low TCP contrack- Swapiness = 0 and no use swap;- Solr cloud has 2 collections, only one collection down causes node down (the remain collection is still green) On Sunday, July 5, 2020, 1:30:59 AM GMT+7, Rodrigo Oliveira wrote: Network it's ok? Between nodes? The use? Swap it's disabled? Swapiness rhe value it's 0? Em sáb, 4 de jul de 2020 15:19, Tran Van Hoan escreveu: > I used physical servers, and IO wait is small :(!!!I saw that iptables > dropped all ACK message from clients (not only client solr, prometheus > scape metric from exporter was dropped too).all when i check netstat > -anp|grep 8983, all socket are TIME_WAIT state.Only restart solrs, the > incident was resolved. Total request around 2.5k request per second per > node. > > On Sunday, July 5, 2020, 1:11:38 AM GMT+7, Rodrigo Oliveira < > adamantina.rodr...@gmail.com> wrote: > > Hi, > > I had this problem. In my case was the wait/io in vm. I migrate my > environment to another place and solved. > > Actually it's problem wirh wait/io at host physical (until backup it's a > problem over veeam). > > Regards > > Em sáb, 4 de jul de 2020 12:30, Tran Van Hoan > escreveu: > > > The problem reoccurs repeatly in recent days. > > To day i tried dump heap and thread. Only dumping thread, heap can not > > because solr instance was hang. > > Almost thread was blocked. > > > > On Tuesday, June 23, 2020, 10:42:36 PM GMT+7, Tran Van Hoan > > wrote: > > > > > > I checked node exporter metrics and saw network no problem > > > > On Tuesday, June 23, 2020, 8:37:41 PM GMT+7, Tran Van Hoan < > > tranvanhoan...@yahoo.com> wrote: > > > > > > I check node exporter, no problem with OS, hardware and network. > > I attached images about solr metrics 7 days and 12h. > > > > On Tuesday, June 23, 2020, 2:23:05 PM GMT+7, Dario Rigolin < > > dario.rigo...@comperio.it> wrote: > > > > > > What about a network issue? > > > > Il giorno mar 23 giu 2020 alle ore 01:37 Tran Van Hoan > > ha scritto: > > > > > > > > > > dear all, > > > > > > I have a solr cloud 8.2.0 with 6 instance per 6 server (64G RAM), each > > > instance has xmx = xms = 30G. > > > > > > Today almost nodes in the solrcloud were dead 2 times from 8:00AM (5/6 > > > nodes were down) and 1:00PM (2/6 nodes were down). yesterday, One > node > > > were down. almost metrics didn't increase too much except threads. > > > > > > Performance in one week ago: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > performace 12h ago: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I go to the admin UI, some node dead some node too long to response. > When > > > checking logfile, they generate too much (log level warning), here are > > logs > > > which appears in the solr cloud: > > > > > > Log before server 4 and 6 down > > > > > > - Server 4 before it dead: > > > > > > + o.a.s.h.RequestHandlerBase java.io.IOException: > > > java.util.concurrent.TimeoutException: Idle timeout expired: > > 12/12 > > > ms > > > > > > +org.apache.solr.client.solrj.SolrServerException: Timeout occured > while > > > waiting response from server at: > > > http://server6:8983/solr/mycollection_shard3_replica_n5/select > > > > > > > > > > > > at > > > > > > org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:406) > > > > > > at > > > > > > org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:746) > > > > > > at > > > org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1274) > > > > > > at > > > > > > org.apache.solr.handler.component.HttpShardHandler.request(HttpShardHandler.java:238) > > > > > > at > > > > > > org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:199) > > > > > > at > > java.util.concurrent.FutureTask.run(FutureTask.java:266) > > > > > > at > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > > > > > > at > > java.util.concurrent.FutureTask.run(FutureTask.java:266) > > > > > > at > > > > > > com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.ja
Re: Almost nodes in Solrcloud dead suddently
Network it's ok? Between nodes? The use? Swap it's disabled? Swapiness rhe value it's 0? Em sáb, 4 de jul de 2020 15:19, Tran Van Hoan escreveu: > I used physical servers, and IO wait is small :(!!!I saw that iptables > dropped all ACK message from clients (not only client solr, prometheus > scape metric from exporter was dropped too).all when i check netstat > -anp|grep 8983, all socket are TIME_WAIT state.Only restart solrs, the > incident was resolved. Total request around 2.5k request per second per > node. > > On Sunday, July 5, 2020, 1:11:38 AM GMT+7, Rodrigo Oliveira < > adamantina.rodr...@gmail.com> wrote: > > Hi, > > I had this problem. In my case was the wait/io in vm. I migrate my > environment to another place and solved. > > Actually it's problem wirh wait/io at host physical (until backup it's a > problem over veeam). > > Regards > > Em sáb, 4 de jul de 2020 12:30, Tran Van Hoan > escreveu: > > > The problem reoccurs repeatly in recent days. > > To day i tried dump heap and thread. Only dumping thread, heap can not > > because solr instance was hang. > > Almost thread was blocked. > > > > On Tuesday, June 23, 2020, 10:42:36 PM GMT+7, Tran Van Hoan > > wrote: > > > > > > I checked node exporter metrics and saw network no problem > > > > On Tuesday, June 23, 2020, 8:37:41 PM GMT+7, Tran Van Hoan < > > tranvanhoan...@yahoo.com> wrote: > > > > > > I check node exporter, no problem with OS, hardware and network. > > I attached images about solr metrics 7 days and 12h. > > > > On Tuesday, June 23, 2020, 2:23:05 PM GMT+7, Dario Rigolin < > > dario.rigo...@comperio.it> wrote: > > > > > > What about a network issue? > > > > Il giorno mar 23 giu 2020 alle ore 01:37 Tran Van Hoan > > ha scritto: > > > > > > > > > > dear all, > > > > > > I have a solr cloud 8.2.0 with 6 instance per 6 server (64G RAM), each > > > instance has xmx = xms = 30G. > > > > > > Today almost nodes in the solrcloud were dead 2 times from 8:00AM (5/6 > > > nodes were down) and 1:00PM (2/6 nodes were down). yesterday, One > node > > > were down. almost metrics didn't increase too much except threads. > > > > > > Performance in one week ago: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > performace 12h ago: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I go to the admin UI, some node dead some node too long to response. > When > > > checking logfile, they generate too much (log level warning), here are > > logs > > > which appears in the solr cloud: > > > > > > Log before server 4 and 6 down > > > > > > - Server 4 before it dead: > > > > > >+ o.a.s.h.RequestHandlerBase java.io.IOException: > > > java.util.concurrent.TimeoutException: Idle timeout expired: > > 12/12 > > > ms > > > > > > +org.apache.solr.client.solrj.SolrServerException: Timeout occured > while > > > waiting response from server at: > > > http://server6:8983/solr/mycollection_shard3_replica_n5/select > > > > > > > > > > > > at > > > > > > org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:406) > > > > > >at > > > > > > org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:746) > > > > > >at > > > org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1274) > > > > > >at > > > > > > org.apache.solr.handler.component.HttpShardHandler.request(HttpShardHandler.java:238) > > > > > >at > > > > > > org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:199) > > > > > >at > > java.util.concurrent.FutureTask.run(FutureTask.java:266) > > > > > >at > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > > > > > >at > > java.util.concurrent.FutureTask.run(FutureTask.java:266) > > > > > >at > > > > > > com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:181) > > > > > >at > > > > > > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) > > > > > >at > > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > > > > > >at > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > > > > > >... 1 more > > > > > > Caused by: java.util.concurrent.TimeoutException > > > > > >at > > > > > > org.eclipse.jetty.client.util.InputStreamResponseListener.get(InputStreamResponseListener.java:216) > > > > > >at > > > > > > org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient
Re: Almost nodes in Solrcloud dead suddently
I used physical servers, and IO wait is small :(!!!I saw that iptables dropped
all ACK message from clients (not only client solr, prometheus scape metric
from exporter was dropped too).all when i check netstat -anp|grep 8983, all
socket are TIME_WAIT state.Only restart solrs, the incident was resolved. Total
request around 2.5k request per second per node.
On Sunday, July 5, 2020, 1:11:38 AM GMT+7, Rodrigo Oliveira
wrote:
Hi,
I had this problem. In my case was the wait/io in vm. I migrate my
environment to another place and solved.
Actually it's problem wirh wait/io at host physical (until backup it's a
problem over veeam).
Regards
Em sáb, 4 de jul de 2020 12:30, Tran Van Hoan
escreveu:
> The problem reoccurs repeatly in recent days.
> To day i tried dump heap and thread. Only dumping thread, heap can not
> because solr instance was hang.
> Almost thread was blocked.
>
> On Tuesday, June 23, 2020, 10:42:36 PM GMT+7, Tran Van Hoan
> wrote:
>
>
> I checked node exporter metrics and saw network no problem
>
> On Tuesday, June 23, 2020, 8:37:41 PM GMT+7, Tran Van Hoan <
> tranvanhoan...@yahoo.com> wrote:
>
>
> I check node exporter, no problem with OS, hardware and network.
> I attached images about solr metrics 7 days and 12h.
>
> On Tuesday, June 23, 2020, 2:23:05 PM GMT+7, Dario Rigolin <
> dario.rigo...@comperio.it> wrote:
>
>
> What about a network issue?
>
> Il giorno mar 23 giu 2020 alle ore 01:37 Tran Van Hoan
> ha scritto:
>
>
> >
> > dear all,
> >
> > I have a solr cloud 8.2.0 with 6 instance per 6 server (64G RAM), each
> > instance has xmx = xms = 30G.
> >
> > Today almost nodes in the solrcloud were dead 2 times from 8:00AM (5/6
> > nodes were down) and 1:00PM (2/6 nodes were down). yesterday, One node
> > were down. almost metrics didn't increase too much except threads.
> >
> > Performance in one week ago:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > performace 12h ago:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > I go to the admin UI, some node dead some node too long to response. When
> > checking logfile, they generate too much (log level warning), here are
> logs
> > which appears in the solr cloud:
> >
> > Log before server 4 and 6 down
> >
> > - Server 4 before it dead:
> >
> > + o.a.s.h.RequestHandlerBase java.io.IOException:
> > java.util.concurrent.TimeoutException: Idle timeout expired:
> 12/12
> > ms
> >
> > +org.apache.solr.client.solrj.SolrServerException: Timeout occured while
> > waiting response from server at:
> > http://server6:8983/solr/mycollection_shard3_replica_n5/select
> >
> >
> >
> > at
> >
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:406)
> >
> > at
> >
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:746)
> >
> > at
> > org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1274)
> >
> > at
> >
> org.apache.solr.handler.component.HttpShardHandler.request(HttpShardHandler.java:238)
> >
> > at
> >
> org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:199)
> >
> > at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >
> > at
> > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> >
> > at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >
> > at
> >
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:181)
> >
> > at
> >
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> >
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> >
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> >
> > ... 1 more
> >
> > Caused by: java.util.concurrent.TimeoutException
> >
> > at
> >
> org.eclipse.jetty.client.util.InputStreamResponseListener.get(InputStreamResponseListener.java:216)
> >
> > at
> >
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:397)
> >
> > ... 12 more
> >
> >
> >
> > + o.a.s.s.HttpSolrCall invalid return code: -1
> >
> > + o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp:
> > 1592803662746 , received timestamp: 1592803796152 , TTL: 12
> >
> > + o.a.s.s.PKIAuthenticationPlugin Decryption failed , key must be wrong
> =>
> > java.security.InvalidKeyException: No installed provider supports this
> key:
> > (null)
> >
> > + o.a.s.u.ErrorReportingConcurrentUpdateSolrClient Error when calling
> > SolrCmdDistributor$Req: cmd=delete{,commitWithin=-1}; node=ForwardNode:
Re: Almost nodes in Solrcloud dead suddently
Hi,
I had this problem. In my case was the wait/io in vm. I migrate my
environment to another place and solved.
Actually it's problem wirh wait/io at host physical (until backup it's a
problem over veeam).
Regards
Em sáb, 4 de jul de 2020 12:30, Tran Van Hoan
escreveu:
> The problem reoccurs repeatly in recent days.
> To day i tried dump heap and thread. Only dumping thread, heap can not
> because solr instance was hang.
> Almost thread was blocked.
>
> On Tuesday, June 23, 2020, 10:42:36 PM GMT+7, Tran Van Hoan
> wrote:
>
>
> I checked node exporter metrics and saw network no problem
>
> On Tuesday, June 23, 2020, 8:37:41 PM GMT+7, Tran Van Hoan <
> tranvanhoan...@yahoo.com> wrote:
>
>
> I check node exporter, no problem with OS, hardware and network.
> I attached images about solr metrics 7 days and 12h.
>
> On Tuesday, June 23, 2020, 2:23:05 PM GMT+7, Dario Rigolin <
> dario.rigo...@comperio.it> wrote:
>
>
> What about a network issue?
>
> Il giorno mar 23 giu 2020 alle ore 01:37 Tran Van Hoan
> ha scritto:
>
>
> >
> > dear all,
> >
> > I have a solr cloud 8.2.0 with 6 instance per 6 server (64G RAM), each
> > instance has xmx = xms = 30G.
> >
> > Today almost nodes in the solrcloud were dead 2 times from 8:00AM (5/6
> > nodes were down) and 1:00PM (2/6 nodes were down). yesterday, One node
> > were down. almost metrics didn't increase too much except threads.
> >
> > Performance in one week ago:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > performace 12h ago:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > I go to the admin UI, some node dead some node too long to response. When
> > checking logfile, they generate too much (log level warning), here are
> logs
> > which appears in the solr cloud:
> >
> > Log before server 4 and 6 down
> >
> > - Server 4 before it dead:
> >
> >+ o.a.s.h.RequestHandlerBase java.io.IOException:
> > java.util.concurrent.TimeoutException: Idle timeout expired:
> 12/12
> > ms
> >
> > +org.apache.solr.client.solrj.SolrServerException: Timeout occured while
> > waiting response from server at:
> > http://server6:8983/solr/mycollection_shard3_replica_n5/select
> >
> >
> >
> > at
> >
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:406)
> >
> >at
> >
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:746)
> >
> >at
> > org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1274)
> >
> >at
> >
> org.apache.solr.handler.component.HttpShardHandler.request(HttpShardHandler.java:238)
> >
> >at
> >
> org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:199)
> >
> >at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >
> >at
> > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> >
> >at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >
> >at
> >
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:181)
> >
> >at
> >
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> >
> >at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> >
> >at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> >
> >... 1 more
> >
> > Caused by: java.util.concurrent.TimeoutException
> >
> >at
> >
> org.eclipse.jetty.client.util.InputStreamResponseListener.get(InputStreamResponseListener.java:216)
> >
> >at
> >
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:397)
> >
> >... 12 more
> >
> >
> >
> > + o.a.s.s.HttpSolrCall invalid return code: -1
> >
> > + o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp:
> > 1592803662746 , received timestamp: 1592803796152 , TTL: 12
> >
> > + o.a.s.s.PKIAuthenticationPlugin Decryption failed , key must be wrong
> =>
> > java.security.InvalidKeyException: No installed provider supports this
> key:
> > (null)
> >
> > + o.a.s.u.ErrorReportingConcurrentUpdateSolrClient Error when calling
> > SolrCmdDistributor$Req: cmd=delete{,commitWithin=-1}; node=ForwardNode:
> > http://server6:8983/solr/mycollection_shard3_replica_n5/ to
> > http://server6:8983/solr/mycollection_shard3_replica_n5/ =>
> > java.util.concurrent.TimeoutException
> >
> > + o.a.s.s.HttpSolrCall
> >
> null:org.apache.solr.update.processor.DistributedUpdateProcessor$DistributedUpdatesAsyncException:
> > Async exception during distributed update: null
> >
> >
> >
> > Server 2:
> >
> > + Max requests queued per destination 3000 exceede
Re: Almost nodes in Solrcloud dead suddently
The problem reoccurs repeatly in recent days.
To day i tried dump heap and thread. Only dumping thread, heap can not because
solr instance was hang.Almost thread was blocked.
On Tuesday, June 23, 2020, 10:42:36 PM GMT+7, Tran Van Hoan
wrote:
I checked node exporter metrics and saw network no problem
On Tuesday, June 23, 2020, 8:37:41 PM GMT+7, Tran Van Hoan
wrote:
I check node exporter, no problem with OS, hardware and network.I attached
images about solr metrics 7 days and 12h.
On Tuesday, June 23, 2020, 2:23:05 PM GMT+7, Dario Rigolin
wrote:
What about a network issue?
Il giorno mar 23 giu 2020 alle ore 01:37 Tran Van Hoan
ha scritto:
>
> dear all,
>
> I have a solr cloud 8.2.0 with 6 instance per 6 server (64G RAM), each
> instance has xmx = xms = 30G.
>
> Today almost nodes in the solrcloud were dead 2 times from 8:00AM (5/6
> nodes were down) and 1:00PM (2/6 nodes were down). yesterday, One node
> were down. almost metrics didn't increase too much except threads.
>
> Performance in one week ago:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> performace 12h ago:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> I go to the admin UI, some node dead some node too long to response. When
> checking logfile, they generate too much (log level warning), here are logs
> which appears in the solr cloud:
>
> Log before server 4 and 6 down
>
> - Server 4 before it dead:
>
> + o.a.s.h.RequestHandlerBase java.io.IOException:
> java.util.concurrent.TimeoutException: Idle timeout expired: 12/12
> ms
>
> +org.apache.solr.client.solrj.SolrServerException: Timeout occured while
> waiting response from server at:
> http://server6:8983/solr/mycollection_shard3_replica_n5/select
>
>
>
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:406)
>
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:746)
>
> at
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1274)
>
> at
> org.apache.solr.handler.component.HttpShardHandler.request(HttpShardHandler.java:238)
>
> at
> org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:199)
>
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:181)
>
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
> ... 1 more
>
> Caused by: java.util.concurrent.TimeoutException
>
> at
> org.eclipse.jetty.client.util.InputStreamResponseListener.get(InputStreamResponseListener.java:216)
>
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:397)
>
> ... 12 more
>
>
>
> + o.a.s.s.HttpSolrCall invalid return code: -1
>
> + o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp:
> 1592803662746 , received timestamp: 1592803796152 , TTL: 12
>
> + o.a.s.s.PKIAuthenticationPlugin Decryption failed , key must be wrong =>
> java.security.InvalidKeyException: No installed provider supports this key:
> (null)
>
> + o.a.s.u.ErrorReportingConcurrentUpdateSolrClient Error when calling
> SolrCmdDistributor$Req: cmd=delete{,commitWithin=-1}; node=ForwardNode:
> http://server6:8983/solr/mycollection_shard3_replica_n5/ to
> http://server6:8983/solr/mycollection_shard3_replica_n5/ =>
> java.util.concurrent.TimeoutException
>
> + o.a.s.s.HttpSolrCall
> null:org.apache.solr.update.processor.DistributedUpdateProcessor$DistributedUpdatesAsyncException:
> Async exception during distributed update: null
>
>
>
> Server 2:
>
> + Max requests queued per destination 3000 exceeded for
> HttpDestination[http://server4:8983
> ]@7d7ec93c,queue=3000,pool=MultiplexConnectionPool@73b938e3
> [c=4/4,b=4,m=0,i=0]
>
> + Max requests queued per destination 3000 exceeded for
> HttpDestination[http://server5:8983
> ]@7d7ec93c,queue=3000,pool=MultiplexConnectionPool@73b938e3
> [c=4/4,b=4,m=0,i=0]
>
>
>
> + Timeout occured while waiting response from server at:
> http://server4:8983/solr/mycollection_shard6_replica_n23/select
>
> + Timeout occured while waiting response from server at:
> http://server6:8983/solr/mycollection_shard2_replica_n15/select
>
> + o.a.s.s.HttpSolrCall null:org.apache.solr.common.SolrException:
> org.apache.solr.client.solrj.SolrServerException: IOExcepti
Re: Questions about Solr Search
Short answer: no Neither Solr nor ElasticSearch have such capabilities out of the box. Solr does have a plugin infrastructure that enables you to provide better tokenization based on language rules, and some are better than others. I saw for example integration of openNLP here: https://lucene.apache.org/solr/guide/7_3/language-analysis.html but that requires additional data to provide language rules, but not a lot of languages have been tackled (http://opennlp.sourceforge.net/models-1.5/). There are of course more general solutions like provided in the first link, but the tokenization are a bit "rough" and aggressive (that is why it is so fast), delivering tokens that do not exist (debugging shows you that). Anyway: do not overdo it. There is no way you can beat large sized company like Google. Language support is more than a set of rules to apply. More important is this: make sure Google can decently index your webpages. More than 90% of your users reach your website through Google, so do not invest too much into this. On 2 Jul 2020, at 16:19, Gautam K mailto:gka...@gmail.com>> wrote: Dear Team, Hope you all are doing well. Can you please help with the following question? We are using Solr search in our Organisation and now checking whether Solr provides search capabilities like Google Enterprise search(Google Knowledge Graph Search). 1, Does Solr Search provide Voice Search like Google? 2. Does Solar Search provide NLP Search(Natural Language Processing)? 3. Does Solr have all the capabilities which Google Knowledge Graph provides like below? - Getting a ranked list of the most notable entities that match certain criteria. - Predictively completing entities in a search box. - Annotating/organizing content using the Knowledge Graph entities. *Your help will be appreciated highly.* Many thanks Gautam Kanaujia India
Re: Time-out errors while indexing (Solr 7.7.1)
You need more shards. And, I’m pretty certain, more hardware. You say you have 13 billion documents and 6 shards. Solr/Lucene has an absolute upper limit of 2B (2^31) docs per shard. I don’t quite know how you’re running at all unless that 13B is a round number. If you keep adding documents, your installation will shortly, at best, stop accepting new documents for indexing. At worst you’ll start seeing weird errors and possibly corrupt indexes and have to re-index everything from scratch. You’ve backed yourself in to a pretty tight corner here. You either have to re-index to a properly-sized cluster or use SPLITSHARD. This latter will double the index-on-disk size (it creates two child indexes per replica and keeps the old one for safety’s sake that you have to clean up later). I strongly recommend you stop ingesting more data while you do this. You say you have 6 VMs with 2 nodes running on each. If those VMs are co-located with anything else, the physical hardware is going to be stressed. VMs themselves aren’t bad, but somewhere there’s physical hardware that runs it… In fact, I urge you to stop ingesting data immediately and address this issue. You have a cluster that’s mis-configured, and you must address that before Bad Things Happen. Best, Erick > On Jul 4, 2020, at 5:09 AM, Mad have wrote: > > Hi Eric, > > There are total 6 VM’s in Solr clusters and 2 nodes are running on each VM. > Total number of shards are 6 with 3 replicas. I can see the index size is > more than 220GB on each node for the collection where we are facing the > performance issue. > > The more documents we add to the collection the indexing become slow and I > also have same impression that the size of the collection is creating this > issue. Appreciate if you can suggests any solution on this. > > > Regards, > Madhava > Sent from my iPhone > >> On 3 Jul 2020, at 23:30, Erick Erickson wrote: >> >> Oops, I transposed that. If your index is a terabyte and your RAM is 128M, >> _that’s_ a red flag. >> >>> On Jul 3, 2020, at 5:53 PM, Erick Erickson wrote: >>> >>> You haven’t said how many _shards_ are present. Nor how many replicas of >>> the collection you’re hosting per physical machine. Nor how large the >>> indexes are on disk. Those are the numbers that count. The latter is >>> somewhat fuzzy, but if your aggregate index size on a machine with, say, >>> 128G of memory is a terabyte, that’s a red flag. >>> >>> Short form, though is yes. Subject to the questions above, this is what I’d >>> be looking at first. >>> >>> And, as I said, if you’ve been steadily increasing the total number of >>> documents, you’ll reach a tipping point sometime. >>> >>> Best, >>> Erick >>> > On Jul 3, 2020, at 5:32 PM, Mad have wrote: Hi Eric, The collection has almost 13billion documents with each document around 5kb size, all the columns around 150 are the indexed. Do you think that number of documents in the collection causing this issue. Appreciate your response. Regards, Madhava Sent from my iPhone > On 3 Jul 2020, at 12:42, Erick Erickson wrote: > > If you’re seeing low CPU utilization at the same time, you probably > just have too much data on too little hardware. Check your > swapping, how much of your I/O is just because Lucene can’t > hold all the parts of the index it needs in memory at once? Lucene > uses MMapDirectory to hold the index and you may well be > swapping, see: > > https://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html > > But my guess is that you’ve just reached a tipping point. You say: > > "From last 2-3 weeks we have been noticing either slow indexing or > timeout errors while indexing” > > So have you been continually adding more documents to your > collections for more than the 2-3 weeks? If so you may have just > put so much data on the same boxes that you’ve gone over > the capacity of your hardware. As Toke says, adding physical > memory for the OS to use to hold relevant parts of the index may > alleviate the problem (again, refer to Uwe’s article for why). > > All that said, if you’re going to keep adding document you need to > seriously think about adding new machines and moving some of > your replicas to them. > > Best, > Erick > >> On Jul 3, 2020, at 7:14 AM, Toke Eskildsen wrote: >> >>> On Thu, 2020-07-02 at 11:16 +, Kommu, Vinodh K. wrote: >>> We are performing QA performance testing on couple of collections >>> which holds 2 billion and 3.5 billion docs respectively. >> >> How many shards? >> >>> 1. Our performance team noticed that read operations are pretty >>> more than write operations like 100:1 ratio, is this expected during >>> indexing or solr nodes are doing any other operations lik
Re: unified highlighter performance in solr 8.5.1
I guess that's fair. Let's have hl.fragsizeIsMinimum=true as default. On 7/4/20, David Smiley wrote: > I doubt that WORD mode is impacted much by hl.fragsizeIsMinimum in terms of > quality of the highlight since there are vastly more breaks to pick from. > I think that setting is more useful in SENTENCE mode if you can stand the > perf hit. If you agree, then why not just let this one default to "true"? > > We agree on better documenting the perf trade-off. > > Thanks again for working on these settings, BTW. > > ~ David > > > On Fri, Jul 3, 2020 at 1:25 PM Nándor Mátravölgyi > wrote: > >> Since the issue seems to be affecting the highlighter differently >> based on which mode it is using, having different defaults for the >> modes could be explored. >> >> WORD may have the new defaults as it has little effect on performance >> and it creates nicer highlights. >> SENTENCE should have the defaults that produce reasonable performance. >> The docs could document this while also mentioning that the UH's >> performance is highly dependent on the underlying Java String/Text? >> Iterator. >> >> One can argue that having different defaults based on mode is >> confusing. In this case I think the defaults should be changed to have >> the SENTENCE mode perform better. Maybe the options for nice >> highlights with WORD mode could be put into the docs in this case as >> some form of an example. >> >> As long as I can use the UH with nicely aligned snippets in WORD mode >> I'm fine with any defaults. I explicitly set them in the config and in >> the queries most of the time anyways. >> >
Re: Time-out errors while indexing (Solr 7.7.1)
Hi Eric, There are total 6 VM’s in Solr clusters and 2 nodes are running on each VM. Total number of shards are 6 with 3 replicas. I can see the index size is more than 220GB on each node for the collection where we are facing the performance issue. The more documents we add to the collection the indexing become slow and I also have same impression that the size of the collection is creating this issue. Appreciate if you can suggests any solution on this. Regards, Madhava Sent from my iPhone > On 3 Jul 2020, at 23:30, Erick Erickson wrote: > > Oops, I transposed that. If your index is a terabyte and your RAM is 128M, > _that’s_ a red flag. > >> On Jul 3, 2020, at 5:53 PM, Erick Erickson wrote: >> >> You haven’t said how many _shards_ are present. Nor how many replicas of the >> collection you’re hosting per physical machine. Nor how large the indexes >> are on disk. Those are the numbers that count. The latter is somewhat fuzzy, >> but if your aggregate index size on a machine with, say, 128G of memory is a >> terabyte, that’s a red flag. >> >> Short form, though is yes. Subject to the questions above, this is what I’d >> be looking at first. >> >> And, as I said, if you’ve been steadily increasing the total number of >> documents, you’ll reach a tipping point sometime. >> >> Best, >> Erick >> On Jul 3, 2020, at 5:32 PM, Mad have wrote: >>> >>> Hi Eric, >>> >>> The collection has almost 13billion documents with each document around 5kb >>> size, all the columns around 150 are the indexed. Do you think that number >>> of documents in the collection causing this issue. Appreciate your response. >>> >>> Regards, >>> Madhava >>> >>> Sent from my iPhone >>> On 3 Jul 2020, at 12:42, Erick Erickson wrote: If you’re seeing low CPU utilization at the same time, you probably just have too much data on too little hardware. Check your swapping, how much of your I/O is just because Lucene can’t hold all the parts of the index it needs in memory at once? Lucene uses MMapDirectory to hold the index and you may well be swapping, see: https://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html But my guess is that you’ve just reached a tipping point. You say: "From last 2-3 weeks we have been noticing either slow indexing or timeout errors while indexing” So have you been continually adding more documents to your collections for more than the 2-3 weeks? If so you may have just put so much data on the same boxes that you’ve gone over the capacity of your hardware. As Toke says, adding physical memory for the OS to use to hold relevant parts of the index may alleviate the problem (again, refer to Uwe’s article for why). All that said, if you’re going to keep adding document you need to seriously think about adding new machines and moving some of your replicas to them. Best, Erick > On Jul 3, 2020, at 7:14 AM, Toke Eskildsen wrote: > >> On Thu, 2020-07-02 at 11:16 +, Kommu, Vinodh K. wrote: >> We are performing QA performance testing on couple of collections >> which holds 2 billion and 3.5 billion docs respectively. > > How many shards? > >> 1. Our performance team noticed that read operations are pretty >> more than write operations like 100:1 ratio, is this expected during >> indexing or solr nodes are doing any other operations like syncing? > > Are you saying that there are 100 times more read operations when you > are indexing? That does not sound too unrealistic as the disk cache > might be filled with the data that the writers are flushing. > > In that case, more RAM would help. Okay, more RAM nearly always helps, > but such massive difference in IO-utilization does indicate that you > are starved for cache. > > I noticed you have at least 18 replicas. That's a lot. Just to sanity > check: How many replicas are each physical box handling? If they are > sharing resources, fewer replicas would probably be better. > >> 3. Our client timeout is set to 2mins, can they increase further >> more? Would that help or create any other problems? > > It does not hurt the server to increase the client timeout as the > initiated query will keep running until it is finished, independent of > whether or not there is a client to receive the result. > > If you want a better max time for query processing, you should look at > > https://lucene.apache.org/solr/guide/7_7/common-query-parameters.html#timeallowed-parameter > but due to its inherent limitations it might not help in your > situation. > >> 4. When we created an empty collection and loaded same data file, >> it loaded fine without any issues so having more documents in a >> collection would
***URGENT***Re: Questions about Solr Search
Since it's a bit of an urgent request so if could please help me on this by today it will be highly appreciated. Thanks & Regards, Gautam Kanaujia On Thu, Jul 2, 2020 at 7:49 PM Gautam K wrote: > Dear Team, > > Hope you all are doing well. > > Can you please help with the following question? We are using Solr search > in our Organisation and now checking whether Solr provides search > capabilities like Google Enterprise search(Google Knowledge Graph Search). > > 1, Does Solr Search provide Voice Search like Google? > 2. Does Solar Search provide NLP Search(Natural Language Processing)? > 3. Does Solr have all the capabilities which Google Knowledge Graph > provides like below? > > >- Getting a ranked list of the most notable entities that match >certain criteria. >- Predictively completing entities in a search box. >- Annotating/organizing content using the Knowledge Graph entities. > > > *Your help will be appreciated highly.* > > Many thanks > Gautam Kanaujia > India >
Questions about Solr Search
Dear Team, Hope you all are doing well. Can you please help with the following question? We are using Solr search in our Organisation and now checking whether Solr provides search capabilities like Google Enterprise search(Google Knowledge Graph Search). 1, Does Solr Search provide Voice Search like Google? 2. Does Solar Search provide NLP Search(Natural Language Processing)? 3. Does Solr have all the capabilities which Google Knowledge Graph provides like below? - Getting a ranked list of the most notable entities that match certain criteria. - Predictively completing entities in a search box. - Annotating/organizing content using the Knowledge Graph entities. *Your help will be appreciated highly.* Many thanks Gautam Kanaujia India
