Re: Streaming Expression joins not returning all results
We likely have the same laptop :-)
There must be something weird with my schema or usage but even if I had 10x
the throughput I have now, throwing around that many docs for a single join
isn't conducive to desired latency, concurrent requests, network bandwidth,
etc. I feel like I'm not using the tool properly so I'll do some more
thinking.
Really enjoying the work you're doing!
On Mon, May 16, 2016 at 8:09 AM, Joel Bernstein <joels...@gmail.com> wrote:
> So, with that setup you're getting around 150,000 docs per second
> throughput. On my laptop with a similar query I was able to stream around
> 650,000 docs per second. I have an SSD and 16 Gigs of RAM. Also I did lots
> of experimenting with different numbers of workers and tested after warming
> the partition filters. I was also able to maintain that speed exporting
> larger result sets in the 25,000,000 doc range.
>
> Based on our discussion, it's clear that there needs to be documentation
> about how to build and scale streaming architectures with Solr. I'm working
> on that now. The work progress is here:
>
> https://cwiki.apache.org/confluence/display/solr/Scaling+with+Worker+Collections
>
> As I work on the documentation I'll revalidate the performance numbers I
> was seeing when I did the performance testing several months ago.
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Mon, May 16, 2016 at 10:51 AM, Ryan Cutter <ryancut...@gmail.com>
> wrote:
>
> > Thanks for all this info, Joel. I found if I artificially limit the
> > triples stream to 3M and use the /export handler with only 2 workers, I
> can
> > get results in @ 20 seconds and Solr doesn't tip over. That seems to be
> > the best config for this local/single instance.
> >
> > It's also clear I'm not using streaming expressions optimally so I need
> to
> > do some more thinking! I don't want to stream all 26M triples (much less
> > billions of docs) just for a simple join in which I expect a couple
> hundred
> > results. I wanted to see if I could directly port a SQL join into this
> > framework using normalized Solr docs and single streaming expression.
> I'll
> > do some more tinkering.
> >
> > Thanks again, Ryan
> >
> > On Sun, May 15, 2016 at 4:14 PM, Joel Bernstein <joels...@gmail.com>
> > wrote:
> >
> > > One other thing to keep in is how the partitioning is done when you add
> > the
> > > partitionKeys.
> > >
> > > Partitioning is done using the HashQParserPlugin, which builds a filter
> > for
> > > each worker. Under the covers this is using the normal filter query
> > > mechanism. So after the filters are built and cached they are
> effectively
> > > free from a performance standpoint. But on the first run they need to
> be
> > > built and they need to be rebuilt after each commit. These means
> several
> > > things:
> > >
> > > 1) If you have 8 workers then 8 filters need to be computed. The
> workers
> > > call down to the shards in parallel so the filters will build in
> > parallel.
> > > But this can take time and the larger the index, the more time it
> takes.
> > >
> > > 2) Like all filters, the partitioning filters can be pre-computed using
> > > warming queries. You can check the logs and look for the {!hash ...}
> > filter
> > > queries to see the syntax. But basically you would need a warming query
> > for
> > > each worker ID.
> > >
> > > 3) If you don't pre-warm the partitioning filters then there will be a
> > > performance penalty the first time they are computed. The next query
> will
> > > be much faster.
> > >
> > > 4) This is another area where having more shards helps with
> performance,
> > > because having fewer documents per shard, means faster times building
> the
> > > partition filters.
> > >
> > > In the future we'll switch to segment level partitioning filters, so
> that
> > > following each commit only the new segments need to be built. But this
> is
> > > still on the TODO list.
> > >
> > >
> > > Joel Bernstein
> > > http://joelsolr.blogspot.com/
> > >
> > > On Sun, May 15, 2016 at 5:38 PM, Joel Bernstein <joels...@gmail.com>
> > > wrote:
> > >
> > > > Ah, you also used 4 shards. That means with 8 workers there were 32
> > > > concurrent queries against the /select handler each requesting
> 100,000
> > > > rows. That's a really heavy load!
> > > >
> > > > You can sti
Re: Streaming Expression joins not returning all results
ng the same *:* search() against the /export handler in > >> parallel() gradually increasing the number of workers. Time how long it > >> takes as you add workers and watch the load it places on the server. > >> Eventually you'll max out your performance. > >> > >> > >> Then you'll start to get an idea of how fast a single node can sort and > >> export data. > >> > >> > >> > >> > >> Joel Bernstein > >> http://joelsolr.blogspot.com/ > >> > >> On Sat, May 14, 2016 at 4:14 PM, Ryan Cutter <ryancut...@gmail.com> > >> wrote: > >> > >>> Hello, I'm running Solr on my laptop with -Xmx8g and gave each > >>> collection 4 > >>> shards and 2 replicas. > >>> > >>> Even grabbing 100k triple documents (like the following) is taking 20 > >>> seconds to complete and prone to fall over. I could try this in a > proper > >>> cluster with multiple hosts and more sharding, etc. I just thought I > was > >>> tinkering with a small enough data set to use locally. > >>> > >>> parallel( > >>> triple, > >>> innerJoin( > >>> search(triple, q=*:*, fl="subject_id,type_id", sort="type_id > asc", > >>> partitionKeys="type_id", rows="10"), > >>> search(triple_type, q=*:*, fl="triple_type_id", > >>> sort="triple_type_id > >>> asc", partitionKeys="triple_type_id", qt="/export"), > >>> on="type_id=triple_type_id" > >>> ), > >>> sort="subject_id asc", > >>> workers="8") > >>> > >>> > >>> When Solr does crash, it's leaving messages like this. > >>> > >>> ERROR - 2016-05-14 20:00:53.892; [c:triple s:shard3 r:core_node2 > >>> x:triple_shard3_replica2] org.apache.solr.common.SolrException; > >>> null:java.io.IOException: java.util.concurrent.TimeoutException: Idle > >>> timeout expired: 50001/5 ms > >>> > >>> at > >>> > >>> > org.eclipse.jetty.util.SharedBlockingCallback$Blocker.block(SharedBlockingCallback.java:226) > >>> > >>> at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:164) > >>> > >>> at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:530) > >>> > >>> at > >>> > >>> > org.apache.solr.response.QueryResponseWriterUtil$1.write(QueryResponseWriterUtil.java:54) > >>> > >>> at java.io.OutputStream.write(OutputStream.java:116) > >>> > >>> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) > >>> > >>> at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282) > >>> > >>> at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125) > >>> > >>> at java.io.OutputStreamWriter.write(OutputStreamWriter.java:207) > >>> > >>> at org.apache.solr.util.FastWriter.flush(FastWriter.java:140) > >>> > >>> at org.apache.solr.util.FastWriter.write(FastWriter.java:54) > >>> > >>> at > >>> > >>> > org.apache.solr.response.JSONWriter.writeMapCloser(JSONResponseWriter.java:420) > >>> > >>> at > >>> > >>> > org.apache.solr.response.JSONWriter.writeSolrDocument(JSONResponseWriter.java:364) > >>> > >>> at > >>> > >>> > org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:246) > >>> > >>> at > >>> > >>> > org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:150) > >>> > >>> at > >>> > >>> > org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183) > >>> > >>> On Fri, May 13, 2016 at 5:50 PM, Joel Bernstein <joels...@gmail.com> > >>> wrote: > >>> > >>> > Also the hashJoin is going to read the entire entity table into > >>> memory. If > >>> > that's a large index that could be using lots of memory. > >>> > > >>> > 25 million docs should be ok to /export from one node, as long as you > >>> have > >>> > enough memory to load the docValues for the fields for sorting and
Re: Streaming Expression joins not returning all results
Hello, I'm running Solr on my laptop with -Xmx8g and gave each collection 4 shards and 2 replicas. Even grabbing 100k triple documents (like the following) is taking 20 seconds to complete and prone to fall over. I could try this in a proper cluster with multiple hosts and more sharding, etc. I just thought I was tinkering with a small enough data set to use locally. parallel( triple, innerJoin( search(triple, q=*:*, fl="subject_id,type_id", sort="type_id asc", partitionKeys="type_id", rows="10"), search(triple_type, q=*:*, fl="triple_type_id", sort="triple_type_id asc", partitionKeys="triple_type_id", qt="/export"), on="type_id=triple_type_id" ), sort="subject_id asc", workers="8") When Solr does crash, it's leaving messages like this. ERROR - 2016-05-14 20:00:53.892; [c:triple s:shard3 r:core_node2 x:triple_shard3_replica2] org.apache.solr.common.SolrException; null:java.io.IOException: java.util.concurrent.TimeoutException: Idle timeout expired: 50001/5 ms at org.eclipse.jetty.util.SharedBlockingCallback$Blocker.block(SharedBlockingCallback.java:226) at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:164) at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:530) at org.apache.solr.response.QueryResponseWriterUtil$1.write(QueryResponseWriterUtil.java:54) at java.io.OutputStream.write(OutputStream.java:116) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282) at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:207) at org.apache.solr.util.FastWriter.flush(FastWriter.java:140) at org.apache.solr.util.FastWriter.write(FastWriter.java:54) at org.apache.solr.response.JSONWriter.writeMapCloser(JSONResponseWriter.java:420) at org.apache.solr.response.JSONWriter.writeSolrDocument(JSONResponseWriter.java:364) at org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:246) at org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:150) at org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183) On Fri, May 13, 2016 at 5:50 PM, Joel Bernstein <joels...@gmail.com> wrote: > Also the hashJoin is going to read the entire entity table into memory. If > that's a large index that could be using lots of memory. > > 25 million docs should be ok to /export from one node, as long as you have > enough memory to load the docValues for the fields for sorting and > exporting. > > Breaking down the query into it's parts will show where the issue is. Also > adding more heap might give you enough memory. > > In my testing the max docs per second I've seen the /export handler push > from a single node is 650,000. In order to get 650,000 docs per second on > one node you have to partition the stream with workers. In my testing it > took 8 workers hitting one node to achieve the 650,000 docs per second. > > But the numbers get big as the cluster grows. With 20 shards and 4 replicas > and 32 workers, you could export 52,000,000 docs per-second. With 40 > shards, 5 replicas and 40 workers you could export 130,000,000 docs per > second. > > So with large clusters you could do very large distributed joins with > sub-second performance. > > > > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Fri, May 13, 2016 at 8:11 PM, Ryan Cutter <ryancut...@gmail.com> wrote: > > > Thanks very much for the advice. Yes, I'm running in a very basic single > > shard environment. I thought that 25M docs was small enough to not > require > > anything special but I will try scaling like you suggest and let you know > > what happens. > > > > Cheers, Ryan > > > > On Fri, May 13, 2016 at 4:53 PM, Joel Bernstein <joels...@gmail.com> > > wrote: > > > > > I would try breaking down the second query to see when the problems > > occur. > > > > > > 1) Start with just a single *:* search from one of the collections. > > > 2) Then test the innerJoin. The innerJoin won't take much memory as > it's > > a > > > streaming merge join. > > > 3) Then try the full thing. > > > > > > If you're running a large join like this all on one host then you might > > not > > > have enough memory for the docValues and the two joins. In general > > > streaming is designed to scale by adding servers. It scales 3 ways: > > > > > > 1) Adding shards, splits up the index for more pushing power. > > > 2) Adding workers, partitions the streams and splits up the joi
Re: Streaming Expression joins not returning all results
Thanks very much for the advice. Yes, I'm running in a very basic single
shard environment. I thought that 25M docs was small enough to not require
anything special but I will try scaling like you suggest and let you know
what happens.
Cheers, Ryan
On Fri, May 13, 2016 at 4:53 PM, Joel Bernstein <joels...@gmail.com> wrote:
> I would try breaking down the second query to see when the problems occur.
>
> 1) Start with just a single *:* search from one of the collections.
> 2) Then test the innerJoin. The innerJoin won't take much memory as it's a
> streaming merge join.
> 3) Then try the full thing.
>
> If you're running a large join like this all on one host then you might not
> have enough memory for the docValues and the two joins. In general
> streaming is designed to scale by adding servers. It scales 3 ways:
>
> 1) Adding shards, splits up the index for more pushing power.
> 2) Adding workers, partitions the streams and splits up the join / merge
> work.
> 3) Adding replicas, when you have workers you will add pushing power by
> adding replicas. This is because workers will fetch partitions of the
> streams from across the entire cluster. So ALL replicas will be pushing at
> once.
>
> So, imagine a setup with 20 shards, 4 replicas, and 20 workers. You can
> perform massive joins quickly.
>
> But for you're scenario and available hardware you can experiment with
> different cluster sizes.
>
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Fri, May 13, 2016 at 7:27 PM, Ryan Cutter <ryancut...@gmail.com> wrote:
>
> > qt="/export" immediately fixed the query in Question #1. Sorry for
> missing
> > that in the docs!
> >
> > The second query (with /export) crashes the server so I was going to look
> > at parallelization if you think that's a good idea. It also seems unwise
> > to joining into 26M docs so maybe I can reconfigure the query to run
> along
> > a more happy path :-) The schema is very RDBMS-centric so maybe that
> just
> > won't ever work in this framework.
> >
> > Here's the log but it's not very helpful.
> >
> >
> > INFO - 2016-05-13 23:18:13.214; [c:triple s:shard1 r:core_node1
> > x:triple_shard1_replica1] org.apache.solr.core.SolrCore;
> > [triple_shard1_replica1] webapp=/solr path=/export
> >
> >
> params={q=*:*=false=triple_id,subject_id,type_id=type_id+asc=json=2.2}
> > hits=26305619 status=0 QTime=61
> >
> > INFO - 2016-05-13 23:18:13.747; [c:triple_type s:shard1 r:core_node1
> > x:triple_type_shard1_replica1] org.apache.solr.core.SolrCore;
> > [triple_type_shard1_replica1] webapp=/solr path=/export
> >
> >
> params={q=*:*=false=triple_type_id,triple_type_label=triple_type_id+asc=json=2.2}
> > hits=702 status=0 QTime=2
> >
> > INFO - 2016-05-13 23:18:48.504; [ ]
> > org.apache.solr.common.cloud.ConnectionManager; Watcher
> > org.apache.solr.common.cloud.ConnectionManager@6ad0f304
> > name:ZooKeeperConnection Watcher:localhost:9983 got event WatchedEvent
> > state:Disconnected type:None path:null path:null type:None
> >
> > INFO - 2016-05-13 23:18:48.504; [ ]
> > org.apache.solr.common.cloud.ConnectionManager; zkClient has disconnected
> >
> > ERROR - 2016-05-13 23:18:51.316; [c:triple s:shard1 r:core_node1
> > x:triple_shard1_replica1] org.apache.solr.common.SolrException;
> null:Early
> > Client Disconnect
> >
> > WARN - 2016-05-13 23:18:51.431; [ ]
> > org.apache.zookeeper.ClientCnxn$SendThread; Session 0x154ac66c81e0002 for
> > server localhost/0:0:0:0:0:0:0:1:9983, unexpected error, closing socket
> > connection and attempting reconnect
> >
> > java.io.IOException: Connection reset by peer
> >
> > at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> >
> > at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> >
> > at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> >
> > at sun.nio.ch.IOUtil.read(IOUtil.java:192)
> >
> > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> >
> > at
> >
> org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:68)
> >
> > at
> >
> >
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:366)
> >
> > at
> > org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)
> >
> > On Fri, May 13, 2016 at 3:09 PM, Joel Bernstein <joels...@gmail.com>
> > wrote:
> >
> > > A couple of other things:
> > >
> >
Re: Streaming Expression joins not returning all results
qt="/export" immediately fixed the query in Question #1. Sorry for missing
that in the docs!
The second query (with /export) crashes the server so I was going to look
at parallelization if you think that's a good idea. It also seems unwise
to joining into 26M docs so maybe I can reconfigure the query to run along
a more happy path :-) The schema is very RDBMS-centric so maybe that just
won't ever work in this framework.
Here's the log but it's not very helpful.
INFO - 2016-05-13 23:18:13.214; [c:triple s:shard1 r:core_node1
x:triple_shard1_replica1] org.apache.solr.core.SolrCore;
[triple_shard1_replica1] webapp=/solr path=/export
params={q=*:*=false=triple_id,subject_id,type_id=type_id+asc=json=2.2}
hits=26305619 status=0 QTime=61
INFO - 2016-05-13 23:18:13.747; [c:triple_type s:shard1 r:core_node1
x:triple_type_shard1_replica1] org.apache.solr.core.SolrCore;
[triple_type_shard1_replica1] webapp=/solr path=/export
params={q=*:*=false=triple_type_id,triple_type_label=triple_type_id+asc=json=2.2}
hits=702 status=0 QTime=2
INFO - 2016-05-13 23:18:48.504; [ ]
org.apache.solr.common.cloud.ConnectionManager; Watcher
org.apache.solr.common.cloud.ConnectionManager@6ad0f304
name:ZooKeeperConnection Watcher:localhost:9983 got event WatchedEvent
state:Disconnected type:None path:null path:null type:None
INFO - 2016-05-13 23:18:48.504; [ ]
org.apache.solr.common.cloud.ConnectionManager; zkClient has disconnected
ERROR - 2016-05-13 23:18:51.316; [c:triple s:shard1 r:core_node1
x:triple_shard1_replica1] org.apache.solr.common.SolrException; null:Early
Client Disconnect
WARN - 2016-05-13 23:18:51.431; [ ]
org.apache.zookeeper.ClientCnxn$SendThread; Session 0x154ac66c81e0002 for
server localhost/0:0:0:0:0:0:0:1:9983, unexpected error, closing socket
connection and attempting reconnect
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:192)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
at
org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:68)
at
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:366)
at
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)
On Fri, May 13, 2016 at 3:09 PM, Joel Bernstein <joels...@gmail.com> wrote:
> A couple of other things:
>
> 1) Your innerJoin can parallelized across workers to improve performance.
> Take a look at the docs on the parallel function for the details.
>
> 2) It looks like you might be doing graph operations with joins. You might
> to take a look at the gatherNodes function coming in 6.1:
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=62693238
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Fri, May 13, 2016 at 5:57 PM, Joel Bernstein <joels...@gmail.com>
> wrote:
>
> > When doing things that require all the results (like joins) you need to
> > specify the /export handler in the search function.
> >
> > qt="/export"
> >
> > The search function defaults to the /select handler which is designed to
> > return the top N results. The /export handler always returns all results
> > that match the query. Also keep in mind that the /export handler requires
> > that sort fields and fl fields have docValues set.
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Fri, May 13, 2016 at 5:36 PM, Ryan Cutter <ryancut...@gmail.com>
> wrote:
> >
> >> Question #1:
> >>
> >> triple_type collection has a few hundred docs and triple has 25M docs.
> >>
> >> When I search for a particular subject_id in triple which I know has 14
> >> results and do not pass in 'rows' params, it returns 0 results:
> >>
> >> innerJoin(
> >> search(triple, q=subject_id:1656521,
> >> fl="triple_id,subject_id,type_id",
> >> sort="type_id asc"),
> >> search(triple_type, q=*:*, fl="triple_type_id,triple_type_label",
> >> sort="triple_type_id asc"),
> >> on="type_id=triple_type_id"
> >> )
> >>
> >> When I do the same search with rows=1, it returns 14 results:
> >>
> >> innerJoin(
> >> search(triple, q=subject_id:1656521,
> >> fl="triple_id,subject_id,type_id",
> >> sort="type_id asc", rows=1),
> >> search(triple_type, q=*:*, fl="triple_type_id,triple_type_label",
> >> sort="triple_type
Streaming Expression joins not returning all results
Question #1: triple_type collection has a few hundred docs and triple has 25M docs. When I search for a particular subject_id in triple which I know has 14 results and do not pass in 'rows' params, it returns 0 results: innerJoin( search(triple, q=subject_id:1656521, fl="triple_id,subject_id,type_id", sort="type_id asc"), search(triple_type, q=*:*, fl="triple_type_id,triple_type_label", sort="triple_type_id asc"), on="type_id=triple_type_id" ) When I do the same search with rows=1, it returns 14 results: innerJoin( search(triple, q=subject_id:1656521, fl="triple_id,subject_id,type_id", sort="type_id asc", rows=1), search(triple_type, q=*:*, fl="triple_type_id,triple_type_label", sort="triple_type_id asc", rows=1), on="type_id=triple_type_id" ) Am I doing this right? Is there a magic number to pass into rows which says "give me all the results which match this query"? Question #2: Perhaps related to the first question but I want to run the innerJoin() without the subject_id - rather have it use the results of another query. But this does not return any results. I'm saying "search for this entity based on id then use that result's entity_id as the subject_id to look through the triple/triple_type collections: hashJoin( innerJoin( search(triple, q=*:*, fl="triple_id,subject_id,type_id", sort="type_id asc"), search(triple_type, q=*:*, fl="triple_type_id,triple_type_label", sort="triple_type_id asc"), on="type_id=triple_type_id" ), hashed=search(entity, q=id:"urn:sid:entity:455dfa1aa27eedad21ac2115797c1580bb3b3b4e", fl="entity_id,entity_label", sort="entity_id asc"), on="subject_id=entity_id" ) Am I using doing this hashJoin right? Thanks very much, Ryan
Re: Streaming expressions join operations
Hi Joel, I wiped my repo and started fresh with the hope of documenting my steps and producing a stacktrace for you - of course, this time innerJoin() works fine. :-) I must have gotten something sideways the first time. Thanks for your time. I look forward to diving into this really cool feature. I really feel like this is a game changer for many people. - Ryan On Tue, May 10, 2016 at 6:54 AM, Joel Bernstein <joels...@gmail.com> wrote: > The block of code the NPE is coming from is where the collection nodes are > being gathered for the query. So this points to some issue with the cloud > setup or the query. > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Tue, May 10, 2016 at 9:52 AM, Joel Bernstein <joels...@gmail.com> > wrote: > > > Can you post the entire stack trace? I'd like to see what line the NPE is > > coming from. The line you pasted in is coming from the wrapper exception > I > > believe. > > > > Joel Bernstein > > http://joelsolr.blogspot.com/ > > > > On Tue, May 10, 2016 at 12:30 AM, Ryan Cutter <ryancut...@gmail.com> > > wrote: > > > >> Yes, the people collection has the personId and pets has ownerId, as > >> described. > >> On May 9, 2016 8:55 PM, "Joel Bernstein" <joels...@gmail.com> wrote: > >> > >> > The example is using two collections: people and pets. So these > >> collections > >> > would need to be present for the join expression to work. > >> > > >> > Joel Bernstein > >> > http://joelsolr.blogspot.com/ > >> > > >> > On Mon, May 9, 2016 at 10:43 PM, Ryan Cutter <ryancut...@gmail.com> > >> wrote: > >> > > >> > > Thanks Joel, I added the personId and ownerId fields before > ingested a > >> > > little data. I made them to be stored=true/multiValue=false/longs > >> (and > >> > > strings, later). Is additional schema required? > >> > > > >> > > On Mon, May 9, 2016 at 6:45 PM, Joel Bernstein <joels...@gmail.com> > >> > wrote: > >> > > > >> > > > Hi, > >> > > > > >> > > > The example in the cwiki would require setting up the people and > >> pets > >> > > > collections. Unless I'm mistaken this won't work with the out of > the > >> > box > >> > > > schemas. So you'll need to setup some test schemas to get started. > >> > > Although > >> > > > having out of the box streaming schemas is a great idea. > >> > > > > >> > > > Joel Bernstein > >> > > > http://joelsolr.blogspot.com/ > >> > > > > >> > > > On Mon, May 9, 2016 at 9:22 PM, Ryan Cutter <ryancut...@gmail.com > > > >> > > wrote: > >> > > > > >> > > > > Hello, I'm checking out the cool stream join operations in Solr > >> 6.0 > >> > but > >> > > > > can't seem to the example listed on the wiki to work: > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > https://cwiki.apache.org/confluence/display/solr/Streaming+Expressions#StreamingExpressions-innerJoin > >> > > > > > >> > > > > innerJoin( > >> > > > > search(people, q=*:*, fl="personId,name", sort="personId > asc"), > >> > > > > search(pets, q=type:cat, fl="ownerId,petName", sort="ownerId > >> asc"), > >> > > > > on="personId=ownerId" > >> > > > > ) > >> > > > > > >> > > > > ERROR - 2016-05-09 21:42:43.497; [c:pets s:shard1 r:core_node1 > >> > > > > x:pets_shard1_replica1] org.apache.solr.common.SolrException; > >> > > > > java.io.IOException: java.lang.NullPointerException > >> > > > > > >> > > > > at > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > org.apache.solr.client.solrj.io.stream.CloudSolrStream.constructStreams(CloudSolrStream.java:339) > >> > > > > > >> > > > > 1. Joel Bernstein pointed me at SOLR-9058. Is this the likely > >> bug? > >> > > > > 2. What kind of field should personId and ownerId be? long, > >> string, > >> > > > > something else? > >> > > > > 3. Does someone have an example schema or dataset that show off > >> these > >> > > > > joins? If not, it's something I could work on for future souls. > >> > > > > > >> > > > > Thanks! Ryan > >> > > > > > >> > > > > >> > > > >> > > >> > > > > >
Re: Streaming expressions join operations
Yes, the people collection has the personId and pets has ownerId, as described. On May 9, 2016 8:55 PM, "Joel Bernstein" <joels...@gmail.com> wrote: > The example is using two collections: people and pets. So these collections > would need to be present for the join expression to work. > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Mon, May 9, 2016 at 10:43 PM, Ryan Cutter <ryancut...@gmail.com> wrote: > > > Thanks Joel, I added the personId and ownerId fields before ingested a > > little data. I made them to be stored=true/multiValue=false/longs (and > > strings, later). Is additional schema required? > > > > On Mon, May 9, 2016 at 6:45 PM, Joel Bernstein <joels...@gmail.com> > wrote: > > > > > Hi, > > > > > > The example in the cwiki would require setting up the people and pets > > > collections. Unless I'm mistaken this won't work with the out of the > box > > > schemas. So you'll need to setup some test schemas to get started. > > Although > > > having out of the box streaming schemas is a great idea. > > > > > > Joel Bernstein > > > http://joelsolr.blogspot.com/ > > > > > > On Mon, May 9, 2016 at 9:22 PM, Ryan Cutter <ryancut...@gmail.com> > > wrote: > > > > > > > Hello, I'm checking out the cool stream join operations in Solr 6.0 > but > > > > can't seem to the example listed on the wiki to work: > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/solr/Streaming+Expressions#StreamingExpressions-innerJoin > > > > > > > > innerJoin( > > > > search(people, q=*:*, fl="personId,name", sort="personId asc"), > > > > search(pets, q=type:cat, fl="ownerId,petName", sort="ownerId asc"), > > > > on="personId=ownerId" > > > > ) > > > > > > > > ERROR - 2016-05-09 21:42:43.497; [c:pets s:shard1 r:core_node1 > > > > x:pets_shard1_replica1] org.apache.solr.common.SolrException; > > > > java.io.IOException: java.lang.NullPointerException > > > > > > > > at > > > > > > > > > > > > > > org.apache.solr.client.solrj.io.stream.CloudSolrStream.constructStreams(CloudSolrStream.java:339) > > > > > > > > 1. Joel Bernstein pointed me at SOLR-9058. Is this the likely bug? > > > > 2. What kind of field should personId and ownerId be? long, string, > > > > something else? > > > > 3. Does someone have an example schema or dataset that show off these > > > > joins? If not, it's something I could work on for future souls. > > > > > > > > Thanks! Ryan > > > > > > > > > >
Re: Streaming expressions join operations
Thanks Joel, I added the personId and ownerId fields before ingested a little data. I made them to be stored=true/multiValue=false/longs (and strings, later). Is additional schema required? On Mon, May 9, 2016 at 6:45 PM, Joel Bernstein <joels...@gmail.com> wrote: > Hi, > > The example in the cwiki would require setting up the people and pets > collections. Unless I'm mistaken this won't work with the out of the box > schemas. So you'll need to setup some test schemas to get started. Although > having out of the box streaming schemas is a great idea. > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Mon, May 9, 2016 at 9:22 PM, Ryan Cutter <ryancut...@gmail.com> wrote: > > > Hello, I'm checking out the cool stream join operations in Solr 6.0 but > > can't seem to the example listed on the wiki to work: > > > > > > > https://cwiki.apache.org/confluence/display/solr/Streaming+Expressions#StreamingExpressions-innerJoin > > > > innerJoin( > > search(people, q=*:*, fl="personId,name", sort="personId asc"), > > search(pets, q=type:cat, fl="ownerId,petName", sort="ownerId asc"), > > on="personId=ownerId" > > ) > > > > ERROR - 2016-05-09 21:42:43.497; [c:pets s:shard1 r:core_node1 > > x:pets_shard1_replica1] org.apache.solr.common.SolrException; > > java.io.IOException: java.lang.NullPointerException > > > > at > > > > > org.apache.solr.client.solrj.io.stream.CloudSolrStream.constructStreams(CloudSolrStream.java:339) > > > > 1. Joel Bernstein pointed me at SOLR-9058. Is this the likely bug? > > 2. What kind of field should personId and ownerId be? long, string, > > something else? > > 3. Does someone have an example schema or dataset that show off these > > joins? If not, it's something I could work on for future souls. > > > > Thanks! Ryan > > >
Streaming expressions join operations
Hello, I'm checking out the cool stream join operations in Solr 6.0 but can't seem to the example listed on the wiki to work: https://cwiki.apache.org/confluence/display/solr/Streaming+Expressions#StreamingExpressions-innerJoin innerJoin( search(people, q=*:*, fl="personId,name", sort="personId asc"), search(pets, q=type:cat, fl="ownerId,petName", sort="ownerId asc"), on="personId=ownerId" ) ERROR - 2016-05-09 21:42:43.497; [c:pets s:shard1 r:core_node1 x:pets_shard1_replica1] org.apache.solr.common.SolrException; java.io.IOException: java.lang.NullPointerException at org.apache.solr.client.solrj.io.stream.CloudSolrStream.constructStreams(CloudSolrStream.java:339) 1. Joel Bernstein pointed me at SOLR-9058. Is this the likely bug? 2. What kind of field should personId and ownerId be? long, string, something else? 3. Does someone have an example schema or dataset that show off these joins? If not, it's something I could work on for future souls. Thanks! Ryan
Re: SolrCloud delete by query performance
GC is operating the way I think it should but I am lacking memory. I am just surprised because indexing is performing fine (documents going in) but deletions are really bad (documents coming out). Is it possible these deletes are hitting many segments, each of which I assume must be re-built? And if there isn't much slack memory laying around to begin with, there's a bunch of contention/swap? Thanks Shawn! On Wed, May 20, 2015 at 4:50 PM, Shawn Heisey apa...@elyograg.org wrote: On 5/20/2015 5:41 PM, Ryan Cutter wrote: I have a collection with 1 billion documents and I want to delete 500 of them. The collection has a dozen shards and a couple replicas. Using Solr 4.4. Sent the delete query via HTTP: http://hostname:8983/solr/my_collection/update?stream.body= deletequerysource:foo/query/delete Took a couple minutes and several replicas got knocked into Recovery mode. They eventually came back and the desired docs were deleted but the cluster wasn't thrilled (high load, etc). Is this expected behavior? Is there a better way to delete documents that I'm missing? That's the correct way to do the delete. Before you'll see the change, a commit must happen in one way or another. Hopefully you already knew that. I believe that your setup has some performance issues that are making it very slow and knocking out your Solr nodes temporarily. The most common root problems with SolrCloud and indexes going into recovery are: 1) Your heap is enormous but your garbage collection is not tuned. 2) You don't have enough RAM, separate from your Java heap, for adequate index caching. With a billion documents in your collection, you might even be having problems with both. Here's a wiki page that includes some info on both of these problems, plus a few others: http://wiki.apache.org/solr/SolrPerformanceProblems Thanks, Shawn
SolrCloud delete by query performance
I have a collection with 1 billion documents and I want to delete 500 of them. The collection has a dozen shards and a couple replicas. Using Solr 4.4. Sent the delete query via HTTP: http://hostname:8983/solr/my_collection/update?stream.body= deletequerysource:foo/query/delete Took a couple minutes and several replicas got knocked into Recovery mode. They eventually came back and the desired docs were deleted but the cluster wasn't thrilled (high load, etc). Is this expected behavior? Is there a better way to delete documents that I'm missing? Thanks, Ryan
Re: SolrCloud delete by query performance
Shawn, thank you very much for that explanation. It helps a lot. Cheers, Ryan On Wed, May 20, 2015 at 5:07 PM, Shawn Heisey apa...@elyograg.org wrote: On 5/20/2015 5:57 PM, Ryan Cutter wrote: GC is operating the way I think it should but I am lacking memory. I am just surprised because indexing is performing fine (documents going in) but deletions are really bad (documents coming out). Is it possible these deletes are hitting many segments, each of which I assume must be re-built? And if there isn't much slack memory laying around to begin with, there's a bunch of contention/swap? A deleteByQuery must first query the entire index to determine which IDs to delete. That's going to hit every segment. In the case of SolrCloud, it will also hit at least one replica of every single shard in the collection. If the data required to satisfy the query is not already sitting in the OS disk cache, then the actual disk must be read. When RAM is extremely tight, any disk operation will erase relevant data out of the OS disk cache, so the next time it is needed, it must be read off the disk again. Disks are SLOW. What I am describing is not swap, but the performance impact is similar to swapping. The actual delete operation (once the IDs are known) doesn't touch any segments ... it writes Lucene document identifiers to a .del file, and that file is consulted on all queries. Any deleted documents found in the query results are removed. Thanks, Shawn
Overseer cannot talk to ZK
Solr 4.7.2 went down during a period of little activity. Wondering if anyone has an idea about what's going on, thanks! INFO - 2014-09-26 15:35:00.152; org.apache.solr.cloud.DistributedQueue$LatchChildWatcher; LatchChildWatcher fired on path: null state: Disconnected type None then eventually: WARN - 2014-09-26 15:35:00.377; org.apache.solr.cloud.OverseerCollectionProcessor; Overseer cannot talk to ZK and: WARN - 2014-09-26 15:35:00.454; org.apache.solr.cloud.Overseer$ClusterStateUpdater; Solr cannot talk to ZK, exiting Overseer main queue loop org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = Session expired for /overseer/queue at org.apache.zookeeper.KeeperException.create(KeeperException.java:127) at org.apache.zookeeper.KeeperException.create(KeeperException.java:51) at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1468) at org.apache.solr.common.cloud.SolrZkClient$6.execute(SolrZkClient.java:257) at org.apache.solr.common.cloud.SolrZkClient$6.execute(SolrZkClient.java:254) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73) at org.apache.solr.common.cloud.SolrZkClient.getChildren(SolrZkClient.java:254) at org.apache.solr.cloud.DistributedQueue.orderedChildren(DistributedQueue.java:89) at org.apache.solr.cloud.DistributedQueue.peek(DistributedQueue.java:411) at org.apache.solr.cloud.DistributedQueue.peek(DistributedQueue.java:391) at org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:173) at java.lang.Thread.run(Thread.java:662) as well as: ERROR - 2014-09-26 15:35:21.025; org.apache.solr.common.SolrException; There was a problem finding the leader in zk:org.apache.solr.common.SolrException: Could not get leader props at org.apache.solr.cloud.ZkController.getLeaderProps(ZkController.java:934) at org.apache.solr.cloud.ZkController.getLeaderProps(ZkController.java:898) at org.apache.solr.cloud.ZkController.waitForLeaderToSeeDownState(ZkController.java:1422) at org.apache.solr.cloud.ZkController.registerAllCoresAsDown(ZkController.java:370) at org.apache.solr.cloud.ZkController.access$000(ZkController.java:87) at org.apache.solr.cloud.ZkController$1.command(ZkController.java:222) at org.apache.solr.common.cloud.ConnectionManager$1$1.run(ConnectionManager.java:166) Caused by: org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /collections/collection1/leaders/shard1 at org.apache.zookeeper.KeeperException.create(KeeperException.java:111) at org.apache.zookeeper.KeeperException.create(KeeperException.java:51) at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1151) at org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:274) at org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:271) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73) at org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:271) at org.apache.solr.cloud.ZkController.getLeaderProps(ZkController.java:912) ... 6 more In ZK's log at about the same time: 2014-09-26 15:35:00,000 [myid:] - INFO [SessionTracker:ZooKeeperServer@334] - Expiring session 0x144e09d7b910008, timeout of 3ms exceeded 2014-09-26 15:35:00,000 [myid:] - WARN [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0:2181:NIOServerCnxn@349] - caught end of stream exception EndOfStreamException: Unable to read additional data from client sessionid 0x144e09d7b910007, likely client has closed socket at org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:220) at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:224) at java.lang.Thread.run(Thread.java:662) as well as: 2014-09-26 15:35:00,534 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@617] - Got user-level KeeperException when processing sessionid:0x144e09d7b91000a type:delete cxid:0x8 zxid:0xbdd txntype:-1 reqpath:n/a Error Path:/overseer_elect/leader Error:KeeperErrorCode = NoNode for /overseer_elect/leader 2014-09-26 15:35:00,572 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@617] - Got user-level KeeperException when processing sessionid:0x144e09d7b91000a type:create cxid:0xd zxid:0xbdf txntype:-1 reqpath:n/a Error Path:/overseer Error:KeeperErrorCode = NodeExists for /overseer
Re: Overseer cannot talk to ZK
Sorry, I believe this can be disregarded. There were changes made to system time that likely caused this state. Apologies, Ryan On Mon, Sep 29, 2014 at 8:24 AM, Ryan Cutter ryancut...@gmail.com wrote: Solr 4.7.2 went down during a period of little activity. Wondering if anyone has an idea about what's going on, thanks! INFO - 2014-09-26 15:35:00.152; org.apache.solr.cloud.DistributedQueue$LatchChildWatcher; LatchChildWatcher fired on path: null state: Disconnected type None then eventually: WARN - 2014-09-26 15:35:00.377; org.apache.solr.cloud.OverseerCollectionProcessor; Overseer cannot talk to ZK and: WARN - 2014-09-26 15:35:00.454; org.apache.solr.cloud.Overseer$ClusterStateUpdater; Solr cannot talk to ZK, exiting Overseer main queue loop org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = Session expired for /overseer/queue at org.apache.zookeeper.KeeperException.create(KeeperException.java:127) at org.apache.zookeeper.KeeperException.create(KeeperException.java:51) at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1468) at org.apache.solr.common.cloud.SolrZkClient$6.execute(SolrZkClient.java:257) at org.apache.solr.common.cloud.SolrZkClient$6.execute(SolrZkClient.java:254) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73) at org.apache.solr.common.cloud.SolrZkClient.getChildren(SolrZkClient.java:254) at org.apache.solr.cloud.DistributedQueue.orderedChildren(DistributedQueue.java:89) at org.apache.solr.cloud.DistributedQueue.peek(DistributedQueue.java:411) at org.apache.solr.cloud.DistributedQueue.peek(DistributedQueue.java:391) at org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:173) at java.lang.Thread.run(Thread.java:662) as well as: ERROR - 2014-09-26 15:35:21.025; org.apache.solr.common.SolrException; There was a problem finding the leader in zk:org.apache.solr.common.SolrException: Could not get leader props at org.apache.solr.cloud.ZkController.getLeaderProps(ZkController.java:934) at org.apache.solr.cloud.ZkController.getLeaderProps(ZkController.java:898) at org.apache.solr.cloud.ZkController.waitForLeaderToSeeDownState(ZkController.java:1422) at org.apache.solr.cloud.ZkController.registerAllCoresAsDown(ZkController.java:370) at org.apache.solr.cloud.ZkController.access$000(ZkController.java:87) at org.apache.solr.cloud.ZkController$1.command(ZkController.java:222) at org.apache.solr.common.cloud.ConnectionManager$1$1.run(ConnectionManager.java:166) Caused by: org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /collections/collection1/leaders/shard1 at org.apache.zookeeper.KeeperException.create(KeeperException.java:111) at org.apache.zookeeper.KeeperException.create(KeeperException.java:51) at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1151) at org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:274) at org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:271) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73) at org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:271) at org.apache.solr.cloud.ZkController.getLeaderProps(ZkController.java:912) ... 6 more In ZK's log at about the same time: 2014-09-26 15:35:00,000 [myid:] - INFO [SessionTracker:ZooKeeperServer@334] - Expiring session 0x144e09d7b910008, timeout of 3ms exceeded 2014-09-26 15:35:00,000 [myid:] - WARN [NIOServerCxn.Factory: 0.0.0.0/0.0.0.0:2181:NIOServerCnxn@349] - caught end of stream exception EndOfStreamException: Unable to read additional data from client sessionid 0x144e09d7b910007, likely client has closed socket at org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:220) at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:224) at java.lang.Thread.run(Thread.java:662) as well as: 2014-09-26 15:35:00,534 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@617] - Got user-level KeeperException when processing sessionid:0x144e09d7b91000a type:delete cxid:0x8 zxid:0xbdd txntype:-1 reqpath:n/a Error Path:/overseer_elect/leader Error:KeeperErrorCode = NoNode for /overseer_elect/leader 2014-09-26 15:35:00,572 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@617] - Got user-level KeeperException when processing sessionid:0x144e09d7b91000a type:create cxid:0xd zxid:0xbdf txntype:-1 reqpath:n/a Error Path:/overseer Error:KeeperErrorCode = NodeExists for /overseer
Re: Index a time/date range
Great resources, thanks everyone! On Wed, Jul 30, 2014 at 8:12 PM, david.w.smi...@gmail.com david.w.smi...@gmail.com wrote: The wiki page on the technique cleans up some small errors from Hoss’s presentation: http://wiki.apache.org/solr/SpatialForTimeDurations But please try Solr trunk which has first-class support for date durations: https://issues.apache.org/jira/browse/SOLR-6103 Soonish I’ll back-port to 4x. ~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley On Wed, Jul 30, 2014 at 7:29 PM, Jost Baron jost.ba...@gmx.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ryan, On 07/31/2014 01:26 AM, Ryan Cutter wrote: Is there a way to index time or date ranges? That is, assume 2 docs: #1: date = 2014-01-01 #2: date = 2014-02-01 through 2014-05-01 Would there be a way to index #2's date as a single field and have all the search options you usually get with time/date? One strategy could be to index the start and stop values separately. Just wondering if there's a fancier option out there. Take a look at this: https://people.apache.org/~hossman/spatial-for-non-spatial-meetup-20130117/ Regards, Jost -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPZf94ACgkQNme/yCvmvTIp9ACfeuKfCRFuGY/Y2aLH6BxtkS+c kNMAoIcWFuJnnwV8ouajvTUXojR6HiTo =EKfo -END PGP SIGNATURE-
Index a time/date range
Is there a way to index time or date ranges? That is, assume 2 docs: #1: date = 2014-01-01 #2: date = 2014-02-01 through 2014-05-01 Would there be a way to index #2's date as a single field and have all the search options you usually get with time/date? One strategy could be to index the start and stop values separately. Just wondering if there's a fancier option out there. Thanks, Ryan
Branch/Java questions re: contributing code
1. Should we be using Java 6 or 7? The docs say 1.6 ( http://wiki.apache.org/solr/HowToContribute) but running 'ant test' on trunk/ yields: /lucene/common-build.xml:328: Minimum supported Java version is 1.7. I don't get that error with branch_4x/ which leads to my next question. 2. Should work toward 4.X be done on trunk/ or branch_4x/? It sounds like patches should be based on trunk then it gets ported as necessary. Thanks! Ryan
Re: Branch/Java questions re: contributing code
Thanks, everything worked fine after these pointers and I was able to generate a patch properly. Cheers, Ryan On Mon, Jan 6, 2014 at 7:31 AM, Shalin Shekhar Mangar shalinman...@gmail.com wrote: On Mon, Jan 6, 2014 at 8:54 PM, Ryan Cutter ryancut...@gmail.com wrote: 1. Should we be using Java 6 or 7? The docs say 1.6 ( http://wiki.apache.org/solr/HowToContribute) but running 'ant test' on trunk/ yields: /lucene/common-build.xml:328: Minimum supported Java version is 1.7. I don't get that error with branch_4x/ which leads to my next question. branch_4x is on Java 6 and trunk is on Java 7. 2. Should work toward 4.X be done on trunk/ or branch_4x/? It sounds like patches should be based on trunk then it gets ported as necessary. Thanks! Ryan Yeah, you are right. Features are committed to trunk first and backported to branch_4x -- Regards, Shalin Shekhar Mangar.
Re: Heap size and Solr 4.3
Marcello, Can you quantify what you're seeing? Did you send the JVM any args (Xmx, Xms, etc)? Thanks, Ryan On Mon, Dec 16, 2013 at 1:01 AM, Marcello Lorenzi mlore...@sorint.itwrote: Hi All, we have deployed on our production environment a new Solr 4.3 instance (2 nodes with SolrCloud) but this morning one node gone on outofmemory status and we have noticed that the JVM uses a lot of Old Gen space during the normal lifecycle. What are the items that improve this high usage of Heap? Thanks, Marcello
Re: Solr hardware memory question
Shawn's right that if you're going to scale this big you'd be very well served to spend time getting the index as small as possible. In my experience if your searches require real-time random access reads (that is, the entire index needs to be fast), you don't want to wait for HDD disk reads. Getting everything in RAM is best but 6TB per replica (perhaps you'll want more than 1 replica?) is a tall order. SSDs are coming down in price. Flash memory tech is advancing quickly (Fusion-io and the like). Sounds like an interesting use case! Thanks, Ryan On Tue, Dec 10, 2013 at 9:37 AM, Shawn Heisey s...@elyograg.org wrote: On 12/10/2013 9:51 AM, Hoggarth, Gil wrote: We're probably going to be building a Solr service to handle a dataset of ~60TB, which for our data and schema typically gives a Solr index size of 1/10th - i.e., 6TB. Given there's a general rule about the amount of hardware memory required should exceed the size of the Solr index (exceed to also allow for the operating system etc.), how have people handled this situation? Do I really need, for example, 12 servers with 512GB RAM, or are there other techniques to handling this? That really depends on what kind of query volume you'll have and what kind of performance you want. If your query volume is low and you can deal with slow individual queries, then you won't need that much memory. If either of those requirements increases, you'd probably need more memory, up to the 6TB total -- or 12TB if you need to double the total index size for redundancy purposes. If your index is constantly growing like most are, you need to plan for that too. Putting the entire index into RAM is required for *top* performance, but not for base functionality. It might be possible to put only a fraction of your index into RAM. Only testing can determine what you really need to obtain the performance you're after. Perhaps you've already done this, but you should try as much as possible to reduce your index size. Store as few fields as possible, only just enough to build a search result list/grid and retrieve the full document from the canonical data store. Save termvectors and docvalues on as few fields as possible. If you can, reduce the number of terms produced by your analysis chains. Thanks, Shawn
Re: Constantly increasing time of full data import
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 on the system. It's possible you're seeing something outside the norm - I just don't know what you were expecting and the capabilities of your resources. You might want to post more info (autoCommit settings, etc) as well. Thanks, Ryan On Mon, Dec 2, 2013 at 4:22 AM, michallos michal.ware...@gmail.com wrote: 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 such strange behaviour? It is critical for us. Best, Michal -- View this message in context: http://lucene.472066.n3.nabble.com/Constantly-increasing-time-of-full-data-import-tp4103873p4104370.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: How to remove a Solr Node and its cores from a cluster SolrCloud and from collection
For people who run into this situation in the future: I had the exact same problem Sebastien had while using 4.4.0 (1 of my 6 nodes died). We rebuilt a host to take its place but gave it the same hostname instead of making a new one. It was configured the same way with the same config files but without any data of course. When Solr on this rebuilt host got fired up, it joined ZK and the shard indexes were repopulated from the other hosts. Didn't have any issues. I think the host that died was a leader and now the rebuilt host that took its place is a replica - fine with me. I think if you pick a new hostname and the dead node kept popping up, I'd try to edit the clusterstate.json file in ZK. - Ryan On Fri, Nov 29, 2013 at 5:17 AM, Eric Bus eric@websight.nl wrote: Hi Sébastien, Maybe this can help? Add a collection admin command to remove a replica https://issues.apache.org/jira/browse/SOLR-5310 It's part of the new 4.6.0 update. Best regards, Eric -Oorspronkelijk bericht- Van: Seb Geek [mailto:geek...@gmail.com] Verzonden: vrijdag 29 november 2013 12:47 Aan: solr-user@lucene.apache.org Onderwerp: How to remove a Solr Node and its cores from a cluster SolrCloud and from collection Hello, I have a cluster of 4 Solr Cloud Nodes (nodes N1, N2, N3, N4). I use Solr version 4.5.1 . One (N4) of these node have completely died (all cpu, ram and disks are lost), I have added an other node (N5) to the Solr Cloud cluster and copied all core configuration previously on node N4 to that node (solr.xml and core.properties in data dir). That N5 node have replicated all the index of my collection and is already able to respond to request for the core (replica) that it owns. In the state of my Solr cloud cluster, i can see old replicas on the died node N4 ! how can i remove theses replica from my collection ? Thanks Sébastien
Re: Unit of dimension for solr field
I think Upayavira's suggestion of writing a filter factory fits what you're asking for. However, the other end of cleverness is to simple use solr.TrieIntField and store everything in MB. So for 1TB you'd write 51200. A range query for 256MB to 1GB would be field:[256 TO 1024]. Conversion from MB to your displayed unit (2TB, for example) would happen in the application layer. But using trie ints would be simple and efficient. - Ryan On Mon, Nov 11, 2013 at 7:06 AM, eakarsu eaka...@gmail.com wrote: Thanks Upayavira It seems it needs too much work. I will have several more fields that will have unit values. Do we have more quicker way of implementing it? We have Currency filed coming as default with SOLR. Can we use it? Creating conversion rate table for each field? What I am expecting from units is similar to currency field Erol Akarsu -- View this message in context: http://lucene.472066.n3.nabble.com/Unit-of-dimension-for-solr-field-tp4100209p4100295.html Sent from the Solr - User mailing list archive at Nabble.com.
